RE: Completeness of draft-kapoor-rohc-profiles-reordering-01.txt(WAS: RE: [rohc] 3GPP2's need for)

Rohit,

ACK.

> For the above two issues, I was trying to point out that the
> issues that v2 is trying to solve do not exist *only* due to
> reordering. In fact, why don't you give an example where the
> functionality of the above two packets is broken *only* due
> to reordering (pls assume an OA value that is appropriately
> set for reordering)?

In fact, I can't. I cannot give examples using this assumption.

It is a fact that if the OA is set to an infinite value (not literally,
of course), meaning here that each type of update is repeated at least a
number of times larger than say the sum of the maximum reordering depth
possible (with 100% confidence) and the maximum number of consecutive
losses possible (with 100% confidence), then the robustness properties
of these packets will not break.

However, I do consider that efficient compression when used and when
updating the context is also part of their respective functionality.

But I will discuss more in details below about the OA argument in
general, and why I believe it is not a fair or generally applicable
argument in favor of an RFC3095-based solution to reordering (if this is
an argument that is however acceptable to 3GPP2, then I think that at
least a discussion should be provided to 3GPP2 in relation to what
happens if not meeting a proper value when deploying without addressing
other issues).

So, I will instead refrain from making (system) specific assumptions,
and instead discuss a solution that aims to be generally applicable and
to provide an equal efficiency gain in any system, and thus give some
examples where I believe that the functionality of these packets can
break, and why I consider that this is only due to the possibility of
those being reordered.

o wrt IR-DYN

The CRC8 only covers the content of the IR-DYN header, not the original
header. My understanding is that if an IR-DYN header is received after
an IR header (i.e. reordering), different impairments may happen:

- if the IR header had a different profile then the IR-DYN
  (new flow, different protocol type)
- if the IR header had different static information than the IR-DYN
  (new flow, same protocol type)

Basically, the weaknesses of the design of the IR-DYN header, deriving
directly from its application in conjunction with reordering, are
related to its capacity to re-associate a CID with a different profile
and "compressing away static information" - without verifying the
successful outcome of the reconostruction itself (CRC8 over transmitted
info only).

Additional problems are introduced from the fact that it can break the
context based on the above, and yet be successful so that an ACK is sent
back to the compressor, which leads to a longer impairment event.

Please let me know if you believe that the reasoning above fails
somewhere, and where.

o wrt to "control fields" (e.g. TS_STRIDE and TIME_STRIDE)
  IR, IR-DYN and UOR-2-EXT3

The properties of these fields in RFC3095 are such that for neither IR,
IR-DYN or UOR-2-EXT3 these fields are used to reconstruct the original
header; each header update these values in the context, and in the case
of UOR-2-EXT3 it does not verify those fields whatsoever in conjunction
with the processing of this header.

The presence of these fields in the header is also optional.

Control fields in RFC3095 are weak wrt reordering because reordered (and
thus faulty) updates with different values can lead to different
impairments:

- the loss of context synchronization cannot be detected immediately,
  and thus ACKs can be sent;
- it is unclear how the compressor can detect what occurred,
  especially in the event where the only ACK received is for the
  late packet (this can occur if an ACK is sent only for the
  late packet, or if feedback is also lost)
- there is no guarantee from RFC3095 text that the context will
  ever recover (a decompressor implementation is at the mercy of
  the compressor implementation)

The third point above can occur, because even if the compressor receives
a STATIC-NACK later, the faulty update to the control fields may itself
have been ACKed previously (a result of the first point above). Since
the transmission of these fields is optional in RFC3095, then there is
no guarantee that a compressor will actually take the proper actions to
recover synchronization and send those fields.

Note: This is as opposed to semi-static fields for which in the worst
case (STATIC-NACK) an suitable update is always conveyed in the IR.

Please let me know if you believe that the reasoning above fails
somewhere, and where.

(note: the problem is described in
http://tools.ietf.org/html/draft-ietf-rohc-rtp-impl-guide-22#section-8.1
1. The point here is that without reordering the fix is only a "should"
because only residual errors can lead to this problem when reordering is
not considered, but with reordering this probability is not
insignificant anymore and then becomes a "must")

(note: I am aware that this also applies to control fields in RoHCv2,
the point is that text is required to shut down this eventuality wrt to
when to update the context or not, when to send these control fields,
when/what to ACK, etc. Such text, if not already present in RoHCv2
draft, will be in there. We are also considering for RoHCv2 to more
clearly require that control fields are send periodically in
unidirectional operation, and to define a feedback option to allow the
decompressor to request in a STATIC-NACK a complete re-init of the
context)

o wrt OA

> As you yourself said, this is only an implementer's choice,
> to find the best trade-off. In some systems, max reordering
> and max losses may not be very high, so a small OA is OK.
> Other systems may require a larger OA, if reordering and/or
> losses is higher. This is not a reordering issue in general.

I am not denying that the OA is an implementer's choice, and a tradeoff.

When only losses are possible, the OA is not too costly; in RFC3095, the
alternative to the OA is R-mode for which updates are also repeated - at
minimum under one RTT (i.e. the minimum time to get an ACK), so the
tradeoff is most of the time better with the OA when only losses can
occur, but the marginal is small and depends on the RTT and the rate of
the flow.

Different systems also in general have values for the maximum possible
number of packet losses, and these are within a small span often between
2-5 packets. RFC3095 is designed to minimize the possibility of loss
propagation in case an impairment on the link exceeds the OA value used,
as the protocol design does NOT RELY on the OA to be EQUAL to the
_absolute_ maximum possible value for it NOT to break.

In other words, if the OA is set to 4 and a loss event goes up to 6
consecutive packets, then the algorithm still has the possibility to
recover as soon as it can.

When reordering comes into the picture, it is important to review all
aspects of the protocol to ensure that this is still true for the OA. In
other words, the design has to ensure that a packet that is reordered
and falls outside the OA will not contribute to further loss
propagation. Only the packet itself should be discarded, with no other
side effects. 

Especially, cases where the algorithm can break and possibly not recover
must be avoided.

I also believe that generally the maximum possible reordering depth will
be larger than the maximum possible number of consecutive losses. Thus
the combined maximum depth + consecutive losses corresponding to
different systems will vary within a much broader span of values. In
other words, the costs of the OA is still bound to system-specific
properties.

Wrt to protocol design, I believe that it is a good practice to ensure
that the performance of a protocol is not made dependent on system
specific properties when those might not be generally similar across
systems, i.e. the protocol may behave differently when used over two
links whose behavior varies differently, but under the same conditions
the performance should be equal. I also believe that if a specific
impairment _can_ happen, even will low probability, it _will_ happen
eventually, so that the protocol must ensure that it can recover in ALL
cases.

So, in this discussion, it seems to me that I'm seeing claims wrt two
different approaches:

1) always assume that the OA is set to the absolute worst case;
  - this "guarantees" that the protocol design won't break
    because of reordering
  - this makes the protocol performance dependent on the
    link properties/assumptions (compression efficiency-wise)

