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

From: "West, Mark" <[email-masked]>
Date: Thu, 21 Apr 2005 16:40:14 +0100

Hi all,

After various holidays, illnesses and assorted other panics, I have now
had sufficient time to both re-read the 're-ordering' draft and collate my
comments.  (I deliberately did not read the other committed document
review so as not to bias my own reading.  However, I have not filtered my
review against it either, so apologies if I have duplicated some comments
as a result!)

I have a couple of possibly significant comments, some minor comments and
a couple of nits.  Hopefully they're not too confused...

I'm basically pretty happy with the document: I like the analysis and
implications and it reads well.  However, I'd like the more significant
comments, at least, to be addressed.

Cheers,

Mark.

* Significant Comments

- External sequence numbers

There is no discussion of how ROHC can be run over a re-ordering channel
when there is an external sequence number present (for example when
running over IPsec ESP).  I accept that this requires no modification at
the compressor [other than the knowledge that this is being done], but it
would require modification at the decompressor.  It may be argued that
this technique is 'out of scope' or merely 'trivial', but I'm slightly
surprised that it isn't even mentioned...

- Discard or Decompress?

Overall, I didn't see much discussion about whether the aim is to (i)
detect sequentially late packets and discard them; or (ii) detect
sequentially late packets and decompress them correctly.

If (i) then the description given appears to be fairly complete.
(Although it's not clear whether 'discard' is automatic on decoding of a
sequentially late SN, or based solely on the CRC; the latter of which
seems obviously less robust...)

If (ii) then, unless I've missed something, there's no discussion of
'rarely changing' fields, for example -- a 'static' field can be
considered to be LSB encoded with a fixed interpretation interval
[lsb(0,0)]. Consider (where '--' == 'not sent' or 'static'):

  Pkt#   1   2   3   4   5   7   6   8
  TTL   62  62  62  --  --  61  --  61

then Pkt#7 is sequentially early (i.e. indistinguishable from loss), but
Pkt#6 is detectably sequentially late.  We can, in this case, either:

i) rely on the CRC (U/O-mode) to catch the error;
ii) discard the packet on detection of it being sequentially late;
iii) discard the packet on detection of it being sequentially late *iff*
there has been an update received that is now known to be sequentially
early; or
iv) cache updates at the decompressor and decompress against the correct
context, having detected the sequentially late nature of the packet.

Again, whatever the recommendation is, I would have thought that these
options should at least be presented?

* Minor Comments

1. Introduction

Asserts that, despite RFC 3095 stating to the contrary, ROHC's inability
to cope with re-ordering is a misconception. Section 3.2 then points out
profiles (including some defined in RFC 3095) for which "reordered packets
cannot be decompressed" [without special considerations].  I guess it
depends what your definition of 'cope with' is, but I'm having a bit of
difficulty reconciling those two statements!

2. Terminology

Cites RFC 2119 but, unless I've mis-grepped, conspicuously fails to use
any capitalised keywords (there are a bunch of lower-case 'must's,
'should's, etc.; but these may just be red herrings!) [Is this document
actually intending to use 'standards' language (should it?)]

"Updating packet" -- IR/IR-DYN packets do not have a CRC computed over the
*uncompressed* packet?  But are updating..? (almost just a nit!)

5.2.1 Functionality Incompatible with Reordering

Timer-based compression is quoted under "functionality incompatible with
reordering", but is (as stated correctly in the body of the draft) just
something that impacts the jitter (i.e. the impact is already legislated
for within RFC 3095) -- so I don't see why this is necessarily
'incompatible'...

6.1.1.1 Reordering and the Optimistic Approach

Regarding increasing the number of repetitions of each context update: Is
this really necessary?  What's the relationship between loss and
re-ordering?  I haven't really thought this one through fully, but I'm
slightly suspicious...

6.1.1.3 Robust Selection of Compressed Header

I'm not completely convinced about the phase, "the interpretation interval
for the LSB encoded sequence number could be adjusted..."  I'd prefer
something more explicit, such as, "packet formats could be chosen with an
interpretation interval for the LSB encoded sequence number that..."

* nits

6.1 "may however lower" -> "may, however, lower"

6.1.2.2 'effiency' -> 'efficiency'

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

---

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

Mark 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 Mark marked with %)

Cheers,
/L-E

