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
