Subject: [6lowpan] Fragment Recovery Discussion

From: "Robert Assimiti" <[email-masked]>
Date: Thu, 7 Feb 2008 09:00:38 -0500

Hello Pascal,

I have a few comments/questions regarding you fragment recovery
proposal. 

In your recoverable fragment header:

Sequence number: At this point the consensus is that fragment sizes are
fixed. This deems the sequence number redundant since you can easily
extract the "sequence" number from the datagram offset, and needs not be
sent over the wireless media.

Fields in re-coverable fragment header: I am wondering what the
rationale is behind changing the order of the header fields:

RFC[4944] -> datagram size, datagram tag, datagram offset

Re-coverable fragment: datagram offset, datagram tag, SEQUENCE (see
above, this is redundant), datagram size.

Any reasons for re-arranging the order of the fields?

Thank you. 

"The nice thing about standards is that there are so many to choose
from." - Andrew S. Tannenbaum 

Robert Assimiti

Executive Staff Engineer

Office: [678]-202-6859

Mobile: [404]-578-0205

[email-masked]

This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.
_______________________________________________
6lowpan mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 7 Feb 2008 16:03:01 +0100

Hi Robert:
 
Thanks a lot for this posting; For all at 6LoWPAN, this is actually a
cross discussion with ISA 100.11a. 

I posted a draft to the IETF on fragment recovery, the draft is not yet
visible from the I-D site so I attach it here for the sake of the
discussion. This draft was discussed inside ISA100 prior to posting to
IETF to get a local agreement prior to widening the discussion. ISA
100.11a members recognize that the work belongs to IETF, and are willing
to help the work happen there. Thus Robert's posting on this list.

 Robert, please see inline

> Sequence number: At this point the consensus is that fragment sizes
are fixed. 
> This deems the sequence number redundant since you can easily extract
the "sequence" 
> number from the datagram offset, and needs not be sent over the
wireless media.

You are talking about an ISA decision to make the MTU size fixed on a
per node basis. My understanding is though we can expect all fragments
in a same datagram (but the last) to have a same size, RFC 4944 does not
mandate it so I think that we can not base our algorithm on this
expectation. 

I could not figure a way to make the recovery FULLY backward compatible
with the existing formats and operations; there are efforts to improve
the draft in that direction and I hope we ultimately succeed. Christos
already proposed acknowledging offsets (TCP-like) to keep the formats
mostly unchanged from RFC 4944. But ths alone does not solve all the
compatibility issues so the draft still uses the simpler approach of
sequence counters. 

rationale is behind changing the order of the header fields:
>	Re-coverable fragment: datagram offset, datagram tag, SEQUENCE
(see above, this is redundant), datagram size.
>	Any reasons for re-arranging the order of the fields?

Sequencinf the fragments needed a new field for an integer [0..31] of 5
bits. This aligns perfectly with datagram_size and saves from eating up
3 bits from the dispatch header. Considering that backward compatibility
was not achieved anyway, I took the liberty to optimize alignments save
on the dispatch header.

Thanks again,

Pascal