% - External sequence numbers 
% There is no discussion of how ROHC can be run over a re-ordering
% channel when there is an external sequence number present (for
% example when running over IPsec ESP).  I accept that this
% requires no modification at the compressor [other than the
% knowledge that this is being done], but it would require
% modification at the decompressor.  It may be argued that 
% this technique is 'out of scope' or merely 'trivial', but I'm
% slightly surprised that it isn't even mentioned... 

We agree that the scope could be made clearer, so we suggest to add
the following paragraph to the end of the introduction.

OLD:
<

NEW:
> In some scenarios, there might be external means (such as a
> sequence number) to detect and potentially correct reordering. 
> That is for example the case when running compression over an
> IPsec ESP tunnel. With such external means to detect reordering,
> the decompressor can be modified to make use of the external
> information provided, and reordering can then be handled. How
> to make use of external means to address reordering is, however,
> out of scope for this document.

% - Discard or Decompress? 
% Overall, I didn't see much discussion about whether the aim is to
% (i) detect sequentially late packets and discard them; or
% (ii) detect sequentially late packets and decompress them
% correctly. 

The goal in the long run is of course just to "decompress correctly",
not necessarily even noticing reordering as anything special. In the
short term, with only 3095 being available as compression standard,
we will have to live with doing the best possible, probably a mixture
of (i) and (ii). This document aims at discussing the various aspects
of using ROHC over channels that can reorder packets, including 
identifying the challenges, as well as suggesting both implementation
methods and future standards improvements to better cope with
reordering. However, this document is not aiming at specifying a
solution, i.e. there is no single goal like your (i) or (ii).

% 1. Introduction 
% Asserts that, despite RFC 3095 stating to the contrary, ROHC's
% inability to cope with re-ordering is a misconception. Section
% 3.2 then points out profiles (including some defined in RFC
% 3095) for which "reordered packets cannot be decompressed"
% [without special considerations].  I guess it depends what your
% definition of 'cope with' is, but I'm having a bit of
% difficulty reconciling those two statements!

The misconception is that ROHC handles reordering worse than
other existing header compression schemes (just because it
explicitly states it has been designed with an assumption
about in-order delivery), and we believe that is what the
text says.

% 2. Terminology 
% Cites RFC 2119 but, unless I've mis-grepped, conspicuously
% fails to use any capitalised keywords (there are a bunch of
% lower-case 'must's, 'should's, etc.; but these may just be red
% herrings!) [Is this document actually intending to use
% 'standards' language (should it?)] 

Yes, it was our intention to use 2119 language if we formulated
technical proposals to be incorporated in future ROHC profiles.
However, we did not go that way but instead we just explained
the technical concepts. The 2119 references should thus go away:

OLD: 
<  However, the document discusses possible ways of modifying existing
<  ROHC implementations and/or specifications to address its objectives.
<  In those parts of the document, the key words "MUST", "MUST NOT",
<  "REQUIRED", "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT",
<  "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
<  described in RFC 2119 [1].

NEW:

OLD:
<  [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.
NEW:

% "Updating packet" -- IR/IR-DYN packets do not have a CRC computed
% over the *uncompressed* packet?  But are updating..? (almost just
% a nit!) 

OLD:
<  Updating packet
<
<     A packet that updates the context of the decompressor, i.e. all
<     packets carrying a CRC calculated over the uncompressed header.
<
<  Non-updating packet
<
<     A packet that carries a CRC calculated over the uncompressed
<     header updates the context of the decompressor when it is
<     successfully decompressed. A packet without such a CRC is thus
<     referred to as a non-updating packet.

NEW:
>  Updating packet
>
>     A packet that updates the context of the decompressor, e.g. all
>     packets except R-0 and R-1* in RFC 3095 [2].
>
>  Non-updating packet
>
>     A packet that does not update the context of the decompressor, 
>     e.g. only R-0 and R-1* in RFC 3095 [2].

% 5.2.1 Functionality Incompatible with Reordering 
% Timer-based compression is quoted under "functionality incompatible
% with reordering", but is (as stated correctly in the body of the
% draft) just something that impacts the jitter (i.e. the impact is
% already legislated for within RFC 3095) -- so I don't see why this
% is necessarily 'incompatible'... 

Agree, see previous mail with responses to Aniruddhas comments.

% 6.1.1.1 Reordering and the Optimistic Approach 
% Regarding increasing the number of repetitions of each context
% update: Is this really necessary?  What's the relationship between
% loss and re-ordering?  I haven't really thought this one through
% fully, but I'm slightly suspicious... 

