Good points, thanks Vipul. Just to clarify, the latest draft (the one submitted) has a tag field of 10 bits, no 8. By the way, I added a retransmission timeout of 15 sec (took it out of a hat). Seems to be reasonable, in particular seeing your calculations below. But please check and comment.
-gabriel --- Vipul Gupta <[EMAIL PROTECTED]> wrote: > Hi Gab, > > I've been thinking some more about the fragmentation issue and > have managed to convince myself that the tag size in the latest draft > (of 1 byte) is adequate :-) My initial analysis assumed two things: > > 1. That the application would be pumping a lot of data > over a short period of time > > 2. It would do so using a fairly small packet size that is still > large enough to cause fragmentation (e.g. the analysis > assumed 128 bytes). > > We do see 1 on our network already, for example, when over the > air reprogramming is involved and we send 10s of KBs of code. > However, in such situations, an application is also likely to use > large packets -- closer to the 2KB max. (I couldn't think of any > realistic situations where 1 and 2 both apply simultaneously). > > If we change 2 to assume large packets, the analysis changes > quite a bit. Assuming 1-2KB packets, 8-bit sequence numbers > will roll around only after an application has pumped out > 256-512KB of data which, at 250kbits/s (or more realistically > ~16KB/s), would take about 16-32 seconds -- reasonable > enough for a reassembly timer. In reality, these values might be > even higher because few sensors (the Sun SPOT being an exception) > have enough memory to buffer 256-512KB of data. > > vipul > > On Oct 24, 2005, at 3:44 PM, gabriel montenegro wrote: > > > Vipul, > > > > --- Vipul Gupta <[EMAIL PROTECTED]> wrote: > >> If we assume that the LowPAN design this group comes up > >> with will only need to be revised when a new lower layer > >> is designed, then yes there is no need for version numbers. > >> > >> However, if there's even a small chance that, based on > >> deployment experience, we may revise the LowPAN > >> header format while still wanting to run it on top of the > >> same lower layer then I don't see how the recipient > >> would figure out how to interpret the received packet > >> without a version number. From what I can tell, there is > > > > Yes, there is that risk. I guess the more complex an encapsulation, > > the more justifiable it is to have a version field. > > > >> no place in the 802.15.4 header to describe the higher > >> protocol type > > > > Correct, 802.15.4-2003 does not. But as an 802 technology, you're > > supposed to use > > 802.2 LLC (section 5.3 in the 15.4 spec), which we've abandoned > > because of its overhead. > > Instead, we provide our own protocol field within the lowpan layer. > > > >> (ethernet, in contrast, does have such a > >> field). > > > > Well, the 802.3-2002 spec talks about a Type/Length field. > > When one uses the "ethernet II" frame format, this field > > is interpreted as "Type", so what you say is true. But when you > > use the other available formats (802.3, 802.2 LLC, SNAP/RFC1042) > > then this field is interpreted as "Length". In these cases, the > > ethernet frame does not have such a type field, and this is > > left to the higher layer encapsulation, e.g., 802.2 LLC or > > the LLC-derived SNAP encapsulation. > > > > Notice that none of the basic ethernet frame, LLC or SNAP have a > > version field. > > > > Our LoWPAN encapsulation is somewhat similar in function to > > the 802.2 LLC. It is a bit more complex. A much closer analogy is the > > encapsulation format defined in section 4.2 of the "IPv4 over IEEE > > 1394" > > (RFC 2734) spec (not suprisingly, as this was the model for our > > adaptation > > layer at the start). Again, this encapsulation does not have a version > > field > > either. > > > > So I wonder, if a version field was deemed superfluous for all the > > above > > encapsulation formats (which did not have the stringent constraints we > > do), > > why would it be justified in our case? Our complexity is similar to > > that > > of the encapsulation for IEEE 1394. One thing we do in addition to > > what they > > do is have a mesh header. Is this additional complexity enough to > > justify adding > > a version header? > > > >> Perhaps the following example will make things clearer. > >> Because SSL includes a version number, the IETF was > >> able to define TLS and now TLS 1.1 without requiring > >> a new underlying protocol (all versions of SSL and > >> TLS run atop TCP). > > > > Like I said, the more complex an encapsulation, the more chances you'll > > want a version field in there. For higher layer protocols like HTTP, > > TLS/SSL, SSH, etc, you definitely want one. No question there. But > > protocols > > at those layers are hardly applicable to what we're doing. When I look > > at > > what I believe is applicable (frame formats as discussed above), I > > have not > > seen version numbers. Perhaps we've just added enough complexity to > > just > > tilt the balance enough that we should use one. Not sure yet. I'd > > certainly > > like to hear from implementors and people deploying this stuff. I > > didn't add > > the version field before this submission cuz I think we need more > > discussion > > (and frankly, cuz I didn't have time). > > > > Let's discuss some more. > > > >> It seems like a prudent tradeoff to me to spend 2 bits > >> for the ability to later revise LowPAN (based on deployment > >> experience) without requiring a new lower layer. > >> > >> As for the tag size, I think 7 bits is still too low (based on > >> the previously posted analysis). If the general consensus > > > > That analysis is a theoretical one. I'm quite unconvinced that we'll > > ever hit this in practice given the type of applications that 15.4 is > > for (after all, the max frame size is remarkably puny). I think before > > over-engineering this is one point that requires input from folks > > actually > > deploying (hopefully comercially) 15.4 networks. > > > >> is to bump it to 10 and wait for deployment experience > >> before changing it to a higher value, that's fine (at current > >> data rates, 10 bits would allow for a reassembly timeout of > >> around 8 seconds which might be ok). > > > > From RFC 2734 I note that the 1394 encapsulation uses a datagram tag > > length of 16 bits. > > Comparing with the lowest speed or 100Mbps in RFC 2734 (with an MTU of > > 512 octets), it > > seems like there's a factor of slightly under 2^8 as compared to > > 802.15.4's > > expected max throughput of 125Kbps at 128 octets MTU. If so, and given > > that > > 1394 is *MUCH* more probable to transfer long packets than 802.15.4, > > I'd say for us a datagram tag of 8 bits is at least equivalent (and in > > reality much safer, given expected usage) than their 16 bits. > > > > In keeping with this reasoning, and if we determined that a version > > field was useful, > > I'd suggest taking 2 bits from the tag (bumping it down to 8 bits as > > per the previous > > paragraph). > > > >> In terms of saving bits, supporting short addresses > >> provides the biggest bang for the buck -- instead > >> of carrying two 8-byte addresses across each hop > >> (for a multihop pkt), carrying two 2-byte addresses > >> saves 96 bits. Compared to this, the extra few > >> bits spent on the version or the tag are minuscule. > > > > Agree, small addresses are the best bang for the buck. The latest > > version of > > the draft supports these. But I don't think we can claim that by doing > > so we > > are being particularly good citizens. This is a savings enabled > > fundamentally by the 802.15.4 spec regardless of us. > > > > On the contrary, *not* supporting short addresses > > would have made us bad citizens. We only become good citizens by being > > careful about the > > stuff we are adding. That stuff is the fixed overhead in the > > encapsulation formats. > > The first version had very little overhead, and we've been growing it > > slowly. > > > > -gabriel > > _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
