Subject: RE: [rohc] 3GPP2's need for

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 15 Nov 2006 16:02:40 +0100

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:[email-masked]]
> Sent: Wednesday, November 15, 2006 4:05 PM
> To: Trabelsi, Chokri (Chokri); Ghyslain Pelletier (LU/EAB); Thomas
> Narten; [email-masked] 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
> [email-masked] -- and destroy all copies of
> this message and any attachments without reading or
> disclosing their contents. Thank you."

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 16 Nov 2006 10:08:58 +0100

Rohit, Thomas,

I am also expecting feedback on the following:

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

Especially wrt to feedback received that the long-term solution in 3GPP2
would be RoHCv2.

Best regards,

///Ghyslain

Ghyslain Pelletier (LU/EAB) wrote:
> 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
>

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Fri, 17 Nov 2006 00:15:08 +0100

Folks,

This is an IETF working group, not a toy factory that satisfies the 
wishes from each and every child on this planet. Let's remind ourselves 
of what that means.

a) We work together to make the Internet work, and to develop technology 
that makes sense. In general, this means we should strive for solutions 
that will be good in the long run, and which are generally applicable.

b) We contribute as individuals. Statements about company opinions can 
(and maybe even should) be ignored.

c) There is no voting in the IETF.

d) Non-technical arguments are normally rather irrelevant.

e) What sums up to rough consensus on a subject is based on the 
technical merits of all contributions.

f) We work on chartered work items. To get a work item chartered, there 
has to be a convincing need for it, and also must the reason for working 
on it within the IETF be clear.

g) We do not rubber-stamp solutions already developed elsewhere, we 
produce our protocols based on our agreed requirements and needs, and we 
do the work on our mailing list(s).

h) We have no obligation to produce a protocol just because some other 
standards body wants it. See f).

i) Our work is ready for publication when it is ready, not when we 
wanted it to be ready.

j) We can only control what we produce, not what other groups do or what 
is used "out there". But still, we can control what we let out of our 
dooor.

Regarding draft-kapoor-rohc-profiles-reordering-01.txt, the various ways 
forward listed in Thomas mail are just what we could come up with as 
potential ways to produce a protocol withoin or outside the IETF, all 
these are not necessarily applicable in this case. Remember the 
requirements to "have it finalized immediately" and to "have it solve 
exactly this problem and nothing more in exactly this way". Considering 
the four options listed and discussed:

1) Doing this in the ROHC WG is impossible with such requirements, see 
f), g), i) above.

2) This makes no sense, and is nothing we can ask for or decide about. 
Why should an AD shepard a protocol draft when there is a WG? That would 
be to by-pass the WG and let individual authors produce an RFC as if it 
was an IETF product. Our AD has also expressed his opinion on this, and 
I fully understand he is not willing to do such a trick.

3) At all having an RFC with profiles that are highly undesirable, if 
one consider the whole ROHC picture, is bad for the Internet and serves 
noone. Anyone is free to try this way, but I do not think it will fly. 
The whole argument that 2) or 3) would be desirable from a 3GPP2 point 
of view because "it would mean more IETF review of the outcome" is just 
totally moot.

4) If this is *needed* by 3GPP2, nothing prevents them to do it. And if 
they actually want feedback on it, they can get that if they ask for it, 
as easy as for any other alternative. Getting profile numbers is not a 
problem either, as long as they do have a protocol specification to 
refer to.

Having multiple profile sets is bad for interoperability, multiple 
choices (options) are always bad from an interoperability point of view. 
We have had a long process to come up with the way forward with ROHC RTP 
(and related profiles), which is now resulting in ROHCv2. If some other 
standards body can not wait for ROHCv2, that is their problem and not a 
reason for us to do yet another RFC 3095 (quick and dirty solution). 
Getting ROHCv2 finalized is our top priority, that is where we should 
put our (limited) resources, which is also in line with the request of 
the original 3GPP2 liaison letter on this subject, when it expressed a 
general problem to be solved (and not asked for an IETF rubber-stamp on 
one specific draft).

/L-E

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Fri, 17 Nov 2006 19:45:27 -0800

Ghyslain,

Let me answer both your questions in this email.

