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

well, gee. My mention of putting the IPv6 header into 28 bytes was  
very tongue in cheek, but using IPv6 fragmentation instead of link  
layer fragmentation would require us to do exactly that. Am I mistaken?

If a link layer frame is less than the IPv6 MTU of 1280, it will have  
to be the link layer's job to get it there.

On Jun 17, 2009, at 7:55 AM, Alexandru Petrescu wrote:

> 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
>
>