2) identify and address all possible cases where the protocol can fail
  in presence of impairment situation, and design the protocol
  accordingly (or fix those as in the case of RFC3095 here)
  - this removes any possibility for the protocol to break
    (ok to loose a packet, but no side effects)
  - this makes its compression efficiency independent of
    link properties/assumptions

I prefer 2). The first alternative concerns me in a generally applicable
solution, because the protocol does not apply as well to every system.
It is also in practice so that implementers often set values agressively
to spare one octet here and there, so I would assume that e.g. the OA
for IR headers will be a problem in that respect in 2). I think that 2)
requires at least a lot of guidance, and this also means implementation
work that is outside the protocol definition. It think 2) is not proper
for a generally applicable specification, as the protocol should be
fixed to match the new assumptions on its applicability.

What I think is important in a spec promoting 2) is to make clear the
possible downfalls of being too agressive wrt RFC3095: when only losses
may occur, RFC3095 has mechanisms to get the context back in synch; when
reordering is possible, then other types of impairments may occur as
described above (and I cannot claim that I have investigated the entire
list of possible corner-case - I am NOT using this as an argument, I
simply mean that I do not personally intend to look for more as I want
to focus on not having such in RoHCv2 instead and to provide correct
guidelines in RoHCv2 about this. This is also the responsability of the
author of the proposal to ensure that this is made and reflected in text
IMO).

My point wrt to the OA is that I do not believe it is the general answer
to all reordering issues and possible drawbacks of RFC3095, for all
systems in general. The performance of the proposed solution does not
remain be equal for every system, with differences in performance being
more extreme than when only consecutive losses are considered (as it was
for RFC3095).

If, for example, EVDO Rev. A can guarantee with high probability that
max reordering depth and max losses are small enough, then of course the
tradeoff is less costly and it MAY be a proper assumption to then mainly
rely on the OA, set to this absolute value (the consequence of a failure
to set a proper value should be mentionned).