> Why try to motivate this in the IETF, and why try to get an
> IETF blessing for it and not just do it in 3GPP2 specifications?

<Rohit> As I replied to Kristofer earlier, we think this solution is useful in general for any system that wants a near-term solution for out-of-order (with minimal changes to RFC 3095). If you read the Applicability statement in draft-kapoor, it says the following:

"This specification attempts to set out the
   minimal set of changes to RFC 3095 needed to support reordering.
   This specification is intended to be used for near-term support of
   systems which require this functionality. It is not intended to
   replace RoHCv2's reordering support, and the full RoHCv2 profiles
   should be the basis of any long term protocol development."

<Rohit> I have always strongly supported RoHC v2 and maintained that it provides benefits that are likely to be particularly useful for future PP2 (as well as PP) systems. One extremely good aspect of RoHC v2 is its graceful handling of multiple IP headers, and while this may not be very useful for "today's" PP2 systems, it is likely to be very useful for future PP2 systems. This is also one reason why we have been actively participating in v2 development.

With that said, in the near-term it is not possible for solutions that have implemented RFC 3095 and want reordering support, to implement v2. This would require reimplementing RoHC and current timelines don't allow that. This is where draft-kapoor fits in, i.e., for the near-term.

Thanks,
Rohit

---

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

Rohit,

> Let me answer both your questions in this email.

Fact is, unless repeating the highly-speculative argument that others
_MAY_ want this, you haven't answered.

Consider:
o the RoHC WG has clearly stated it is working on
  draft-ietf-rohc-rfc3095bis-rohcv2-profiles
o there is no consensus in the RoHC WG that it will work on
  draft-kapoor-rohc-profiles-reordering
o it is requested that draft-kapoor-rohc-profiles-reordering
  is handled by IETF outside the RoHC working group, alt 2) in:
  http://www1.ietf.org/mail-archive/web/rohc/current/msg04697.html 
o other "arguments" heard have been that 3GPP2 needs a
  "something is better than nothing" specs asap ...

I fail to understand the following:

o how can 3GPP2 be comfortable with this process
o why would the IETF accept to publish a draft that hasn't been
  a work item in the WG that has direct and sole responsability for
  the protocol this draft is modifying  

> If you read the Applicability statement in draft-kapoor

I have read the entire very short draft a number of times. I made a
serious review. Your claims go beyond this, and calls for a more
widespread applicability: "useful in general for any system". This makes
me even more uncomfortable, whatever comes out of a header compression
solution has to be at the very least technically complete, with a clear
discussions of impacts and limitations, or if making assumptions a clear
description of those.

To the risk of sounding blunt, I AM addressing this draft very
seriously, but I am starting to wonder if this is a draft that is trying
to get to some specs status by avoiding a serious development process in
both the IETF and 3GPP2. Surely, getting AD Shepherded Informational
document bypassing the RoHC WG and the normal IETF process is a good way
to alleviate the need for 3GPP2 to assess its quality, and thus ensure
its lack thereof.

Best regards,

///Ghyslain 

Kapoor, Rohit wrote:
>> Why try to motivate this in the IETF, and why try to get an IETF
>> blessing for it and not just do it in 3GPP2 specifications?
> 
> <Rohit> As I replied to Kristofer earlier, we think this
> solution is useful in general for any system that wants a
> near-term solution for out-of-order (with minimal changes to
> RFC 3095). If you read the Applicability statement in
> draft-kapoor, it says the following:
> 
> Especially wrt to feedback received that the long-term
> solution in 3GPP2 would be RoHCv2.
> 
> <Rohit> I have always strongly supported RoHC v2 and
> maintained that it provides benefits that are likely to be
> particularly useful for future PP2 (as well as PP) systems.
> One extremely good aspect of RoHC v2 is its graceful handling
> of multiple IP headers, and while this may not be very useful
> for "today's" PP2 systems, it is likely to be very useful for
> future PP2 systems. This is also one reason why we have been
> actively participating in v2 development.
> 
> With that said, in the near-term it is not possible for
> solutions that have implemented RFC 3095 and want reordering
> support, to implement v2. This would require reimplementing
> RoHC and current timelines don't allow that. This is where
> draft-kapoor fits in, i.e., for the near-term.
> 
> Thanks,
> Rohit