RE: [rohc] Update of ROHCv2 profiles draft

[Biplab Sarkar <[e-mail]>]

Kristofer,

Sorry for the confusion. I was trying to use timer based compression and
I observed that some of the packets arrive too late. Hope Rohcv2 is
still supporting Timer based compression (6.6.9).
Since we want to avoid sending too many Ext3 packets we try to send as
many packets using the current value of TIME_STRIDE. This results in
going for larger value of TS bits. I believe the problem is more
prominent in Timer based compression. As long as the packet arrives
within the constraints of the permitted jitter we can use the same value
of TIME_STRIDE and compress the TS field. Now the problem comes in
getting the desired packet to carry the compresses TS bits. 
I  am yet to fully understand the concept of MSN in ROHCv2, But as you
said the large value of TS was a side effect of limited value of SN,
might be true.  I am attaching some sample data for your reference. 

Thanks
Biplab

On Mon, 2007-05-28 at 11:55 +0200, Kristofer Sandlund (LU/EAB) wrote:

> Hi,
> 
> comments inline.
> 
> Biplab Sarkar <mailto:[e-mail]> wrote on den 28 maj
> 2007 09:22 :
> 
> > Kristofer,
> > 
> > I have seen some unusual delays of the packets that come to
> > the compressor from the internet rtp servers and some times
> > they come out of sequence too. So in order to send those
> > delayed packets I would like more "k" bits.
> 
> I don't think that would solve what you're seeing since I don't think
> that is the issue. Here's why I don't agree:
> 
> If a packet arrives late out-of-sequence, it can have one of the
> following two field change patterns w.r.t. the TS:
> 
> a) It sticks to the same SN-to-TS function (deltaTS=TS_STRIDE*deltaSN),
> where deltaSN is probably less than zero since it is a late packet.
> In this case, you should not need more TS bits since you do not need
> to send TS at all, all you need is that p(MSN) can allow for a negative
> offset. If this is the case, your RFC3095-compliant compressor chooses
> an EXT2 because you have too few SN bits to allow for the negative
> jump, and you get extra TS bits only as a sideeffect of that since
> you don't have a SN-only extension format.
> So are you sure that it isn't this effect you're seeing?
> If this is the problem, then the ROHCv2 solution is either a pt_0_crc7
> with more MSN bits or you configure for a different p(MSN) via
> REORDERING_HALF or something like that. (or extend pt_0_crc7 even
> further)
> 
> b) It does not have the same pattern (e.g. silence) and
> deltaTS=STRIDE*deltaSN+some_other_offset. Again, if it is a late
> arrival, deltaSN is probably less than zero.
> Also in this case, it might be the MSN (either p or k) that forces
> your compressor to choose the EXT2 format. In this case, you of
> course have to send some TS bits, but with the current ROHCv2 
> 8-bit format, you allow an offset of 8*TS_STRIDE in the
> negative direction and 248*TS_STRIDE in the positive direction.
> So I would *guess* that 8 bits should be enough, possibly that
> we should adjust the p-value to something more that 8 if you would
> have problems with that.
> 
> > I often see I
> > need 10-bits of k-bits. But with the current packets sizes I
> > don't get an optimal packet to sent them. So I was thinking
> > of the enhancements.
> > 
> > Looking at the RFC3095, I see the support for UOR-1-TS-Ext2
> > should have been ideal. But such packets are not there.  So
> > only way to send large k-bits is to go to Type-2 packets with
> > extensions. 
> 
> See above, I suspect you're seeing k(MSN) or p(MSN) being the reason,
> not k(TS), but I can't be sure since I don't have your data. 
> That's why I asked you to explain the traffic pattern in more
> detail.
> 
> > 
> > Since the delays are not always with in bounds I feel support
> > for larger values of TS should be incorporated. If one has to
> > minimize the value of the TS bits they have to send  frequent
> > updates of TIME_STRIDEs which will bring down the efficiency.
> 
> Again, I'd say large k(TS) is only needed in codecs that don't
> send SID frames. And as long as we have an 8-bit TS in the pt_2
> format, you should allow 248*TS_STRIDE jumps there.
> That of couse *might* be a too-small limit, but so far, I haven't
> seen any data pointing towards that. Please provide more data
> on how the TS and SN jumps and we can have a discussion on if we
> need to update the formats.
> 
> > One of the problems of sending Type-2 packets in RFC3095 is
> > that one has to repeat them multiple times.
> 
> You have to repeat all packets multiple times if you work with
> the optimistic approach. So to get around this, you would need to
> have non-updating packet types, not a larger k-value.
> Non-updating PT-1 packets is somehing that can be discussed,
> though I am not very fond of those.
> 
> /Kristofer
> 
> > So this is not
> > very efficient. So I suggest support of larger values for TS
> > both for pt_1 and pt_2 types of packets.
> > 
> > Thanks
> > Biplab
> > 
> > On Mon, 2007-05-28 at 08:50 +0200, Kristofer Sandlund (LU/EAB) wrote:
> > 
> > 
> > 	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