There is no actual relationship between loss and reordering that
specifically affects the optimistic approach, but reordering itself
do influence the robustness of the optimistic approach, as discussed
in 6.1.1.1.

% 6.1.1.3 Robust Selection of Compressed Header 
% I'm not completely convinced about the phase, "the interpretation
% interval for the LSB encoded sequence number could be adjusted..."
% I'd prefer something more explicit, such as, "packet formats could
% be chosen with an interpretation interval for the LSB encoded
% sequence number that..." 

We agree:

OLD:
<  The interpretation interval for the LSB encoded sequence number can
<  be adjusted to allow for larger negative offsets (see section 5.1.1).

NEW:
>  Packet formats could be chosen with an interpretation interval for
>  the LSB encoded sequence number that allow for larger negative
>  offsets (see section 5.1.1).

% 6.1 "may however lower" -> "may, however, lower" 

OLD:
<  The methods suggested here may however lower compression efficiency,
   and these modifications should not be used when reordering is known

NEW:
>  The methods suggested here may, however, lower compression efficiency,
   and these modifications should not be used when reordering is known

% 6.1.2.2 'effiency' -> 'efficiency' 

OLD:
      packet types are used. This can be useful to minimize the usage of
<     the feedback channel, thereby improving effiency of the link.

NEW:
      packet types are used. This can be useful to minimize the usage of
>     the feedback channel, thereby improving efficiency of the link.

---

From: "West, Mark" <[email-masked]>
Date: Mon, 9 May 2005 23:11:31 +0100

Hi Lars-Erik,

Thanks for your suggested updates.  I have a couple of follow-on comments
(for brevity, I've chopped out stuff where the update completely addresses
my comment)...

Cheers,

Mark.

> solution, i.e. there is no single goal like your (i) or (ii).

Ok, that makes sense -- and maybe I should have been clear that my 'or'
was not necessarily an 'exclusive or' :-)

The fact remains, though, that if you are trying to correctly decompress
re-ordered packets, there are more challenges than are described.
Specifically, the full version of my comments argued that decompressing a
sequentially late packet during the update of a rarely-changing field (for
example) is problematic (for detection, in an R-mode scenario; and for
correct decompression in U/O-mode).

Unless I've missed something, then I do not see how the draft can be
complete without some discussion of this?

> about in-order delivery), and we believe that is what the

Fair enough.

> do influence the robustness of the optimistic approach, as discussed

I think that I was struggling to find the rationale behind the text, 'For
example, the number of repetitions for each context update can be
increased.'  But I don't think that this is a big deal, as the section
does, overall, make sense.  I'm happy to leave it as it stands.

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 10 May 2005 13:45:01 +0200

Mark,

Thanks for being insistent, I believe you have a point here. After reading
the draft text again and discussing this with Kristofer, our conclusion is
that what we believe is missing is more text in section 5.1.3, which
should discuss both "Reordering between non-change packets only"
and "Reordering involving change packets".
The current text in 5.1.3 actually only covers the former. So, our 
proposal is to make the following changes to section 5.1.3:

OLD:
   5.1.3. Reordering of Packets in U/O-mode
 
<     Sequentially late packets
< 
<        The ability to decompress sequentially late packets is limited by
<        the offset p of the interpretation interval (see section 5.1.1).
         Decompression of a sequentially late packet with SN = x is
         possible if the value of the SN of the packet that last updated
         the context was less than or equal to x + p.
 
         Problems occur if context(SN) has increased by more than p with
         respect to field(SN) carried within the packet to decompress.
 
         This means that for a well-behaved stream with a constant unit
         increase in the RTP SN, a packet can arrive up to p packets out of
         sequence and still be correctly decompressed. Otherwise, it cannot
         be properly decompressed. It also means that if the compressor
         sends two consecutive packets with SN(packet1)=100 and
         SN(packet2)=108 when p=7, packet1 cannot be decompressed if it
         arrives even one packet late due to reordering.
 
      Decompression can always be verified since all U/O-mode packet types
<     are context updating. Consequently, reordering of packets is not
<     deemed problematic when operating in U/O-mode. For channels known to
<     reorder packets, the U/O-mode should therefore be the preferred mode
      of operation. The additional risk of losing context synchronization,
      or for erroneous packet to be delivered to upper layers, is limited.

NEW:
   5.1.3. Reordering of Packets in U/O-mode
 
