Hi Carsten; Thanks for the pointer, it's all the more interesting that tools.ieft.org fails to refer it. I'll update the fragment recovery draft with the proper reference.
Now I fail to gather your conclusion: Do you mean that applications should refrain from sending more than 80 bytes at a time to avoid 6LoWPAN fragmentation to occur? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:[EMAIL PROTECTED] >Sent: lundi 16 juin 2008 15:40 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Geoff Mulligan; Jean Philippe Vasseur (jvasseur); 6lowpan >Subject: Re: [6lowpan] New charter text: fragment recovery item > >On Jun 16 2008, at 10:51, Pascal Thubert (pthubert) wrote: > >> http://tools.ietf.org/html/draft-mathis-frag-harmful > >Which has since become RFC 4963, "IPv4 Reassembly Errors at High Data >Rates". >Mandatory reading in some of our classes (see also RFC 3819, for a >more general overview of L2/L3 issues), but kind of less relevant for >IPv6. > >(PLPMTUD is RFC 4821, but doesn't really help with the 6lowpann issue, >because the IPv6 MTU *MUST* be >= 1280, and we would prefer >applications to stay well below that -- there is no easy way in IPv6 >to tell them.) > >The situation right now (RFC 4944) is that applications just have to >know that large packets will have bad performance. >This is a classical case of the L2/L3 not being able to tell L4/L7 >something it needs to know. >Fortunately, many 6lowpan applications will run custom protocols on >top of UDP, so they can keep this under consideration. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
