Hi Jonathan:
I agree we need to maintain the datagram tag to at least 16 bits.
Another (key for me) reason is its potential use as a label for label
switching fragments in a route over model.
Please find below the exercise of picking your proposal of 11 for
fragments applied to the frag recovery draft. I agree with Dario that we
should reserve 11X00 to avoid confusion, at least for a while. That
could give us:
Forward 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 F A 1| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sequence | datagram_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where F would be (reserved for) Forward ECN and A ACK requested
Reply/ACK:
----------
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 B 1 0 0|siz| datagram_tag | Ack Bitmap ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where B would be (reserved for) Backward ECN, R set if error, and size
used to encode the ack bitmap size (1 to 4 bytes).
The cool thing is that we do not need the complex bitmap encoding that
was introduced recently to we could ack up to 32 fragments.
Reply/NACK:
-----------
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 B 1 0 1|rsv| datagram_tag | error code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
What do you think?
Pascal
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Jonathan Hui
Sent: Thursday, February 18, 2010 10:49 PM
To: Dario Tedeschi
Cc: [email protected]
Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions
Hi Dario,
I support the effort to make the offset field be in units of single
octets, rather than 8 octets. Though we need to be careful about
shrinking the tag field. Earlier drafts of RFC 4944 originally made the
tag field 10 bits, but some comments from IESG review raised concerns
about whether that was enough. After some discussion on the list, the
decision was made to expand the field to 16 bits (though only 14 bits
was necessary at the time) [1]. The key point is that
802.15.4 may operate on different PHYs with higher bit rates so we
should be prepared for those.
In my ideal world, we would reallocate a single fragment header type for
simplicity. I'm not concerned about backwards compatibility given that
we are changing the entire HC format. And little has been done in the
way of multi-vendor interoperability with the existing formats. In that
case, we include the tag, size, and offset fields in every fragment
while keeping the tag 16 bits and others 11 bits. The header type would
remain at two bits with '11'. Eliding the offset field in the first
fragment doesn't give much added benefit.
To me, the above is the most straight-forward approach - maintaining
most of the existing format structure, while at the same time
simplifying it and avoids revisiting the same IESG concerns we've had in
the past.
An alternate approach is to pick up on existing work to redesign the
fragmentation layer to support more efficient fragment recovery and
out-of-order delivery, but that would require a bigger change. I'd echo
Pascal's request to get additional thoughts there.
[1] http://www.ietf.org/mail-archive/web/6lowpan/current/msg00588.html
<http://www.ietf.org/mail-archive/web/6lowpan/current/msg00588.html>
--
Jonathan Hui
On Feb 18, 2010, at 1:07 PM, Dario Tedeschi wrote:
> Richard and Owen,
>
>>
>>> I think that the best solution would be to switch to using the
>>> compressed size and offsets in the fragment headers.
>>> This would allow (un)compression and (de)fragmentation to be done
>>> independently.
>>>
>> I absolutely agree.
>>
> I agree.
>
> I think it should be simplified further by making datagram_offset
> 11bits long. Having datagram_offset as 8bits (forcing fragment length
> to a multiple of 8) may save 1 byte, but it also means that up to 7
> bytes at the end of a fragment can be left unused (save 1 byte to,
> potentially, lose 7). So how about a new fragmentation header where
> both datagram_size and datagram_offset are 11bits and the datagram_tag
> is reduced to 13bits (how big does the tag need to be anyway). A new
> dispatch pattern would indicate a new fragmentation header where
> _offset and _size are relative to the compressed datagram. Something
> like the following:
>
> 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 2 3
> 4 5 6 7 8 9
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+-+-+
> |1 1 1 1 1| datagram_size | datagram_tag |
> datagram_offset |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+-+-+
>
>
> From an implementation point of view, bits 0 to 28 can be used as a
> pseudo tag in identifying fragments that belong to one datagram. It
> could be stored in 4 bytes with the last three bits of the last byte
> masked out, but that's just an idea for trying to be a little more
> efficient.
>
> Regards
> Dario
>
>
> _______________________________________________
> 6lowpan mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/6lowpan
<https://www.ietf.org/mailman/listinfo/6lowpan>
_______________________________________________
6lowpan mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6lowpan
<https://www.ietf.org/mailman/listinfo/6lowpan>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
