Subject: RE: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 4 May 2005 10:00:09 +0200

Aniruddha and others,

Here are responses to your comments from the draft authors, expressed
as suggestions for how to address them in the draft. 

(Original comments from Aniruddha marked with %)

Cheers,
/L-E

% 1. section 5.1.2.1 "The compressor removes values smaller than..."
%    this should be "...older than...".

OLD: 
   The compressor always adds references in the sliding window for all
<  updating packets sent. The compressor removes values smaller than
                                                        
NEW:
   The compressor always adds references in the sliding window for all
>  updating packets sent. The compressor removes values older than

% 2. section 5.2.1 "When using this encoding method, the decompressor 
%    discards...". This should be "..., the compressor discards..."
%    (refer 3095 section 4.5.4, para 4).

We believe this text is actually correct, although it is not very
well formulated. Anyway, see below how we intend to handle the timer-
based issue.

% I agree with others on the point that timer-based 
% compression is not "functionally incompatible" with
% reordering. It suffers in same way as scaled-timestamp
% encoding would.

Yes, we agree that as long as the expected jitter is properly estimated,
timer-based compression requires no special reordering considerations.

We suggest to remove timer-based from this section.

OLD: 
5.2.1. Functionality Incompatible with Reordering

<  There are some optional ROHC functions that cannot work in the
   presence of reordering between ROHC peers.

   The ROHC segmentation scheme (see [2], section 5.2.5) relies entirely
   on the in-order delivery of each segment, as there is no sequencing
   information in the segments. A segmented packet for which one (or
   more) segment is received out-of-order cannot be decompressed, and is
   discarded by the decompressor. Therefore segmentation should not be
   used if there can be reordering between the ROHC peers.

<  Timer-based compression of RTP TS (see [2], section 4.5.4) is built
<  on an assumption of timely (minimal jitter) delivery. When using this
<  encoding method, the decompressor discards packets arriving with an
<  arrival time that is outside the estimated upper bound for the
<  estimated jitter. Therefore it should be used with care over links
<  where reordering can occur, with respect to the amount of jitter that
<  can be introduced by reordering.

<  The use of these optional features is open to implementations and is
   local to the compressor only; it does not impact the decompressor.

NEW:
5.2.1. Functionality Incompatible with Reordering

>  There is one optional ROHC function that cannot work in the
   presence of reordering between ROHC peers.

   The ROHC segmentation scheme (see [2], section 5.2.5) relies entirely
   on the in-order delivery of each segment, as there is no sequencing
   information in the segments. A segmented packet for which one (or
   more) segment is received out-of-order cannot be decompressed, and is
   discarded by the decompressor. Therefore segmentation should not be
   used if there can be reordering between the ROHC peers.

>  The use of this optional feature is open to implementations and is
   local to the compressor only; it does not impact the decompressor.

We also suggest to add the following to the end of section 5.1.1.

OLD:
<

NEW:
>  Timer-based compression of RTP TS (see [2], section 4.5.4) provides
>  means to reduce the number of timestamp bits needed in compressed
>  headers after longer gaps in the packet stream (typically due to
>  silence suppression). To use timer-based compression, an upper limit
>  on the inter-arrival jitter must be reliably estimated by the
>  compressor. It should be noted that although the risk of reordering
>  of course means there is a more significant jitter on the path 
>  between the compressor and the decompressor, there are no special
>  reordering considerations for timer-based compression. It all still
>  boils down to the task of estimating the jitter, requiring channel
>  characteristics knowledge at the compressor, and/or jitter estimation
>  figures received from the decompressor.

% 3. section 6.1.1.2 , Avoiding the "missing reference" problem
%    If the decompressor implements the context updating logic of section 
%    6.1.2.1 and compressor is aware of that (by means of standardization), 
%    why would it delay advance in sliding window?

We agree that the current text is confusing and should be reformulated.
However, after looking more carefully at your comment number 4 (see below),
we believe section 6.1.2.1 should actually be removed. This means we
change 6.1.1.2 as follows:

OLD:
   Avoiding the "missing reference" problem (section 5.1.2.1)

      A compressor implementation can delay the advance in the sliding
      window to a reference acknowledged by the decompressor, until it
      has confidence that no acknowledgement for any of the values that
      could be discarded can be received. This confidence can be based
      on the maximum delay that reordering can introduce over the
<     channel. It can also be based on the knowledge that the
<     decompressor implements the context updating logic of section
<     6.1.2.1 (e.g. by means of standardization).

NEW:
   Avoiding the "missing reference" problem (section 5.1.2.1)

      A compressor implementation can delay the advance in the sliding
      window to a reference acknowledged by the decompressor, until it
      has confidence that no acknowledgement for any of the values that
      could be discarded can be received. This confidence can be based
      on the maximum delay that reordering can introduce over the
>     channel. 

% 4. section 6.1.2.1 , Will the addition of "The decompressor 
%    should not deliver the sequentially late (with respect to the
%    reference) non-updating packet to upper layer." handle case for
%    both updating and non-updating packets?

The logic behind only discussing updating packets here was that when
this was written we believed it should in most cases be possible to
detect reordered updating packets only by using methods internally
within ROHC. Reordering of non-updating packets would on the other
hand for sure require external mechanisms. After looking a bit deeper
into this, we tend to agree that there are no reliable ways to detect
reordering, neither of updating nor non-updating packets, and therefore
we suggest to remove section 6.1.2.1 altogether.

OLD:
< 6.1.2.1. Bi-directional Reliable Mode (R-mode)
<
<   The "missing reference" problem described in section 5.1.2.1 can be
<   avoided. If the decompressor can detect when two updating packets
<   (packets including CRCs) are reordered with respect to each other, it
<   should not update the context with the values of the sequentially
<   late update packet.

NEW:

% 5. section 6.1.2.2 "Note that if the decompressor does not make this 
%    adjustment to its feedback, packet losses or context damages will
%    not increase".
%    It is confusing, could it mean that "if decompressor does make the 
%    adjustment, packet losses/context damages will increase" or does
%    it mean "even if decompressor does not make the adjustment, 
%    losses/damages will not increase". Can it be made bit clear?

Yes, it can, according to your latter interpretation:

OLD:
<     Note that if the decompressor does not make this adjustment to its
<     feedback rate, packet losses or context damages will not increase.

NEW:
>     Note that even if the decompressor does not make this adjustment
>     to its feedback rate, packet losses or context damages will not
>     increase.

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

---

From: Aniruddha Kulkarni <[email-masked]>
Date: Tue, 10 May 2005 10:25:30 +0200

Hi Lars-Erik,

    Your suggested updates address my comments. I am wondering if there 
is no
reliable way to detect reordering then are the last para in section 
6.1.2.2 and
section 6.1.2.3 still relavent?

---Aniruddha