Subject: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt)

From: Vipul Gupta <[email-masked]>
Date: Tue, 18 Oct 2005 14:53:51 -0700

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.

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
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).

thoughts/comments?

vipul

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 19 Oct 2005 10:14:15 +0900

> alone might take this long).

Interesting point, but I am really not sure how often the tag field reuse happen in 6lowpan scenarios. The major applicable connectivity amongst 6lowpan nodes are simple control. Anything else ?

Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 18 Oct 2005 18:34:08 -0700 (PDT)

> datagram tag size of 7 bits seems too low to me.

Don't think there's been any discussion on this topic.

> 128kbps or 16KBps. At this rate, an application could

this rate sounds reasonable as a maximum actual throughput
(assuming ACKs being turned on).

> 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

---

From: Vipul Gupta <[email-masked]>
Date: Tue, 18 Oct 2005 21:48:19 -0700

On Oct 18, 2005, at 6:14 PM, Soohong Daniel Park wrote:

> Interesting point, but I am really not sure how often the tag field 
> reuse happen in 6lowpan scenarios. The major applicable connectivity 
> amongst 6lowpan nodes are simple control. Anything else ?

   You are certainly correct in the assumption that many applications
   are unlikely to involve high data rates (at least not all the time).
   However, there are several applications (e.g. structural monitoring
   etc.) where an application keeps collecting sensor readings until
   some application specific buffer is full and then turns on the radio
   and to send data back to a central collection site.

   In such "bursty traffic" scenarios, tag rollover could be an issue
   even though the "average" data rate is very low.

   vipul

---

From: Vipul Gupta <[email-masked]>
Date: Tue, 18 Oct 2005 21:57:28 -0700

Given that IPv4 has managed to do fine with a
16-bit identifier, I'd say this size represents a
reasonable compromise.

vipul

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 19 Oct 2005 12:33:34 -0700 (PDT)

> Given that IPv4 has managed to do fine with a

I wouldn't necessarily say that IPv4 is fine with only 16 bits.
This is a known issue. See for example:

http://www.watersprings.org/pub/id/draft-mathis-frag-harmful-00.txt

And some updated discussion in the context of tunnels in:

http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunneling-05.txt

> 16-bit identifier, I'd say this size represents a

16 bits would buy us over a minute at 1Mbps (dunno if this is a possible rate
in the future, though). For comparison, RFC 1122 (3.3.2  Reassembly) requires 
that the IPv4 reassembly timeout be between 1 and 2 minutes. Not sure what is
reasonable for us to drive for. 

Given that these puny devices have to put out all that traffic, do we understand the
system implications of such a feat? How reasonable is it to expect the required buffer
space, bus bandwidth (I2C, etc) on these platforms to sustain that level of offered 
traffic? Of course, one can always 15.4-enable a regular computer, in which case
such sustained throughput is not an issue. However, I wouldn't know the difference
between this scenario and a "denial of service" attack...

Frankly, I don't loose much sleep over this, and would be fine even at less than 
16 bits. For example, even if 1 Mbps were possible with 802.15.4a (my guess
is that we won't have that) it would represent 512K max, by the same reason that 
802.15.4's "250Kbps" becomes a max (perhaps unattained) of actual 128Kbps on the wire, 
If so, 15 bits is fine and would give us over a minute before rollover at 512K.

If we just look at the packet formats, and extrapolate, here's an example of what
one might end up with:

Format 2:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|      prot_type      |M|   datagram_size     |datagram_tag |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | datagram_tag  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Format 3:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|   datagram_offset   |M|   datagram_size     |datagram_tag |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | datagram_tag  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What do folks think?

We haven't discussed at all about alignment issues (perhaps a discussion
to have with respect to IPv6 header alignment requirements, implications
and what we wish to do about it), but the above keeps
an octet alignment. Typical radio chips will read in min 1 octet most
probably 2 octets at a time, I believe.

Comments?

-gabriel

---

From: Vipul Gupta <[email-masked]>
Date: Wed, 19 Oct 2005 13:09:54 -0700

15 bits should be ok for the data rates we are dealing with
and still support reassembly timers in the order of 1min.
However, if we need an extra bit, one could possibly take
that from the prot_type and the datagram_offset fields
(for the latter one could use a mechanism similar to what's
used in IPv4 and IPv6 and specify the offset in 2 byte
units -- IPv4 and IPv6 use 8-byte units).

It might also make sense to reserve a portion of the prot_type
space for private use among consenting parties. Has there
been any discussion on including a version field in the
LowPAN header for future extensions (it could be fairly
short 2-4 bits)?

vipul

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 19 Oct 2005 15:16:09 -0700 (PDT)

> LowPAN header for future extensions (it could be fairly

If one were to do both (add a fixed version field, say 2 bits, and
add one bit to the datagram tag), we'd need 3 bits in header formats
2 and 3, where both the version and the enlarged datagram tag appear.

In the header formats 1 and 2, these 3 bits could come from the protocol type
(reducing to 8 from 11 bits, which is still enough, I think), and in 
header format 3 they'd come from the datagram tag (meaning we'd specify
offsets in 8 octet units). Here's what formats might look like:

Format 1:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|Ver|  prot_type    |M| rsv |Payload (or Mesh Delivery Hdr)... 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Format 2:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|Ver|  prot_type    |M|   datagram_size     | datagram_tag...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |...datagram_tag| Payload (or Mesh Delivery Hdr)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Format 3:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|Ver|datagram_offset|M|   datagram_size     | datagram_tag...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |...datagram_tag| Payload (or Mesh Delivery Hdr)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

protocol type and datagram offset now at 8bits
datagram tag now at 16 bits

