[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rohc] Re: More comments on ROHCv2 profiles draft
Hi Kristofer,
Sorry for the my delayed reply.
more comments inline...
Kristofer Sandlund (LU/EAB) wrote:
> Hi Calle,
>
> sorry for the delayed reply. I agree to the cut&paste issue about the
> CRC option, so that will go away.
>
Good!
> 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.
>
This addition will improve the draft. I like the addition of the "Acknowledgment
Number".
> - 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
>
Yes, I agree that it should be "lsb the MSN" (or maybe Acknowledge number,
whichever suits you best). The Compressor may have more references depending on
its updating strategy. How the compressor updates the context and the information
it keeps for every packet is out-of-scope of this draft, so it should be left out.
I wasn't expecting an exact description like FN, so I agree with this wording...
> - 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.
>
No interplanetary solution!! Throwing away an old ROHC tradition just like that :)
14 bits will probably be sufficient. Let's remove the MSN option..
> 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.
>
I agree.
/Calle
> 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