Subject: Re: [6lowpan] Size of datagram_tag field in Fragmentation Header

From: gabriel montenegro <[email-masked]>
Date: Thu, 15 Mar 2007 10:31:13 -0700 (PDT)

I would go ahead and grow the datagram_tag by the full 8 bits in the new octet as shown below. We have not needed
these reserve bits so far, and what we're currently addressing is the need to grow the datagram_tag space. So I'd 
recommend sticking to just that and putting this fear of wraparound to rest for good.

-gabriel

OLD:
                           1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 0|    datagram_tag   |    datagram_size    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 10: First Fragment

to this:

NEW:
                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 1|             datagram_tag          |    datagram_size    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 10: First Fragment
And similarly for
 the subsequent fragments:

NEW:

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 1|             datagram_tag          |    datagram_size    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |datagram_offset|
      +-+-+-+-+-+-+-+-+

                      Figure 11: Subsequent Fragments

----- Original Message ----
From: Geoff Mulligan <[email-masked]>
To: 6lowpan <[email-masked]>
Sent: Thursday, March 15, 2007 12:22:49 PM
Subject: [6lowpan] Size of datagram_tag field in Fragmentation Header

We received feedback during the IESG review and IETF last call about the
size of the datagram_tag field.  A concern was expressed over the
limited size of the field.  With only 10 bits and a perfect link it is
possible that the value would wrap in 60 seconds, which is the IPv6
timeout.  In order to deal with this, we are looking at adding another
byte to the header.  From my calculations below, even if we take into
account support for higher speed phy's (802.15.4a / UWB) we do not need
to assign all 8 bits of the added byte to the datagram_tag.  At most we
must add 4 bits.

The question is not about WHETHER we should add the byte, it seems clear
that it is necessary, unless someone in the group has information or
calculations that are different.  The overhead of adding the byte is
only for fragmented packets and the "cost" (the two extra bytes) is
amortized over at least 164 bytes. 

The question IS about should we allocate the entire extra byte to the
datagram_tag field or should we reserve some bits for future use.
Usually reserving bits is a good thing, but in this case since the
header is specific to fragmentation, I'm not sure I see the utility -
what might we use the extra bits for.

Here are my calculations for the current 15.4 radios running at 250Kbps:

First packet - 133 bytes including the PHY
Second packet - 31 bytes including the PHY
Clear channel assessment and Start-up - 400 bytes (in time)
Total byte time to transmit 2 packets is:
  400 + 133 + 400 + 31 = 964 bytes (in time)

250 Kbps => 964 * 8 * 1024 / 250000 = 31 seconds (rounded down)

We really only need 1 more bit.

For developing 15.4a UWB radios with a phy of 2Mbps (the assumption here
is that the CCA and start-up times for 15.4a radios will be comparable
to 15.4b radios):

2 Mbps => 964 * 8 * 1024 / 2000000 = 3 seconds (rounded down)

We would need 4 more bits.

    geoff

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

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

---

From: Philip Levis <[email-masked]>
Date: Fri, 16 Mar 2007 09:53:25 -0700

On Mar 15, 2007, at 10:31 AM, gabriel montenegro wrote:

> I would go ahead and grow the datagram_tag by the full 8 bits in  
> the new octet as shown below. We have not needed
> these reserve bits so far, and what we're currently addressing is  
> the need to grow the datagram_tag space. So I'd

I agree with Gabriel's comment. Better to pick a safe but not  
exorbitant bit width, so that we don't have to add undue complexity  
to deal with unforeseen edge cases in the future.

Phil