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

From: "Kapoor, Rohit" <[email-masked]>
Date: Wed, 15 Nov 2006 19:56:29 -0800

Ghyslain,

As I wrote in my reply to Mark earlier, it is up to the compressor to make sure that these reordering-related problems do not occur. Meaning that the compressor should send an updating packet enough number of times based on its knowledge of how much the channel reorders. This will ensure that none of the updating packets is received after a non-updating packet (which was sent before the updating packets).

The reason we had not mentioned this earlier was that we thought this falls under the Optimistic Approach discussion, which is already present in 3095 and 4224. Nevertheless, we propose to add the following text to draft-kapoor to handle this:

The compressor SHOULD repeat an updating packet enough number of times to handle the worst reordering on the channel. As an example, if the worst reordering known on the channel is 3, an updating packet should be sent 3 times, before a non-updating packet can be sent. This will ensure that a non-updating packet sent after updating packets, does not arrive at the decompressor before at least one of the updating packets has been received.

We also propose to add the following to address your feedback on the R mode:

A decompressor MUST NOT send feedback with the mode bits set to R-mode. A feedback received with mode bit set to R-mode MUST be ignored by the compressor.

We believe that these text additions (as well as what is already contained in draft-kapoor) handle the cases occurring due to reordering. 

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

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Thu, 16 Nov 2006 08:48:16 +0100

Rohit,

About the draft itself:
- It is good that you change so that there's a "MUST NOT" regarding
R-mode,
but that is not the only example of features that should not be used
that
you lack normative text for. For _example_ segmentation and ref-based
list 
compression also fall into this category, and you have no 2119 text in 
those sections. I haven't read the doc thoroughly, but I found this at 
first glance, so I think you need to go through 4224 and you document
piece
by peice and see what you need to change. 4224 is just an informational 
document and since this doc is supposed to be standards track, I think
this 
draft needs more work and should not just reference 4224 without
defining 
exactly what you intend to be normative from that one and what parts
you want to leave to the implementation.

About implementation complexity:
- Although I agree that ROHCv2 is a larger change w.r.t. the 
bits-on-the-wire, I don't really see why you say that the effort to
implement draft-kapoor on a 3095-implementation is much smaller than
implementing v2 when you have a 3095-implementation.
To handle reordering well, the implementations will have to change
quite a lot in how it handles robustness (optimistic approach etc), the
decompressor needs to learn to detect late arrivals (and preferrably not
update the context for these), the decompressor should not send feedback
on late packets, the compressor should not rely very much on ACKs since
these can be late etc. 
So while your draft doesn't (and maybe shouldn't) explicitly state 
all the changes needed in 3095-implementations, the fact is that it is
still there, and I'm not sure that implementers always realize these
things. 
Therefore, some might belive that the fix is just to change the IR and
to
change the p-value in their lsb-functions, and does 3GPP2 really want 
those kind of deployments out there? 

About process:
- In general, I don't see why you would have a problem with 
standardizing this in 3GPP2 instead of in the IETF; the solution should
be specific to 3GPP2 and then I think it seems very logical that it
should be made there. Could you explain the reasons why this is such an
unwanted option? If it is just to get IETF-participants review, I think
you have already gotten that from some of us active in this WG...

Just my 2 cents.

BR,
  Kristofer

Kapoor, Rohit wrote on den 16 november 2006 04:56:

> Ghyslain,
> 
> As I wrote in my reply to Mark earlier, it is up to the
> compressor to make sure that these reordering-related
> problems do not occur. Meaning that the compressor should
> send an updating packet enough number of times based on its
> knowledge of how much the channel reorders. This will ensure
> that none of the updating packets is received after a
> non-updating packet (which was sent before the updating packets).
> 
> The reason we had not mentioned this earlier was that we
> thought this falls under the Optimistic Approach discussion,
> which is already present in 3095 and 4224. Nevertheless, we
> propose to add the following text to draft-kapoor to handle this:
> 
> The compressor SHOULD repeat an updating packet enough number
> of times to handle the worst reordering on the channel. As an
> example, if the worst reordering known on the channel is 3,
> an updating packet should be sent 3 times, before a
> non-updating packet can be sent. This will ensure that a
> non-updating packet sent after updating packets, does not
> arrive at the decompressor before at least one of the
> updating packets has been received.
> 
> A decompressor MUST NOT send feedback with the mode bits set
> to R-mode. A feedback received with mode bit set to R-mode
> MUST be ignored by the compressor.
> 
> 
> We believe that these text additions (as well as what is
> already contained in draft-kapoor) handle the cases occurring due to
> reordering. 
> 
> Thanks,
> Rohit

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Fri, 17 Nov 2006 18:32:14 -0800

