Re: [Roll] New Version Notification for draft-thubert-roll-forwarding-frags-01.txt

Hi Pascal,

Yes, to make it for over-LLNs not only 6lowpan. I being interested now to
read, I hope you don't mind if I ask another question while my read, that
is my bad habit, thanks,

AB

On Mon, Feb 25, 2013 at 4:15 PM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

>  Hello Abdussalam,****
>
> ** **
>
> This used to be 6LoWPAN but the work never took off there (see the mail
> exchange with Carsten).****
>
> The goal of the draft is to streamline fragments and retry individual frag
> loss. ****
>
> ** **
>
> It is useful if:****
>
> - you have route over****
>
> - but lack the 802.15.4g PHY.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
> *Sent:* lundi 25 février 2013 16:03
> *To:* Pascal Thubert (pthubert)
> *Cc:* roll@ietf.org
> *Subject:* Re: [Roll] New Version Notification for
> draft-thubert-roll-forwarding-frags-01.txt****
>
> ** **
>
> Hi Pascal,****
>
>  ****
>
> I may need to discuss to know my interest, or to understand. Does this
> protocol have interact with RPL or its information? The title is LLN
> forwarding but the content is about 6LowPan, is this work better fitted in
> 6LoWPAN WG than ROLL?****
>
>  ****
>
> AB****
>
> On Mon, Feb 25, 2013 at 10:58 AM, Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:****
>
> Dear WG:
>
> As you know well, 6LoWPAN will fragment packets that are too wide for the
> MTU, which is likely to happen in a number of cases, unless the 802.15.4g
> MAC is used.
>
> As a consequence, in a route-over RPL subnet, a large packet must be
> reassembled at each hop to be routed and fragmented again.
>
> Streamlining the fragments will improve latency, and will save memory and
> CPU in the intermediate nodes.
>
> This draft enables the forwarding of fragments, which selective
> acknowledgement and flow control capabilities, end to end over the LLN.
>
> Upon a private request, I resubmitted the draft with a simplification,
> that is the removal of en encoding that would compress the acknowledgement
> bitmap.
>
> I also restored some text about Congestion notification, in order to
> validate the need with the group.
>
> Please let the authors know if you have interest in pursuing this work,
>
> Pascal
>
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: lundi 25 février 2013 11:42
> To: Pascal Thubert (pthubert)
> Cc: Jonathan Hui (johui)
> Subject: New Version Notification for
> draft-thubert-roll-forwarding-frags-01.txt
>
>
> A new version of I-D, draft-thubert-roll-forwarding-frags-01.txt
> has been successfully submitted by Pascal Thubert and posted to the IETF
> repository.
>
> Filename:        draft-thubert-roll-forwarding-frags
> Revision:        01
> Title:           LLN Fragment Forwarding and Recovery
> Creation date:   2013-02-25
> Group:           Individual Submission
> Number of pages: 16
> URL:
> http://www.ietf.org/internet-drafts/draft-thubert-roll-forwarding-frags-01.txt
> Status:
> http://datatracker.ietf.org/doc/draft-thubert-roll-forwarding-frags
> Htmlized:
> http://tools.ietf.org/html/draft-thubert-roll-forwarding-frags-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-thubert-roll-forwarding-frags-01
>
> Abstract:
>    In order to be routed, a fragmented packet must be reassembled at
>    every hop of a multihop link where lower layer fragmentation occurs.
>    Considering that the IPv6 minimum MTU is 1280 bytes and that an an
>    802.15.4 frame can have a payload limited to 74 bytes in the worst
>    case, a packet might end up fragmented into as many as 18 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 forward and
>    recover individual fragments that might be lost over multiple hops
>    between 6LoWPAN endpoints.
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll****
>
> ** **
>