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

["Ghyslain Pelletier \(LU/EAB\)" <[e-mail]>]

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

> o CRC-3 is rather weak for both losses AND reordering
> 
> 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.
> 
> 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