RE: [rohc] 3GPP2's need for

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

Biplab, Chokri, Jun, Haipeng, Rohit, all,

I don't really believe in coming to IETF asking for IETF members to
blindly put a rubber-stamp on a draft. But sure it can work. I have a
whole bunch of RoHC-competent people in my corridor that I could ask to
send in a friendly mail to support me on this list. I just don't think
that would have any value, it brings no technical value. I am not sure
either that I believe that "something is better than nothing" wrt
draft-kapoor.

RFC3095 was published too quickly, because of time pressure from 3GPP.
The implementer's guide has grown since then and now we are finally
publishing it. Sure, we can do it again and spend several years fixing
draft-kapoor once it gets published to fix all the issues it does not
address. RFC3095 is not an easy spec to digest and to implement right.
It scares me to think of removing the underlying assumption that there
is no reordering, fixing lsb and making some recommendations.

Anyway, I've given a significant number of hints as to what should be
worked on for this draft. I also think that the thought to reuse
existing implementations over links that can reorder packets is
appealing; this is one of the reasons we wrote RFC4224. Unfortunately, I
don't believe that the result would be good in a product that is meant
for the long term, and I don't believe that the
modifications/testing/maintenance that it would require to an existing
RFC3095 implementation would be that trivial either. So we've decided to
make RoHCv2 ... for a lack of believing that the path proposed by the
combination of fixing lsb encoding and making RFC4224 mandatory is the
path of least resistance.

I respect different opinions on this. I am just trying to do the right
thing. Hence why I think that this draft should be endorsed by 3GPP2
instead. I am not planning to be that vocal about this anymore, unless
the solution takes a shape that makes more sense to me.

But why not instead ask this WG to speed up and focus on RoHCv2, see
with the RFC-editor if we can get an RFC number reserved and see with
IANA if profile numbers can be reserved for RoHCv2 profiles, and
complete RoHCv2 properly?

We've got excellent feedback from all of you guys, and we've certainly
appreciated it, so why not focus on this?

///Ghyslain

Sarkar, Biplab wrote:
> All,
> 
> 
> 
> I believe "something is better than nothing". So, until we
> get the Rohcv2, why not just have a short term arrangement
> and keep things going. After all this short term solution is
> asking for some new profile numbers. Since I believe we have
> enough of those, sparing a few shouldn't be a big issue.
> Since "Special theory" came ahead of "General Theory" I
> believe we can have this short term solution for the time being.
> 
> 
> 
> Thanks
> 
> Biplab
> 
> 
> 
> 
> 
> ________________________________
> 
> From: West, Mark [mailto:[e-mail]]
> Sent: Wednesday, November 15, 2006 4:05 PM
> To: Trabelsi, Chokri (Chokri); Ghyslain Pelletier (LU/EAB); Thomas
> Narten; [e-mail] Cc: AC Mahendran
> Subject: RE: [rohc] 3GPP2's need for
> 
> 
> 
> 
> 
> Hi all,
> 
> Can I briefly expand upon a (technical) argument made earlier
> in this thread..?  Without prejudice to the discussion about
> what to do about pursuing this work or otherwise ;-)
> 
> I don't recall seeing any discussion in this draft of the
> effect of re-ordering on anything other than typical LSB
> updates.  For example, updates to a rarely changing field (such as
> TTL). 
> 
> The following sequence:
> 
>  1) UO-0
>  3) UOR-2 + EXT-3 (TTL)
>  2) UO-0 (sequentially late)
> 
> will cause the delayed packet 2 to decompress incorrectly.
> 
> There are various ways that this can be handled (rely on CRC;
> detect and discard; detect and correct) some of which may
> impact the configuration of the decompressor (k out of n
> rules).  Whilst it may not be necessary to define this for
> interoperability, it does affect 'robustness' and so some
> discussion is surely justified..?
> 
> In other words, I agree that this should be a relatively
> uncommon case; but that doesn't mean it should be ignored!
> And what concerns me slightly more is how many other similar
> cases may be buried in there...
> 
> Cheers,
> 
> Mark.
> 
> "This email message and any attachments are confidential
> information of Starent Networks, Corp. The information
> transmitted may not be used to create or change any
> contractual obligations of Starent Networks, Corp. Any
> review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon this e-mail and its
> attachments by persons or entities other than the intended
> recipient is prohibited. If you are not the intended
> recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> [e-mail] -- and destroy all copies of
> this message and any attachments without reading or
> disclosing their contents. Thank you."


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