Subject: [Fecframe] RE: Fecframe Digest, Vol 20, Issue 1

From: "Rajiv Asati \(rajiva\)" <[email-masked]>
Date: Tue, 25 Sep 2007 08:23:22 -0400

> There are certain problems with this if you are thinking of a "dumb  
> source" sending to a
> FEC box and then out to the world. (I see this as a likely major use  
> for FECFRAME; I strongly think we need to support it.)

Ditto. 

> We could make the FEC scheme know or guess the MTU and do something  
> if it will violate it, like replacing 1 data packet for 2 repair  
> packets if the MTU will be violated, but this seems very likely to  
> cause problems to me for a bunch of reasons.
> 
> Any other ideas on this ?

It gets trickier, actually. While it is straight-forward to figure out
the MTU of the attached interface, it is not the only thing we should
rely on, since a smaller MTU size along the path may cause the packet to
be fragmented or dropped. What we really need is the ability to figure
out the max MTU end-to-end.

Hence, we should consider exploiting the "PMTU discovery" at the box
implementing the FEC functionality. This will help to get the max MTU
available end-to-end.
This is one of the common utilities already exploited a lot of IP
protocols. Of course, it is easier to do this for unicast, but
challenging for multicast. 

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Saturday, September 22, 2007 12:00 PM
> To: [email-masked]
> Subject: Fecframe Digest, Vol 20, Issue 1
> 
> Send Fecframe mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/fecframe
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Fecframe digest..."
> 
> 
> Today's Topics:
> 
>    1. Packet MTU and other IP header issues (Marshall Eubanks)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 21 Sep 2007 14:12:47 -0400
> From: Marshall Eubanks <[email-masked]>
> Subject: [Fecframe] Packet MTU and other IP header issues
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
> 
> This is the first of several emails raising issues from the Design  
> Team workshop earlier this week that I think needs the groups  
> attention. Slightly modified from the original. Comments would be  
> appreciated.
> 
> I thought that the Design Team meeting went really well and should  
> really improve the draft.
> 
> Marshall
> 
> Begin forwarded message:
> 
> > From: Marshall Eubanks <[email-masked]>
> > Date: September 21, 2007 7:55:09 AM EDT
> > To: [email-masked]
> > Subject: [FECFRAME-PROTO] Packet MTU and other IP header issues
> >
> 
> 
> Note this text from Section 6.3 of draft-ietf-fecframe-framework-00
> 
>     The IP and transport header fields MUST be identical to 
> those of the
>     original source packet.  The Original transport Payload field  
> MUST be
>     identical to the transport payload of the original source packet.
>     The transport payload of the FEC Source packet MUST consist of the
>     Original Transport Payload followed by the Source FEC Payload ID
>     field, if required.
> 
> This specifies a systematic code, where the original source is
> part of the encoded stream (subject to the possible addition 
> of a FEC  
> Payload ID at the end of the packet).
> 
> There are certain problems with this if you are thinking of a "dumb  
> source" sending to a
> FEC box and then out to the world. (I see this as a likely major use  
> for FECFRAME; I strongly think
> we need to support it.)
> 
> Note that the above text states clearly that _FEC protected sources  
> keep their original source IP addresses_.
> If the FEC protection is not done in the same box, it is done by a  
> _middleware_ box.
> 
> Now, some things are clearly missing here :
> 
> - I think that the RTT MUST be decremented by 1 if the FEC is 
> applied  
> by another box. (You don't want loops of the form  Source -> FEC ->  
> Source -> FEC -> infinity.)
> 
> - The _Length_ field of the IP header MUST be changed if the FEC  
> Payload ID is used.
> 
> - The _Length_ field of the UDP header MUST be changed if the FEC  
> Payload ID is used.
> 
> - The _Check Sum_ field of the UDP header MUST be changed if the FEC  
> Payload ID is used.
> 
> Now, DCCP allows for check sums over part of the data of the packet,  
> including all or none.
> 
> Do we want to require DCCP in FECFRAME to extend the check sum to  
> cover the FEC Payload ID ? Note the implication. I may say that, in  
> video encoding foo, the first 100 bytes are critical, so I 
> will apply  
> the checksum to them, but the next 1300 bytes are not so 
> critical, so  
> I will tolerate bit errors, and so the check sum only applies to the  
> first 100 bytes. Then, if we apply FEC, that means that either we  
> have to tolerate bit errors in the FEC Payload ID, which seems very  
> dicey, or we have to ignore this.
> 
> In fact, I think this should be done in any case. Even single bit  
> errors in the payload could potentially cause catastrophic errors in  
> recovery of lost packets if the errored packet is used in their  
> recovery. So, I would add
> 
> - The _Check Sum_ field of the DCCP header MUST be changed if 
> the FEC  
> Payload ID is used, and the check sum MUST be extended to cover the  
> entire length of the DCCP data payload, including the FEC 
> Payload ID,  
> if any, regardless of the coverage of the original DCCP packet.
> 
> Now, for the MTU issue. This is something that rears its ugly head  
> whenever you start adding headers or trailers to  packets is the MTU  
> issue. Many packets of media flows are sent at the MTU limit, so  
> adding even a few bytes
> can cause the packet to be too big, resulting in fragmentation and  
> dropped packets. Many networks will drop all fragmented packets, due  
> to the overhead they cause and possible security worries, so just  
> ignoring this is bad.
> 
> The FEC Payload ID, if used, will definitely cause this problem.
> 
> I don't see any text about this, and there needs to be.
> 
> This is a mess, because the packet may have an internal sequence  
> number, so you can't just have the FEC scheme divide them. Solutions  
> I see include
> 
> a statement on source configuration should be added :
> 
> - Sources of data intended for the application of FEC SHOULD be  
> configured to allow for the insertion of the maximum size FEC 
> Payload  
> ID if the MTU of the distribution network is known, and MUST be  
> configured to not send packets large enough to violate the maximum  
> size of an IP packet once the FEC Payload ID is added.
> 
> We could make the FEC scheme know or guess the MTU and do something  
> if it will violate it, like replacing 1 data packet for 2 repair  
> packets if the MTU will be violated, but this seems very likely to  
> cause problems to me for a bunch of reasons.
> 
> Any other ideas on this ?
> 
> Regards
> Marshall
> 
> P.S. The FECFRAME drafts have expired, but they can be found at
> 
> http://tools.ietf.org/wg/fecframe/
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/fecframe
> 
> 
> End of Fecframe Digest, Vol 20, Issue 1
> ***************************************
> 

_______________________________________________
Fecframe mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe