RE: [rohc] Update of ROHCv2 profiles draft

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

Hi Biplab,

I'm not sure I understand your concern here. If the problem is the
pre-link reordering (negative jumps in the absolute values), then
shouldn't it be the "p" value (offset) part of the LSB encoding that
should be changed and not the "k" (#bits)?
Also, since both the TS and the IP-ID are encoded from the MSN 
(RTP SN) then "negative jumps" in these values should be handled by
the MSNs LSB endcoding if the TS/IP-ID has not changed its relation
to it. So then maybe it is more MSN bits that you need? 

To me, the reason for increasing the k-value should be that you see
very long jumps in the TS value that cannot be compressed
with 8 bits of TS (e.g. after a silence period in a codec that does
not send SID frames) .

So, could you explain a bit more when and why you need to choose
larger k-values for these field so we can get a better understanding
of what you want to adress here (i.e. how do the SN and TS change in
the situations you see a problem with)?

BR,
   Kristofer

Sarkar, Biplab <mailto:[e-mail]> wrote on den 27 maj
2007 16:45 :

> Kristofer/Ghyslain,
> 
> I think the draft should also consider the "out-of-sequence"
> delivery of
> packets at the input of the compressor. Since it's a very common
> scenario in the network, we need to address these scenarios more
> efficiently. Current draft has incorporated 8-bits for ts_scaled in
> pt_2_seq_both format. I would suggest making this ts_scaled
> variable in
> size, to the maximum of 16-bits. I have seen that often we have to use
> UOR-2-TS-Ext2 to incorporate about 10-bits with typical WLSB-sliding
> window size of 6. I would also suggest similar size for ip_id
> too. This
> way one generic packet will be able to do all these multiple roles.
> 
> Thanks
> Biplab
> 
> -----Original Message-----
> From: Kristofer Sandlund (LU/EAB)
> [mailto:[e-mail]]
> Sent: Friday, May 25, 2007 12:18 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
> 
> 
> "This email message and any attachments are confidential
> information of Starent Networks, Corp. The information
> transmitted may not be used to create or change any
> contractual obligations of Starent Networks, Corp.  Any
> review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon this e-mail and its
> attachments by persons or entities other than the intended
> recipient is prohibited. If you are not the intended
> recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> [e-mail] -- and destroy all copies of
> this message and any attachments without reading or
> disclosing their contents. Thank you."

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