From fecframe-bounces@ietf.org Fri Sep 21 14:12:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmzm-0000Zh-Tq; Fri, 21 Sep 2007 14:12:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmzk-0000SW-VO for fecframe@ietf.org; Fri, 21 Sep 2007 14:12:53 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYmzk-0005Fi-6G for fecframe@ietf.org; Fri, 21 Sep 2007 14:12:52 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 8457315 for fecframe@ietf.org; Fri, 21 Sep 2007 14:12:51 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <673373A0-EF13-4C03-A6DF-EA764E4FB199@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Fri, 21 Sep 2007 14:12:47 -0400 To: fecframe@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [Fecframe] Packet MTU and other IP header issues X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org 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 > Date: September 21, 2007 7:55:09 AM EDT > To: fecframe-proto@ietf.org > 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 Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Sep 25 08:24:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9Rt-0002Os-Db; Tue, 25 Sep 2007 08:23:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9Rs-0002Oi-SH for fecframe@ietf.org; Tue, 25 Sep 2007 08:23:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia9Rr-0003sn-KN for fecframe@ietf.org; Tue, 25 Sep 2007 08:23:32 -0400 X-IronPort-AV: E=Sophos;i="4.20,295,1186372800"; d="scan'208";a="132931427" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Sep 2007 08:23:27 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8PCNVhY002962 for ; Tue, 25 Sep 2007 08:23:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8PCNPVG008668 for ; Tue, 25 Sep 2007 12:23:34 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 08:23:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Sep 2007 08:23:22 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6041E8DCD@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fecframe Digest, Vol 20, Issue 1 Thread-Index: Acf9MbxASOIjDeBdTgabHvBBlgGdMgBy3/Ng From: "Rajiv Asati \(rajiva\)" To: X-OriginalArrivalTime: 25 Sep 2007 12:23:23.0618 (UTC) FILETIME=[DDCF3C20:01C7FF6E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8066; t=1190723011; x=1191587011; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20\(rajiva\)=22=20 |Subject:=20RE=3A=20Fecframe=20Digest,=20Vol=2020,=20Issue=201 |Sender:=20 |To:=20; bh=4uP5SUh7c/8Tn5a/AUbGOIiRHTR/6q3UW5VIYwjSfH4=; b=KxDxtw91Cz/Ivt/MEZ+5mMZ42P9APcesH38gi+js1hr19KvEa9uab5Zd7ZhJImR+QPo+JKo6 8jCwj9hbn/HZO3honPkS3tEDsmLRXwgT9y1hN2eh+tzpcMZLtTPYyuVO; Authentication-Results: rtp-dkim-1; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -3.1 (---) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Subject: [Fecframe] RE: Fecframe Digest, Vol 20, Issue 1 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org > There are certain problems with this if you are thinking of a "dumb =20 > source" sending to a > FEC box and then out to the world. (I see this as a likely major use =20 > for FECFRAME; I strongly think we need to support it.) Ditto.=20 > We could make the FEC scheme know or guess the MTU and do something =20 > if it will violate it, like replacing 1 data packet for 2 repair =20 > packets if the MTU will be violated, but this seems very likely to =20 > cause problems to me for a bunch of reasons. >=20 > 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.=20 Cheers, Rajiv > -----Original Message----- > From: fecframe-request@ietf.org [mailto:fecframe-request@ietf.org]=20 > Sent: Saturday, September 22, 2007 12:00 PM > To: fecframe@ietf.org > Subject: Fecframe Digest, Vol 20, Issue 1 >=20 > Send Fecframe mailing list submissions to > fecframe@ietf.org >=20 > 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 > fecframe-request@ietf.org >=20 > You can reach the person managing the list at > fecframe-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Fecframe digest..." >=20 >=20 > Today's Topics: >=20 > 1. Packet MTU and other IP header issues (Marshall Eubanks) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Fri, 21 Sep 2007 14:12:47 -0400 > From: Marshall Eubanks > Subject: [Fecframe] Packet MTU and other IP header issues > To: fecframe@ietf.org > Message-ID: <673373A0-EF13-4C03-A6DF-EA764E4FB199@multicasttech.com> > Content-Type: text/plain; charset=3DUS-ASCII; delsp=3Dyes; = format=3Dflowed >=20 > This is the first of several emails raising issues from the Design =20 > Team workshop earlier this week that I think needs the groups =20 > attention. Slightly modified from the original. Comments would be =20 > appreciated. >=20 > I thought that the Design Team meeting went really well and should =20 > really improve the draft. >=20 > Marshall >=20 > Begin forwarded message: >=20 > > From: Marshall Eubanks > > Date: September 21, 2007 7:55:09 AM EDT > > To: fecframe-proto@ietf.org > > Subject: [FECFRAME-PROTO] Packet MTU and other IP header issues > > >=20 >=20 > Note this text from Section 6.3 of draft-ietf-fecframe-framework-00 >=20 > The IP and transport header fields MUST be identical to=20 > those of the > original source packet. The Original transport Payload field =20 > 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. >=20 > This specifies a systematic code, where the original source is > part of the encoded stream (subject to the possible addition=20 > of a FEC =20 > Payload ID at the end of the packet). >=20 > There are certain problems with this if you are thinking of a "dumb =20 > source" sending to a > FEC box and then out to the world. (I see this as a likely major use =20 > for FECFRAME; I strongly think > we need to support it.) >=20 > Note that the above text states clearly that _FEC protected sources =20 > keep their original source IP addresses_. > If the FEC protection is not done in the same box, it is done by a =20 > _middleware_ box. >=20 > Now, some things are clearly missing here : >=20 > - I think that the RTT MUST be decremented by 1 if the FEC is=20 > applied =20 > by another box. (You don't want loops of the form Source -> FEC -> =20 > Source -> FEC -> infinity.) >=20 > - The _Length_ field of the IP header MUST be changed if the FEC =20 > Payload ID is used. >=20 > - The _Length_ field of the UDP header MUST be changed if the FEC =20 > Payload ID is used. >=20 > - The _Check Sum_ field of the UDP header MUST be changed if the FEC =20 > Payload ID is used. >=20 > Now, DCCP allows for check sums over part of the data of the packet, =20 > including all or none. >=20 > Do we want to require DCCP in FECFRAME to extend the check sum to =20 > cover the FEC Payload ID ? Note the implication. I may say that, in =20 > video encoding foo, the first 100 bytes are critical, so I=20 > will apply =20 > the checksum to them, but the next 1300 bytes are not so=20 > critical, so =20 > I will tolerate bit errors, and so the check sum only applies to the =20 > first 100 bytes. Then, if we apply FEC, that means that either we =20 > have to tolerate bit errors in the FEC Payload ID, which seems very =20 > dicey, or we have to ignore this. >=20 > In fact, I think this should be done in any case. Even single bit =20 > errors in the payload could potentially cause catastrophic errors in =20 > recovery of lost packets if the errored packet is used in their =20 > recovery. So, I would add >=20 > - The _Check Sum_ field of the DCCP header MUST be changed if=20 > the FEC =20 > Payload ID is used, and the check sum MUST be extended to cover the =20 > entire length of the DCCP data payload, including the FEC=20 > Payload ID, =20 > if any, regardless of the coverage of the original DCCP packet. >=20 > Now, for the MTU issue. This is something that rears its ugly head =20 > whenever you start adding headers or trailers to packets is the MTU =20 > issue. Many packets of media flows are sent at the MTU limit, so =20 > adding even a few bytes > can cause the packet to be too big, resulting in fragmentation and =20 > dropped packets. Many networks will drop all fragmented packets, due =20 > to the overhead they cause and possible security worries, so just =20 > ignoring this is bad. >=20 > The FEC Payload ID, if used, will definitely cause this problem. >=20 > I don't see any text about this, and there needs to be. >=20 > This is a mess, because the packet may have an internal sequence =20 > number, so you can't just have the FEC scheme divide them. Solutions =20 > I see include >=20 > a statement on source configuration should be added : >=20 > - Sources of data intended for the application of FEC SHOULD be =20 > configured to allow for the insertion of the maximum size FEC=20 > Payload =20 > ID if the MTU of the distribution network is known, and MUST be =20 > configured to not send packets large enough to violate the maximum =20 > size of an IP packet once the FEC Payload ID is added. >=20 > We could make the FEC scheme know or guess the MTU and do something =20 > if it will violate it, like replacing 1 data packet for 2 repair =20 > packets if the MTU will be violated, but this seems very likely to =20 > cause problems to me for a bunch of reasons. >=20 > Any other ideas on this ? >=20 > Regards > Marshall >=20 > P.S. The FECFRAME drafts have expired, but they can be found at >=20 > http://tools.ietf.org/wg/fecframe/ >=20 >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe >=20 >=20 > End of Fecframe Digest, Vol 20, Issue 1 > *************************************** >=20 _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe