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: [email protected]
Cc: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