Comments?

-gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 19 Oct 2005 15:32:23 -0700 (PDT)

--- gabriel montenegro <[email-masked]> wrote:
> bla, bla, ...
> ...

Actually, the Ver(sion) field would probably preced the LF field.
Something that bothers me is the question of co-existence with, say, 
Zigbee, which also layers itself on top of 15.4 directly.

In a LoWPAN network, when looking into the 15.4 payload, the first bits
one would see would be the 'Ver' bits (presumably 0 for this first version).
If a Zigbee network were to overlap (perhaps on purpose for dual-stack devices),
I don't know what those first bits would be. 

So, while 'Ver' bits are fine in that they allow us to multiplex among the
different versions of the lowpan encapsulation, it would be good to also be
able to multiplex among the different types of 15.4 payloads (e.g., zigbee vs.
lowpan). I don't include proprietary schemes, cuz they are so for a reason,
and are definitely the majority now, and perhaps will remain so. Impossible to
coordinate with all of them.

But do folks see how one might be able to coordinate with zigbee? 

-gabriel

---

From: Samita Chakrabarti <[email-masked]>
Date: Sun, 23 Oct 2005 00:57:00 -0700

I am not quite clear on the need of version for lowpan layer ; how are other
ipv6 over protocol foo defined in this respect? 
Also,  datagram tag size  increament  to 16bits does not seem to be a
clear need to me.  I am not sure if  there is a need for  fragmentation
tax. Today folks run IP datagram over 10Gb/s ethernet, but  IP 
identification
fileld size is not changing. We need to be very sure that the datagram tag
rollover is an issue before  increasing  bit numbers in the lowpan header.
BTW,  currently protocol field is 11 bits - we should reduce that number
to 8 bits. We may want to use 1 bit  (8bit +1)  in highest order bit, to 
indicate
private or standard protocol-type if  folks think that might be useful.

IMHO, we need more discussion and input from folks before changing
the tagsize to 16bits. My recommendation would be to start with  the current
size and change later if needed based on implementations input , ie, when
we have more experience with IPv6 over lowpan.

Thanks,
-Samita

---

From: gabriel montenegro <[email-masked]>
Date: Sun, 23 Oct 2005 13:40:33 -0700 (PDT)

Hi Samita,

> ipv6 over protocol foo defined in this respect? 

Good question, you might want to look over those specs, but I don't recall
ever seeing a version number. If a future rev of 15.4 (e.g.,
15.4-on-steroids) ever makes it obvious that a new adaptation layer
is needed, then instead of handling this via version numbers on the
current spec, one could simply issue another document specifically
for 'IP-over-15.4-on-steroids". Achieves the same thing without wasting
bits on version numbers.

> fileld size is not changing. 

Good point, I don't see a need for this to grow much either.

> We need to be very sure that the datagram tag

This is the main issue, yes, let's not get too aggressive on over-engineering
in advance. 

> to 8 bits. 

Ok, let's do this.

> We may want to use 1 bit  (8bit +1)  in highest order bit, to 
> indicate

I don't think this is useful. Private or proprietary encapsulations are the
majority (and will continue to be so according to some folks) and these precisely
couldn't care less about interoperability with anybody cuz they have their own
isolated network. This bit would remain unused. 

As for interoperability with zigbee, I'm thinking that the fact that most of these
applications will (hopefully) use some link-layer (15.4) security, means that as long
as you don't use the same keys for both lowpan and zigbee, you won't even get a chance
of being confused. This multiplexing will be achieved by traffic separation due to
different
keying. So I'm thinking that there isn't much to do here either.

> we have more experience with IPv6 over lowpan.

Looking at the previous proposed formats I sent on this thread,
how about using the 2 bits from the "Ver" field and assigning them to
the tag size (to grow it from 8 to 10 bits)? This is what I propose:

prot_type: 8 bits
datagram_size: 11 bits
datagram_tag: 10 bits
datagram_offset: 8 bits (offsets expressed in increments of 8 octets)

Format 1 (unfragmented):
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|  prot_type    |M| rsv     |Payload (or Mesh Delivery Hdr)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Format 2 (first fragment):
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|  prot_type    |M|   datagram_size     | datagram_tag      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Payload (or Mesh Delivery Hdr)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Format 3 (middle or last fragment):
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|datagram_offset|M|   datagram_size     | datagram_tag      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Payload (or Mesh Delivery Hdr)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This is what I'll put into the draft before submission, unless I hear
strong opposition, ok?

-gabriel

---

From: Vipul Gupta <[email-masked]>
Date: Sun, 23 Oct 2005 17:26:57 -0700

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
no place in the 802.15.4 header to describe the higher
protocol type (ethernet, in contrast, does have such a
field).

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).

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
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).

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.

vipul

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 24 Oct 2005 00:34:29 -0700

> bits spent on the version or the tag are minuscule.

While supporting 16bit short addresses are a great idea for saving bits 
in case
of multihopping, the draft  will need to consider the 64bit addresses as 
well.
There will be some devices that will use 64bit  link-layer addresses and 
stlll
want to do multihopping and  fragmentation.  I believe ZigBee devices also
support 64bit  addresses.

-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 24 Oct 2005 01:16:10 -0700

> This is what I propose:
Seems OK to me.

Thanks,
-Samita

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Oct 2005 15:44:37 -0700 (PDT)

Vipul,

> 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.

> 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?

> a new underlying protocol (all versions of SSL and

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.

> 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. 

>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).
 
> 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

---

From: Vipul Gupta <[email-masked]>
Date: Mon, 24 Oct 2005 16:51:35 -0700

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

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Oct 2005 23:36:13 -0700 (PDT)

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