>     Reordering between non-change packets only
>
>        When there is reordering of non-change packets only, the ability
>        to decompress sequentially late packets is simply limited by the
>        offset p of the interpretation interval (see section 5.1.1).
         Decompression of a sequentially late packet with SN = x is
         possible if the value of the SN of the packet that last updated
         the context was less than or equal to x + p.
 
         Problems occur if context(SN) has increased by more than p with
         respect to field(SN) carried within the packet to decompress.
 
         This means that for a well-behaved stream with a constant unit
         increase in the RTP SN, a packet can arrive up to p packets out of
         sequence and still be correctly decompressed. Otherwise, it cannot
         be properly decompressed. It also means that if the compressor
         sends two consecutive packets with SN(packet1)=100 and
         SN(packet2)=108 when p=7, packet1 cannot be decompressed if it
         arrives even one packet late due to reordering.

>     Reordering involving change packets
>
>        When a packet is reordered and becomes sequentially late with
>        respect to a change packet, decompression of the late packet may
>        eventually fail, as the context information required for
>        successful decompression may not be available anymore.

      Decompression can always be verified since all U/O-mode packet types
>     are context updating. Consequently, even if reordering of packets
>     may in some cases result in unsuccessful decompression, context
>     invalidation due to reordering can be avoided or detected. The risk
>     of forwarding incorrectly decompressed packets to upper layers is
>     therefore small when operating in U/O-mode. For channels known to
>     reorder packets, U/O-mode should therefore be the preferred mode of
      operation. The additional risk of losing context synchronization,
      or for erroneous packet to be delivered to upper layers, is limited.

Does this capture what you were missing from the draft?
/L-E

-----Original Message-----
From: West, Mark [mailto:[email-masked]]
Sent: den 10 maj 2005 00:12
To: Lars-Erik Jonsson (LU/EAB)
Cc: [email-masked]
Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt

Hi Lars-Erik,

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 12 May 2005 14:58:19 +0200

Some quick picky nits on the proposed text.

BR,

/Ghyslain

> >        offset p of the interpretation interval (see section 5.1.1).

Suggestion:

" When only non-change packets are reordered with respect to each
  other, decompression of sequentially late packets is limited by
  the offset p of the interpretation interval (see section 5.1.1)."

Because reordering of non-change packet may actually be interpreted as with respect to any other event or packet type, despite the usage of the word only. I actually tripped on that sentence...

> >     invalidation due to reordering can be avoided or detected. The risk

Suggestion:

" Consequently, a failure to decompress a packet that is caused
  by reordering can be detected, and context invalidation due
  to reordering can thus be avoided."

Because both "avoidance" and "detection" are applied to context invalidation in the proposed text, while in fact "detection" applies to the decompression failure and "avoidance" applies to context invalidatation.

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 12 May 2005 15:31:18 +0200

I like these adjustments!

I'm, however, still waiting for Mark to ack the proposed changes.

/L-E

> From: Ghyslain Pelletier (LU/EAB) 
> Sent: den 12 maj 2005 14:58
> To: Lars-Erik Jonsson (LU/EAB); West, Mark
> Cc: [email-masked]
> Because reordering of non-change packet may actually be 
> interpreted as with respect to any other event or packet 
> type, despite the usage of the word only. I actually tripped 
> on that sentence...
> 
> Because both "avoidance" and "detection" are applied to 
> context invalidation in the proposed text, while in fact 
> "detection" applies to the decompression failure and 
> "avoidance" applies to context invalidatation.
>

---

From: "West, Mark" <[email-masked]>
Date: Tue, 17 May 2005 23:50:08 +0100

Hi Lars-Erik,

Given the scope of the draft, as discussed with regard to previous
comments, yes -- I'm much happier that the text now explicitly discusses
the implication of re-ordering of "change packets".

I believe that you have now addressed all of my comments.

Thanks,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

On Tue, 10 May 2005, Lars-Erik Jonsson (LU/EAB) wrote:

> Date: Tue, 10 May 2005 13:45:01 +0200
> From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
> To: "West, Mark" <[email-masked]>
> Cc: [email-masked]

---

From: "West, Mark" <[email-masked]>
Date: Tue, 17 May 2005 23:51:12 +0100

Late, as ever!  But having acked the proposed changes, I too like these
adjustments :-)

Cheers,

Mark.

On Thu, 12 May 2005, Lars-Erik Jonsson (LU/EAB) wrote:

> Date: Thu, 12 May 2005 15:31:18 +0200
> To: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>,
>      "West, Mark" <[email-masked]>
> Cc: [email-masked]