Please let me know if you believe that the reasoning above fails
somewhere, and where.

(note: as editor for RoHCv2, I am aware that I will have to parse RoHCv2
draft to make sure that the text there proproses proper guidance. The
design itself, however, is meant to match alternative 2) above. I think
the protocol design addresses this properly in its current state as we
had that in mind from the beginning. If you find problems there, that
would be helpful to know about)

o wrt CRC-3

> How can you say this? A context failure can occur due to
> losses as well as reordering, and a CRC-3 is equally good or
> bad when protecting against these. Again, why don't you give
> an example to illustrate your point that CRC-3 works OK with
> losses, but not with reordering?

My point is not about if the properties of the CRC3 are different or not
from reordering or not - of course they aren't. I did write:

> o CRC-3 is rather weak for both losses AND reordering
> 
>>> CRC-3 is enough when only losses can occur. Losses
>>> + reordering does complicate things however, and your proposal +
>>> bypasses this.

The fact is that when there is an impairment event, a packet with a CRC3
as 1/8 probability to succeed despite the packet not being bitwise
identical. When only packet losses is considered, it takes a rather long
serie of consecutive losses (either larger than OA with IR/IR-DYN/UOR-2
updates) or more than ~14 with PT-0 or residual bit errors to create a
possible impairment event. This is quite rare, so CRC3 is quite
sufficient in that case.

Reordering increases the probability to have such impairment event,
rather close to the rate of occurance of reordered packets. This is a
significant difference IMO. This means that the rate of damage packets
(i.e. packets that are delivered to upper layers but that are not
bitwise identical) increases proportionally.

Please let me know if you believe that the reasoning above fails
somewhere, and where.

(note: RoHCv2 adresses this with pt-0-crc7 packet type, which may be
used by implementations instead of pt-0-crc3 when reordering is
possible; otherwise, pt-0-crc3 can be used when there is no reordering,
thus making the efficiency of RoHCv2 at least at par with RFC3095 under
the same assumptions)

Sorry for the lengthy mail, but this a broad topic.
It is also maybe of some interest wrt RoHCv2 work.
Hope this helps the discussions anyway,
Have a good weekend,

///Ghyslain

Kapoor, Rohit wrote:
> Ghyslain,
> 
>>> You're completely off with your "technical" answers.
> 
> First of all, I would request you to not take "potshots" and
> limit your answers to those that provide technical and/or
> other input to the group. I could also make statements such
> as the above, but I refrain from doing so, since I want to
> keep the use of the mailing list limited to what it is intended for.
> 
> As far as earlier discussions on IR-DYN and UOR-2-Ext3, as
> you might be aware, I have been quite involved in them, so no
> need for you to "help me catch up on recent discussions".
> 
> Also, rather than just giving some arguments, I would request
> you to come up with some concrete examples to back up your arguments.
> 
> o the problems with IR-DYN:
> http://www1.ietf.org/mail-archive/web/rohc/current/msg04556.html
> 
> o the problems with UOR-2-EXT3:
> ... are similar to IRs wrt ctrl fields.
> Read related stuff (especially wrt alternative 3) in thread:
> http://www1.ietf.org/mail-archive/web/rohc/current/msg04555.html
> 
> For the above two issues, I was trying to point out that the
> issues that v2 is trying to solve do not exist *only* due to
> reordering. In fact, why don't you give an example where the
> functionality of the above two packets is broken *only* due
> to reordering (pls assume an OA value that is appropriately
> set for reordering)?
> 
> 
> o about OA, my concerns are related to implementer's choice
> and are expressed somewhere in the middle of this mail:
> http://www1.ietf.org/mail-archive/web/rohc/current/msg04551.html
> 
> As you yourself said, this is only an implementer's choice,
> to find the best trade-off. In some systems, max reordering
> and max losses may not be very high, so a small OA is OK.
> Other systems may require a larger OA, if reordering and/or
> losses is higher. This is not a reordering issue in general.
> 
> o CRC-3 is rather weak for both losses AND reordering
> 
>>> CRC-3 is enough when only losses can occur. Losses
>>> + reordering does complicate things however, and your proposal +
>>> bypasses this.
> 
> How can you say this? A context failure can occur due to
> losses as well as reordering, and a CRC-3 is equally good or
> bad when protecting against these. Again, why don't you give
> an example to illustrate your point that CRC-3 works OK with
> losses, but not with reordering?
> 
> Thanks,
> Rohit

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc