Re: [6lowpan] reference to fragmentation draft, and IPv6 fragmentation (was: LoWPAN simple fragment Recovery)

Side-note

The draft in question is:
http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-05

It is not clear to me why there is a need for 6LoWPAN to manage 
fragmentation below the IP layer (at the 6LoWPAN shim layer) vs managing 
fragmentation at the IP layer (IPv6 fragmentation and reassembly).

The motivation presented in the draft is doubtful, for example refers to 
IPv4 fragmentation, instead of IPv6.  It also refers to MSS of TCP, and 
not to IP fragmentation.

I am not sure where to look for motivation of doing fragmentation at the 
shim layer below IP for 6LoWPAN.

I may miss large parts of earlier discussion/documents.

Alex

Pascal Thubert (pthubert) a écrit :
> Hi Fred:
> 
> 128 includes a lot of overhead, mostly security; the real usable data
> can be in the order of 80 bytes.
> In practice RFC 4944 fixes an MTU of 1280 for 802.15.4. So 16 should
> still be enough VERY strictly speaking. 
> 
> To be considered: some stacks are so constrained that they cannot
> receive 2 fragmented packets in parallel so a very large packet will
> lock resources for a very long time. Another angle is that ISA100.11a
> nodes do not support IP fragments and PMTU discovery on the grounds that
> the MTU is 1280.
> 
> But I thought that might be a bit short sighted. If we use different
> media, with different max frame or security. If 6LoWPAN or an
> implementation was to allow up to 1500 or 2048 we'd be in trouble. So I
> went for 32 to start with, and I might have overshot. 
> 
> The sense of history is that we'll probably not increase MTU for 9K
> packets on 802.15.4 and maybe we'll reduce the number of bits in my
> fragment recovery header. This is certainly something that will pop up
> at the WG to optimize once the group takes the draft aboard. There was a
> rough consensus in SFO to accept the draft but the charter does not
> really include this work. 
> 
> Keep you tuned :)
> 
> Pascal
> 
>> -----Original Message-----
>> From: Fred Baker (fred)
>> Sent: mercredi 17 juin 2009 00:52
>> To: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org
>> Cc: 6lowpan@ietf.org
>> Subject: LoWPAN simple fragment Recovery
>>
>> reading draft-thubert-6lowpan-simple-fragment-recovery-05 and came up
>> with a question.
>>
>> Section 4 indicates that "The recovery mechanism must support highly
>> fragmented packets, with a maximum of 32 fragments per packet." I
>> agree that 32 128 byte fragments is a lot of fragments, but I'm
>> concerned: there is discussion of allowing 9K packets. What happens
>> when a 9K packet goes to a sensor? since 9K/128 is on the order of 70,
>> you are going to have to reply "packet too big". If that is
>> acceptable, why not limit this to 16 fragments, 128*16 being greater
>> that 1500 bytes?
>>
>> Where did "32" come from?
>>
> 
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
> 