RE: [rohc] Update of ROHCv2 profiles draft

["Kristofer Sandlund (LU/EAB)" <[e-mail]>]

Hi Rohit,

thanks for your comments. My answers inline.

Kapoor, Rohit <mailto:[e-mail]> wrote on den 12 juni 2007
04:02 :

> Kristofer, Ghyslain,
> 
> Thanks for the updated draft. Pls find few comments below:
> 
> 1) Regarding use of timer-based compression in pt_1_seq_ts, I had
> brought up this issue earlier, but haven't seen any
> resolution for it in
> the current draft.

Since we hadn't decided what to do on that last time we discussed it, I
left the following TODO in the draft:

// TODO:
// - PT_0/PT_1 packets? Use "tbc-optimized" or "msn-optimized"

So it was not forgotten, we just preferred to get out a new revision of
the
draft as soon as we could and let us continue the discussion later.

I will give a more detailed answer on this issue later this week or next
week

> The issue was that timer-based will
> require 5 bits to
> handle a reasonable amount of jitter, but the pt_1_seq_ts
> packet in the
> current draft only has 4 bits. Also, if the number of bits for TS in
> pt_1_seq_ts is increased from 4 to 5, it would still be good for the
> packet size to stay as 2 octets (so that performance of RoHC v2 for
> VoIP-like applications is not worse than that of RFC 3095).
> For this, we
> had also proposed the solution below.
> 
> Quoting from earlier email:
> 
> "The addition of Timer-Based compression (for which TS will require at
> least 5 bits to handle a reasonable amount of jitter) should not cause
> the pt_1_seq_ts packet to exceed 2 octets. To allow this packet to fit
> within 2 octets, I am providing below a suggestion of what packet
> discriminators can look like (if timer-based and pt_0_crc7 are both
> added). 
> 
> pt_0_crc3: "0"
> pt_1_rnd: "10" (1 extra bit for use; TS can have 1 extra bit)
> pt_1_seq_id: "100" (1 extra bit for use; either MSN or IP-ID
> can have 1
> more bit)
> pt_1_seq_ts: "101" (now this has 1 extra bit for TS, making a
> total of 5
> TS bits).
> pt_0_crc7: "1100" (this has 1 less bit now; so maybe MSN can
> be reduced
> to 5 bits, which is still very robust).
> pt_2_rnd: "1101" (1 fewer bit for use; MSN can be reduced from 7 to 6
> bits) pt_2_seq_ts: "11011" (1 fewer bit for use; MSN can be reduced
> from 7 to
> 6 bits)
> pt_2_seq_id: "110100" (2 fewer bits for use, 1 of them due to the
> addition of pt_2_seq_both; both MSN and IP-ID can be reduced by 1 bit
> each) pt_2_seq_both: "110101"
> 
> 
> Note that this is just an example of a solution. Any proposal which
> handles this issue would be OK for me.
> 
> 
> 2) Section 6.8.3.1 says the following:   "The following packet formats
> exist **exclusively** for profiles 0x101 and 0x107" and then
> later also
> "The following packet formats exist **exclusively** for profiles
> 0x102,0x103, 0x104 and 0x108". But, some of the packet
> formats (such as
> pt_1_seq_id) are defined under both of these sentences.
> 

Ok, I can agree the text could use some polishing :)
The point of the text is that the RTP-based profiles contain different
fields
then the others, but I could have phrased it better. Will think of
something
for the next revision.

> 3) ts_stride_value and time_stride_value are defined as:
> 
>          ts_stride_value: This parameter is set to a
> user-selected value
>          that is the expected increase in the RTP Timestamp between
>          consecutive sequence numbers.  See also Section 6.6.8.
> 
>          time_stride_value: This parameter is set to a user-selected
>          value that is the expected inter-arrival time between
>          consecutive packets for this flow.  See also Section 6.6.9.
> 
> Are these intended to be user-selected values?

Yes, they are "user-selected" the same way they are that in 3095 in the
sense that they can be set to any value independent of what is in the
packet
stream (of course, there are just a couple of values that would make for
efficient compression). But maybe the word "user" is not the best word
to
use here, since it might be interpreted by some as if it is set up
during
configuration while it is *usually* set by inspecting the flow over
time.

Do you have any suggestion for a better phrasing?

/Kristofer

> 
> Thanks,
> Rohit
> 
>> -----Original Message-----
>> From: Kristofer Sandlund (LU/EAB)
> [mailto:[e-mail]]
>> Sent: Thursday, May 24, 2007 11:48 PM
>> To: [e-mail]
>> Cc: Ghyslain Pelletier (LU/EAB)
>> Subject: [rohc] Update of ROHCv2 profiles draft
>> 
>> Hi all,
>> 
>> we have just sent in an update of the profiles draft which
>> mostly contains the changes discussed on the list towards the end of
>> last year. The draft should be announced within the next couple of
>> days as usual. Here is a list of changes since the previous revision.
>> 
>> Changes in the FN code (packet formats):
>> - Lots of minor typos and smaller bug fixes related to FN syntax
>> - Fixes to scaled encoding and MSN handling
>> - Style-related cleanup to make the code more consistent
>> - Addition of many ENFORCE-statements to make the code more formally
>> correct 
>> - Added a co_repair format for all profiles which is bitwaise very
>>   similar to co_common (so it should be very easy to implement), but
>>   has the possibility of sending all LSB-fields as
>>   uncompressed (should be seen as an IR-DYN replacement)
>> - Repair-specific irregular chain items added in order to make
>>   context repair for outer headers, including extension headers, but
>>   have LSB encoded fields sent uncompressed
>> - Optimized the co_common formats with
> "meta-discriminators" in order
> to
>>   reduce the flag overhead
>> - Added timer-based compression (this still needs to be added to the
>>   text where we just have a placeholder section for now)
>> - Fixed ESP static chain so encrypted and null-encrypted static
>>   chains can be discriminated from each other
>> - LSB-offsets are made much more consistent throughput the formats
>> - Header chain termination for IP-only profile (different static
>>   chain items if this is the terminating IP header)
>> 
>> Changes to the text:
>> - Text on scaled encoding re-written and improved
>> - External arguments to the FN code section added
>> - Design rationale for the packet formats section added
>> - Text on state logic improved
>> - Clarifications around the unidirectional/bidirectional operation
>> - Added new feedback option for requesting update of control fields 
>> (to be used with NACKs) 
>> - Update of Appendix A (field classifications) which was previously
>>   imported from RFC3095 and contained a bunch of errors
>> - Removed Appendix A.3
>> - CRC algorithm and demo are now in framework, so it is removed from
>> this draft 
>> - Added section about handling reordering
>> - Removal of the IR-DYN packet format from all these profiles
>> 
>> The draft still needs some more work in a few areas, but we are
>> getting closer to finalizing this work now, so we would be very
>> grateful 
>> if you read and comment on this draft so that it contains what you
>> expect it to. 
>> 
>> Thanks to all the people who contributed on the list to the
>> discussions on this draft! 
>> 
>> /Kristofer & Ghyslain
>> 
>> _______________________________________________
>> Rohc mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc