Hi Pascal and Richard,
Since we are going down this path, I'd like to agree on what the
6lowpan ack/frag mechanism should provide before we get into the
details of bits/bytes. Let me throw out my preferences:
- Ability to ACK/NACK and 6lowpan packet, whether or not it is
fragmented. The NACK is really useful to explicitly indicate that the
receiver does not currently have the buffer space to store the 6lowpan
packet.
- Ability to carry arbitrary payloads in the ACK/NACK. There have
been many times in the past where being able to piggyback information
on the ACK/NACK can be helpful. We would probably initially define a
SNACK option, but I'd really like to keep it general enough so that we
aren't stuck with whatever we define immediately.
- Carry a 6lowpan packet sequence number/tag separate from the MAC
header to assist in identifying 6lowpan fragments/packets as well as
suppressing dups.
- Maintain backwards compatibility with the existing RFC 4944 fragment
header.
Thoughts on the above?
--
Jonathan Hui
On Feb 19, 2010, at 7:06 AM, Pascal Thubert (pthubert) wrote:
Hi Richard:
>>
>> 1) why do you desire to suppress alignment?
> Because requiring the fragment offset be aligned on an eight-byte
boundary adds complexity and wastes payload.
How, that much we agree upon. But on your example you had the
datagram_size over a DWORD barrier and I think that can be an issue.
>> 2) The ack is in the fragment header, so how'd you ack a non
>> fragmented packet?
>What do you mean by "the ack is in the fragment header"?
>The ack is its own dispatch type, distinct from the fragment
dispatch.
I see. So you’d use a new dispatch to make any packet ackable.
Looks good to me. Do you have details on problems that this solves?
As I had before, we need the capability to inform of congestion and
error. In particular propagate a NACK to a source.
Cheers,
-Richard
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