Kristofer, RoHCers,

Please find some comments below.

Thanks,
Rohit

> -----Original Message-----
> 
> Rohit,
> 
> About the draft itself:
> those sections.

<Rohit> The segmentation section in draft-kapoor already uses a 2119
keyword, though the list compression does not. We can add the use of
such a keyword to the list comp section. 

> - ...

<Rohit> I'm not quite sure about what you are referring to. Why does the
decompressor need to learn to detect late arrivals? If the packet is
more reordered than what can be handled, it will (most likely) cause a
decompression failure and the decompressor will send a NACK (this is
also what would happen if too many packets were dropped on the channel).
So, I don't know why you say the decompressor's behavior would change
from that defined in RFC 3095.

> those kind of deployments out there?
<Rohit> Again, I can't understand what extra changes you are talking
about, apart from what is already discussed in draft-kapoor and possibly
a discussion on setting the "optimistic approach" parameter based on
expected reordering on the channel that we plan to add to the draft. So,
from an implementation point of view, there is not much change with this
draft. The optimistic approach parameter is just a matter of setting the
right value for this parameter.

> you have already gotten that from some of us active in this WG...

<Rohit> We believe that this draft does provide a solution for the
reordering issue for not only PP2, but also any other system that is
looking for a short-term solution (with minimal changes from RFC 3095)
for reordering. In fact, I am quite surprised on hearing the arguments
against doing this draft, since as the charter says the RoHC WG should
"ensure that its output fulfills their (PP, PP2 and others)
requirements".

I should make it clear that we also strongly support the development of
v2 and I have quoted advantages of v2 before, so I am not quoting them
again here. We see v2 as a slightly longer-term migration, and there are
upcoming PP2 (and other) systems that can benefit from v2. This is also
the reason that we have been heavily involved in making inputs to v2
development.

But, short-term, draft-kapoor seems to provide a good solution to handle
out-of-order.

Thanks,
Rohit

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Mon, 20 Nov 2006 14:59:51 +0100

Rohit,

The fact that I am seeing that "don't know why" answer so consistently
does not help me feel better about
draft-kapoor-rohc-profiles-reordering-01.txt.

Kristofer added the additional "non-written, non-tangible" extra
implementation complexity, using the example of modifications to the
decompressor and compressor behavior in terms of feedback handling and
detection of late packets (which I entirely agree with, because I wanted
to stick to how draft-kapoor leaves possibilities for the protocol to
break). There's more, especially related on selecting the proper packets
to improve robustness against reordering.

> <Rohit> Again, I can't understand what extra changes you are
> talking about,

Still not feeling better ... I think Kristofer meant what's listed in a
bullet list in a previous mail:
http://www1.ietf.org/mail-archive/web/rohc/current/msg04707.html

It has already been suggested that the authors parse RFC4224 + the above
list of items first, and then come up with a spec that actually defines
a protocol that at least remotely looks like it _could_ live to its
claims. There has been enough useful information provided as feedback on
this list to authors, I think that the wg has been quite kind in this
respect. I think that it would not be a bad idea either to discuss these
additional implementation guidelines, if not to make it clear that there
is much more to this than the LSB fix.

A SIDE NOTE: RFC4224 aimed to mitigate the negative impacts of
reordering on RoHC, NOT to propose how to add support for it. The aim
was to prevent RoHC from generating undetected faulty packets to the IP
layer, and to minimize the risks of damaging a context, IF it would be
deployed over an IP tunnel, which wasn't recommended since RFC3095 makes
the explicit assumption of in-order delivery. Guidelines related to
defining LSB for future profiles were also provided, but in NO WAY was
this presented as "the only change needed is". Draft-kapoor is something
else, as it claims to add support for reordering to RFC3095 profiles,
but fails to address the specifics of the protocol it seeks to update.

BR Ghyslain

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Tue, 21 Nov 2006 17:58:48 -0800

As I have said before, I think draft-kapoor does provide a complete
solution for the issue it tries to solve, i.e., the reordering issue.
You mentioned the bullet points in a previous email, so let me go over
them.

o A reordered IR-DYN can cause different impairments.
  (because of CRC8 properties, because it can reassociate profile/CID,
etc)

As I wrote before in my reply to Mark, this can be handled by the
compressor setting the "number of repeats" of an updating packet based
on the amount of losses as well as reordering expected to be seen on the
channel. If the compressor does this, this is no longer a problem.

Also, we had proposed to add a discussion on this to draft-kapoor.
Moreover, this requires no change to implementations, only the
Optimistic Approach parameter is set to a possibly different value, one
that takes into account both losses and reordering.

RFC 4224 already mentions the following in Section 6.1.1.1, which is
essentially the same as what I said above: 
"   The optimistic approach is affected by the reordering
characteristics
   of the channel when operating over a reordering channel.  Compressor
   implementations should therefore adjust their optimistic approach
   strategy to match both packet loss and reordering characteristics.

   For example, the number of repetitions for each context update can be
   increased.  The compressor should ensure that each update is repeated
   until it is reasonably confident that at least one change packet in
   the sequence of repetitions has reached the decompressor before the
   first packet sent after this sequence. "

o A reordered UOR-2-EXT3 can can different impairments
  (because it carries optional fields, because it does not verify
optional fields, etc)

Same argument as above.

o The Optimistic Approach simply do not ake into account reordering
  (this is in RFC4224)

If the "optimistic approach" parameter is set based on knowledge of
losses as well as reordering on the channel, then it does take into
account reordering. And this is only a matter of setting a parameter
value, which requires no change to implementation.

o CRC-3 is rather weak for both losses AND reordering

This is a general 3095 issue and not a reordering issue in particular.
The robustness of draft-kapoor will thus, be the same as that of RFC
3095.

So, as I said before, we believe this draft is a complete solution for
what it tries to solve, i.e., the reordering issue. RoHC v2 may be
trying to do other things in addition, but that is not the goal of
draft-kapoor.

Thanks,
Rohit

> From: Ghyslain Pelletier (LU/EAB)
[mailto:[email-masked]]
> Sent: Monday, November 20, 2006 6:00 AM
> To: Kapoor, Rohit; Kristofer Sandlund (LU/EAB); Thomas Narten;
> [email-masked]
> Cc: Mahendran, AC
> Subject: RE: Completeness of draft-kapoor-rohc-profiles-reordering-
> 01.txt(WAS: RE: [rohc] 3GPP2's need for)
> 
> Rohit,
>

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 22 Nov 2006 10:28:12 +0100

Rohit,

You're completely off with your "technical" answers.

Besides, I do read your answers and every mail, so there is no need to
repeat the exact same thing every time.

Let me help you catch up on recent discussions about reordering and
header compression on this list.

For each bullet you should have read the parenthesis, where I provided
some hints. You should also have gone back to the list archive and get
some more complementary information there. Some hopefully helpful hints
(i.e. follow the related threads):

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

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

Finally ... 

> This is a general 3095 issue and not a reordering issue in particular.

No. RFC3095 has no general issue with CRC-3 an reordering, _because_ its
design assumed that RFC3095 would not be applied on links where
reordering can occur; CRC-3 is enough when only losses can occur. Losses
+ reordering does complicate things however, and your proposal bypasses
this.

Furthermore, a decompressor that implements local context repairs must
be modified (alt this feature should be disabled), RFC3095 does have
text on local repairs which your draft does not address, among many
other things that's being overlooked.

> The robustness of draft-kapoor will thus, be the same as that
> of RFC 3095.

... which incidently states that its robustness mechanism are for losses
...

This draft has too much potential to create a real mess out there, and
to create confusion about RoHC in general.

Besides, I am not only interested in technical issues:
http://www1.ietf.org/mail-archive/web/rohc/current/msg04730.html

Again, don't understand me wrong - if this is going to be endorsed by
3GPP2 no matter what, my take is that I might as well try to help and
try to provide some guidance. Then it's up to 3GPP2 folks to make their
decisions:
http://www1.ietf.org/mail-archive/web/rohc/current/msg04738.html

Certainly not feeling better about this draft, but that's just my two
cents for now,

BR Ghyslain 

Kapoor, Rohit wrote:
> As I have said before, I think draft-kapoor does provide a
> complete solution for the issue it tries to solve, i.e., the
> reordering issue. You mentioned the bullet points in a previous
> email, so let 
> me go over them.
> 
>   (because of CRC8 properties, because it can reassociate
> profile/CID, etc) 
> 
> As I wrote before in my reply to Mark, this can be handled by
> the compressor setting the "number of repeats" of an updating
> packet based on the amount of losses as well as reordering
> expected to be seen on the channel. If the compressor does
> this, this is no longer a problem.
> 
> Moreover, this requires no change to implementations, only
> the Optimistic Approach parameter is set to a possibly
> different value, one that takes into account both losses and
> reordering. 
> 
> RFC 4224 already mentions the following in Section 6.1.1.1,
> which is essentially the same as what I said above:
>    characteristics of the channel when operating over a reordering
>    channel. Compressor implementations should therefore adjust their
>    optimistic approach strategy to match both packet loss and
> reordering characteristics. 
> 
>   (because it carries optional fields, because it does not
> verify optional fields, etc)
> 
> Same argument as above.
> 
> If the "optimistic approach" parameter is set based on
> knowledge of losses as well as reordering on the channel,
> then it does take into account reordering. And this is only a
> matter of setting a parameter value, which requires no change
> to implementation.
> 
> The robustness of draft-kapoor will thus, be the same as that
> of RFC 3095.
> 
> 
> So, as I said before, we believe this draft is a complete
> solution for what it tries to solve, i.e., the reordering
> issue. RoHC v2 may be trying to do other things in addition,
> but that is not the goal of draft-kapoor.
> 
> Thanks,
> Rohit
> 
>> [email-masked] Cc: Mahendran, AC
>> The fact that I am seeing that "don't know why" answer so
>> consistently does not help me feel better about
>> decompressor and compressor behavior in terms of feedback handling
>> and detection of late packets (which I entirely agree with, because
>> I wanted to stick to how draft-kapoor leaves possibilities for the
>> protocol to break). There's more, especially related on selecting
>> the proper packets to improve robustness against reordering.
>> 
>>> about,
>> Still not feeling better ... I think Kristofer meant what's
> listed in
> a
>> It has already been suggested that the authors parse RFC4224 + the
>> above list of items first, and then come up with a spec that
>> actually defines a protocol that at least remotely looks like it
>> _could_ live to its claims. There has been enough useful information
>> provided 
> as feedback
> on
>> respect. I think that it would not be a bad idea either to discuss
>> these additional implementation guidelines, if not to make it clear
>> that there is much more to this than the LSB fix.
>> 
>> was to prevent RoHC from generating undetected faulty packets to the
>> IP layer, and to minimize the risks of damaging a context, IF it
>> would be deployed over an IP tunnel, which wasn't recommended since
>> RFC3095 makes the explicit assumption of in-order delivery.
>> Guidelines related to defining LSB for future profiles were also
>> provided, but in NO WAY was this presented as "the only change
>> needed is". Draft-kapoor is something else, as it claims to add
>> support for reordering to RFC3095 profiles, but fails to address the
>> specifics of the protocol it seeks to update. 
>> 
>> BR Ghyslain

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Wed, 22 Nov 2006 08:21:07 -0800

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.

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)?

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.

>>CRC-3 is enough when only losses can occur. Losses

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 24 Nov 2006 11:33:24 +0100

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:

>>> + 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:
> 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.
> 
> 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:
> 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.
> 
>>> + 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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 24 Nov 2006 11:37:20 +0100

Rohit,

Re: taking "potshots", ACK. I am often the bad guy, I also have to live
with it. What I perceived as some form of unwillingness to address some
of my comments and work the document may in fact have its grounds coming
from a real technical disagreement (which I've tried to address in an
earlier mail).

Re: "catching up on recent discussions", I could only reach one of two
alternatives interpretations: either 1) those were not known and thus it
was useful to point in their direction, either 2) those were understood
but the mail I was reading was in fact expressing a disagrement with
their conclusions (althought I can't find a clear statement about this
in the respective threads). So I had to go with the former
understanding.

My understanding of your answers at this time is that yes you've
followed the discussions that I referred to (which where related to
RoHCv2 but for which there is no reason why some parts should not
equally apply to draft-kapoor), but that you might not be agreeing with
the conclusions we seemed to reach. That wasn't clear to me before, but
now you've pointed that up, and this becomes another issue then.

Please comfirm if this is the correct understanding. 

Finally, your contribution to the mailing list and especially to the
discussion on reordering is very useful and appreciated; it has already
helped improving the quality of the RoHCv2 draft (I'm working on the
update). I've pointed that out in previous mails as well so there's no
misunderstanding there.

///Ghyslain