--- Vipul Gupta <[EMAIL PROTECTED]> wrote: > I couldn't find an easy way to search the archive > for prior discussions on this topic but the > datagram tag size of 7 bits seems too low to me.
Don't think there's been any discussion on this topic. > The max data rate for 802.15.4 is 250kbps. > Of this, lets assume that one only achieves about > 128kbps or 16KBps. At this rate, an application could this rate sounds reasonable as a maximum actual throughput (assuming ACKs being turned on). > potentially be pumping out 128-byte packets (this > is long enough to cause each packet to be fragmented) > at the rate of 128 packets per second and cause the > tag field to rollover every second. So to avoid any > potential of confusion due to tag reuse, one would > have to assume that packets do not stay in the > multihop network for more than a second or so. This > expectation seems unreasonable (especially > for a reactive routing protocol where route discovery > alone might take this long). does sound unreasonably short. one could also say that no matter how much we decide to grow the tag field, after a certain rate, the fragmentation and reassembly services of the adaptation layer do not apply anymore. apps that spew out more than a certain volume of traffic (TBD) would then have to provide fragmentation and reassembly at their layer. notice that they could continue using mesh delivery, they would just spew out "unfragmented" (at the lowpan layer) packets. The issue is, as always, one of tradeoff. should we specify a field that will be future proof and cover all possible cases? with 15.4a's defining two new PHYs (UWB and "chirp" spread spectrum), who knows what rates we might have. i've heard that anything from 50kbps up to 1Mbps or so is possible. could anyone who follows 15.4a confirm? let's say it's 1Mbps. this means that even if we grow the tag to 10 bits, we'd see a rollover about every second. we could, on the other hand, simply grow it to, say, 16 bits for a rollover every minute or so at 1Mbps (someone check the math). depending on the mesh, one minute may be cutting it short as well, given store and forwarding, transient network partitions, etc. heck, might as well grow it to 32 bits and be done with it. sure, that imposes quite an overhead over apps that cause fragments to occur. But, if so, they *deserve* it (one could see this as the "fragmentation tax"). This fragmentation and reassembly capability is supposed to be used sparingly (if at all), so any overhead to the fragmentation packets does not apply normal operation. just some thoughts. what do others think? -gabriel _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
