[rohc] RE: More comments on ROHCv2 profiles draft

["Kristofer Sandlund (LU/EAB)" <kristofer.sandlund at ericsson.com>]

Hi Calle,

sorry for the delayed reply. I agree to the cut&paste issue about the
CRC option, so that will go away.

Regarding the other issue, me and Ghyslain have discussed this and we 
agree that the feedback parts of the draft lack some information and 
can also use some re-structuring. So, we propose the following changes
to v2:

- The MSN field inside all feedback is renamed "Acknowledgment Number"
which makes it a lot easier to describe what to put in there and also 
makes it easier to see that NACKs also contain ACK numbers.
Concequently,
the MSN-NOT-VALID option is now ACKNUMBER-NOT-VALID. We also add this to
terminology with the following text:
   Acknowledgment Number
      The Acknowledgment Number in ROHCv2 profiles is carried in all
      feedback elements and is used for identifying what packet is being
      acknowledged.  The value of this field is usually set to the MSN
      value of the latest successfully decompressed packet in the flow.

- Text in 6.9.1 is updated as follows:
   The Acknowledgment Number field of the feedback formats contains the
   least significant bits of the MSN (see Section 6.2.1) that
   corresponds to the reference header that is being acknowledged.  A
   reference header is a header that has been successfully CRC-8
   validated or CRC verified.  If there is no reference header
   available, the feedback MUST carry an ACKNUMBER-NOT-VALID option.

- The Ack Number field is just "LSBs" of the MSN and not "LSB encoded 
MSN" (since we're only having one reference, these are actually 
equivalent, but it makes it easier to understand that if we avoid 
the word "LSB encoding" for the field in the feedback element

- We feel that since we have 14 bits of Ack number (MSN) inside 
FEEDBACK-2 and no MSN is longer than 16 bits, the "MSN option" feedback
seems a bit silly. Is there really any case where two more bits would
make any sense (unless we want v2 to support interplanetary ROHC)?
So, we propose to remove this feedback option. The text in 3095 of why
more bits of SN would be needed in feedback really requires the 
decompressor to know about how many packets are sent in each link RTT,
so we do not think this option is useful in any case.

I think the above changes will make it clear how to choose, encode, 
decode and use the sequence number of feedback at both compressor and
decompressor.

Unless anyone objects, these changes go into the next revision of 
the draft

/Kristofer

Carl Knutsson <mailto:carl.knutsson at effnet.com> wrote on den 20 juni
2007 08:50 :

> Hi Kristofer, Ghyslain,
> 
> I found a small issue in the feedback section.
> copy-and-paste? I believe a more
> detailed description of the msn decompression in the feedback packet
> would improve the draft.
> 
> Section 6.9.2.1:
> 	"carrying a REJECT option MUST also carry a CRC option."
> 
> There are no CRC options in ROCHv2 and crc8 is always
> included in feedback-2 packets.
> 
> In Section 6.9.1, it would be nice with a more detailed description
> how the compressor should decompress the msn in feedback packets.
> There are some more places in the draft that describes the msn in
> feedback, but it does not cover the details on how to
> decompress/compress the field other than that it is lsb-encoded. 
> 
> Best regards,
> Carl Knutsson

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc