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

["Kapoor, Rohit" <[e-mail]>]

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

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


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