Subject: [Fecframe] Packet MTU and other IP header issues

From: Marshall Eubanks <[email-masked]>
Date: Fri, 21 Sep 2007 14:12:47 -0400

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