Hi Pat: Copying 6LowPAN
>(2) I could not tell if the fragment congestion problem for the >consolidated message (all fragments) would be > indicated to the higher layer for some action to be taken (e.g. >to back off) or if this proposal > is to entirely handled fragment congestion within the >fragmenting (network) layer. Thanks a bunch for reviewing the draft. I found typos and republished, in particular to use the proper terms (fragments, packets, segments, frames) at the right place. Please let me know if I still missed any. I think that the process that you are talking about fits in the overall the ECN process that the draft intentionally does not cover ;) . Consider what IP does with ECN and IP fragments: if any fragment has ECN set then the reassembled packet must have ECN set. I expect the same behaviour if we place ECN bites in a 6LoWPAN header. Should any 6LoWPAN fragment experience congestion over the LowPAN, then the recomposed IP packet should have ECN on. So if you have transport level ECN support, then the proper end-to-end mechanism should throttle the source. A B(ackward)ECN mechanism at L2 would work for a source that is within the LowPAN. So it would help when the control is in the device, and fail if the push comes from outside because there is no way to propage BECN over IP. Makes sense? Pascal >-----Original Message----- >From: Brett, Patricia (PA62) [mailto:[EMAIL PROTECTED] >Sent: jeudi 29 mai 2008 22:18 >To: Pascal Thubert (pthubert) >Subject: RE: [sp100.11a-pdnt] FW: New Version Notification for draft-thubert-6lowpan-simple-fragment- >recovery-01 > >Hi Pascal >Two remarks: > >(1) I agree with statement regarding : > The process must complete within an acceptable time that is within > the boundaries of upper layer retries. > >(2) I could not tell if the fragment congestion problem for the >consolidated message (all fragments) would be > indicated to the higher layer for some action to be taken (e.g. >to back off) or if this proposal > is to entirely handled fragment congestion within the >fragmenting (network) layer. > > I mean I did not find anything that said a certain amount of >fragment congestion (be that 1 fragment > or a percentage of fragments, or what) for the "whole message" >(all fragments) would also be > indicated to higher layer as congestion for the message as a >whole. > You know, so then BECN could be given, and the original sending >application could also backoff. > Do you know what I mean? > >Regards, >Pat > >-----Original Message----- >From: Pascal Thubert (pthubert) [mailto:[EMAIL PROTECTED] >Sent: Tuesday, May 27, 2008 10:40 AM >To: Phy/DLL/Network/Transport group >Subject: [sp100.11a-pdnt] FW: New Version Notification for >draft-thubert-6lowpan-simple-fragment-recovery-01 > >Hi: > >FYI I published a new version of the fragment recovery draft. It now >includes ECN echo and more details on flow control. > >For those who believe that this will be needed sonner than later :) > >http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recove r >y > >Pascal >>-----Original Message----- >>From: IETF I-D Submission Tool [mailto:[EMAIL PROTECTED] >>Sent: vendredi 23 mai 2008 12:50 >>To: Pascal Thubert (pthubert) >>Subject: New Version Notification for >draft-thubert-6lowpan-simple-fragment-recovery-01 >> >> >>A new version of I-D, >draft-thubert-6lowpan-simple-fragment-recovery-01.txt has been >successfuly >>submitted by Pascal Thubert and posted to the IETF repository. >> >>Filename: draft-thubert-6lowpan-simple-fragment-recovery >>Revision: 01 >>Title: LoWPAN simple fragment Recovery >>Creation_date: 2008-05-23 >>WG ID: Independent Submission >>Number_of_pages: 12 >> >>Abstract: >>Considering that 6LoWPAN packets can be as large as 2K bytes and that >>an 802.15.4 frame with security will carry in the order of 80 bytes of >>effective payload, a packet might end up fragmented into as many as 25 >>fragments at the 6LoWPAN shim layer. If a single one of those >>fragments is lost in transmission, all fragments must be resent, >>further contributing to the congestion that might have caused the >>initial packet loss. This draft introduces a simple protocol to >>recover individual fragments between 6LoWPAN endpoints. >> >> >> >>The IETF Secretariat. >> > > > >--- >You are currently subscribed to sp100.11a-pdnt as: >[EMAIL PROTECTED] To unsubscribe send a blank email to >[EMAIL PROTECTED] _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
