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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc