Subject: [rohc] 3GPP2's need for

From: Thomas Narten <[email-masked]>
Date: Mon, 13 Nov 2006 14:04:27 -0500

Lars-Erik Jonsson (ROHC chair), AC Mahendran (3GPP2 Liaison to IETF),
Thomas Narten (IETF Liaison to 3GPP2) and Rohit Kapoor participated in
a call on September 18 (and have held subsequent discussions) on the
topic of the 2 liaison statements from 3GPP2 to the ROHC WG:

   August 4 2006 entitled "ROHC Revised Profiles Dependency":
   https://datatracker.ietf.org/documents/LIAISON/file347.pdf

   Which was a follow-up on a previous letter sent March 31 2006:
   https://datatracker.ietf.org/documents/LIAISON/file295.pdf

In short 3GPP2 needs a new ROHC profile to handle packet reordering
issues, but is unwilling to wait for the ROHCv2 work to be completed.

Some of the issues that were discussed:

  - There is (and has already been) testing with updated profiles that
    have confirmed  benefits in their networks.

  - Operators hope to begin deployments starting next year, and are
    looking for a solution that minimizes code changes.

  - 3GPP2 needs a finalized specification by the end of this year to
    meet its schedule.

  - There is concern that the updated ROHCv2 specifications will
    contain a number of additions, and thus require significant
    implementation work which is not compatible with their current
    schedules. 

  - The additional changes to the ROCHv2 profiles are not seen as
    critical to 3GPP2 in the short term, however longer-term there is a
    sense that migrating to them is feasible (and will have
    benefits). Thus, having a profile that just includes improved
    support for packet reordering is viewed as a tactical approach.

We then discussed the various options for producing an updated profile
that would meet 3GPP2's needs. Four possibilities were discussed:

1) Have the ROHC WG formally adopt the work. [This approach was viewed
   as being problematic for a number of reasons and is not being
   pursued.]
    
2) Take the work started in
   draft-kapoor-rohc-profiles-reordering-01.txt, and produce an AD
   Shepherded Informational document. [This approach has the advantage
   that it would help get a some level of IETF/WG review to "sanity
   check" that what is being proposed is compatible with the ongoing
   v2 profile work. But discussions with the chair/AD suggested that
   we would have difficulty getting support for this route, as the
   resultant document might appear to have been "blessed" by the IETF
   too much.]

3) Take the above document and submit it as an RFC Editor Independent
   submission document. [This approach is viewed as less preferrable
   to 3GPP2 than 2) but preferable to 4) because 3GPP2 would like to
   have some IETF/ROHC review of the document. While there would be no
   formal review (according to process for Independent Submissions in
   RFC 3932), it would at make the document more visible to the IETF
   for those that chose to review it.]

4) Have the work be done completely outside of the IETF, published as
   a 3GPP2 document. [This would likely result in the least amount of
   IETF review of the document, and is least desirable to 3GPP2.]

Does the WG have thoughts on how best to go forward with this, and/or
which of the above options they would prefer?
   
Thomas

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Tue, 14 Nov 2006 16:51:04 +0100

Tomas,

I think that the only possible alternative for draft-kapoor-rohc-profiles-reordering-01.txt is alternative 4).

Please read my comments inline, explaining my point of view.

///Ghyslain

Thomas Narten wrote:

> In short 3GPP2 needs a new ROHC profile to handle packet
> reordering issues, but is unwilling to wait for the ROHCv2
> work to be completed.

My understanding of this statement is that it mix the discussion of requirements, technical merits of the proposal and a 3GPP2 timeplan. Unfortunately, the latter (in)conveniently hides the first two important items.

What is proposed here is IMHO a solution to an incomplete or incorrect set of requirements. This leads to a proposal that is from my perspective an incomplete solution, a "quickfix" to existing implementations.

In other words, the problem with reordering and ROHC is more complex than what is targeted by the solution in draft-kapoor-rohc-profiles-reordering-01.txt. Lots of insights can be found in RFC4224 and in draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt.

Personnally, I do not feel one bit comfortable with having IETF "supporting" the definition of RoHC profiles that are not technically complete, not generally applicable, and that are not living up to the requirements of this working group.

I would find this a most unusual praxis. Some more thoughts below ...

>     have confirmed  benefits in their networks.

The RoHCv2 work is showing that the changes proposed in draft-kapoor-rohc-profiles-reordering-01.txt are not generally sufficient to guarantee that this will work well in all environments. >From monitoring the list for quite a while I believe there is strong evidence of a consensus around this.

Therefore IMHO the statement above seems to make the proposed solution very 3GPP2-specific.
 
>     looking for a solution that minimizes code changes.

I am not sure how this helps/impacts settling a correct technical solution. However, I would gladly speed up the work on RoHCv2.
 
>     implementation work which is not compatible with their current   

I believe that there is a concern in this wg that without the necessary changes and additions as proposed in RoHCv2, reordering issues will not be addressed properly.

In other words, RoHCv2 looks as it is because it contains the changes _necessary_ to properly address reordering with RoHC. It follows a clear set of requirements agreed by this WG (draft-ietf-rohc-rfc3095bis-improvements).

>     support for packet reordering is viewed as a tactical approach.

What seems to be misunderstood here is that RoHCv2 differs from RFC3095 _because_ it is addressing mainly reordering. It is wrong to believe that only lsb encoding is the issue.

I would thus like to correct the statement above based on my understanding of draft-kapoor-rohc-profiles-reordering-01.txt:

Substitute: "a profile that just includes improved support for packet reordering"

With: "a profile that just includes improved support to the least-significant bit (lsb) encoding for sequentially changing fields in the presence of packet reordering, excluding other possible negative impacts of reordeing to the existing RoHC protocol as listed in RFC4224.". This is closer to reality.

Again, IMHO the statement above seems to make the requirements addressed very 3GPP2-specific.

>    resultant document might appear to have been "blessed" by the IETF

I would oppose this alternative, as I do not believe that the IETF should "bless" a work related to RoHC that is too much 3GPP2-specific. Alternatively, would I support it I would propose changes to the draft that would ultimately make it look like RoHCv2 profiles, which in my opinion contains the _minimal_ and _essential_ elements to make robust header compression robustly and efficiently over a channel that can reorder packets.
 
>    for those that chose to review it.]

I don't see the difference here with 2), other than from a process popint of view and other than to avoid the expertise of the RoHC wg. Explain?

>    IETF review of the document, and is least desirable to 3GPP2.]

As the draft addresses very much 3GPP2-specific requirements and a 3GPP2-specific solution, then it seems to me like the only possible alternative is 4). 

Finally, this whole issue is not about a simple review and a blessing, this is about properly designing a protocol towards a solution that addresses the problem it aims to resolve. I am not seeing this in draft-kapoor-rohc-profiles-reordering-01.txt from the perspective the IETF normally takes when designing protocols and publishing specifications.

Best regards,

///Ghyslain

--
 Ghyslain Pelletier, Dipl. Ing.
 Wireless IP Optimizations
 Ericsson Research, Corporate Unit

 Ericsson AB, Laboratoriegränd 11
 Box 920, S-97128 Luleå, SWEDEN
 Phone : +46 (0)  8 404 29 43
 Mobile: +46 (0) 70 264 83 14
 Ghyslain.Pelletier at ericsson.com
 http://www.ericsson.com

-----------------------------------
 The opinions expressed in this
 message are my personal opinions.
 These opinions are not
 necessarily those of my employer,
 unless stated otherwise.
-----------------------------------

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Tue, 14 Nov 2006 10:34:52 -0800

Thomas, Ghyslain, RoHCers,

I think that draft-kapoor-rohc-profiles-reordering-01.txt contains the
set of changes that are required to support reordering on the channel.
RoHC v2 goes above and beyond this by making significant changes to RFC
3095, not all of which are necessary for support of reordering.

Also, draft-kapoor-rohc-profiles-reordering-01.txt handles all the
issues that were brought up in RCF 4224 with respect to support for
reordering. So, I do believe that
draft-kapoor-rohc-profiles-reordering-01.txt contains the changes
required for support of reordering.

Also, draft-kapoor-rohc-profiles-reordering-01.txt is useful not only
for 3GPP2, but also for other systems that may want to implement only
reordering enhancements to RFC 3095. One more thing: there is support
from a lot of people for draft-kapoor-rohc-profiles-reordering-01.txt on
the RoHC mailing list, which means that people do see some value in this
draft.

Pls find some more comments embedded below.

Thanks,
Rohit

> What is proposed here is IMHO a solution to an incomplete or incorrect
set
> of requirements. This leads to a proposal that is from my perspective
an
> incomplete solution, a "quickfix" to existing implementations.
> 
> In other words, the problem with reordering and ROHC is more complex
than
> what is targeted by the solution in
draft-kapoor-rohc-profiles-reordering-
> 01.txt. Lots of insights can be found in RFC4224 and in
draft-ietf-rohc-
> rfc3095bis-rohcv2-profiles-00.txt.

<Rohit> All the issues brought up in RFC 4224 have been covered by
draft-kapoor-rohc-profiles-reordering-01.txt, so I'm not quite sure what
you are referring to.

> The RoHCv2 work is showing that the changes proposed in
draft-kapoor-rohc-
> profiles-reordering-01.txt are not generally sufficient to guarantee
that
> this will work well in all environments. >From monitoring the list for
> quite a while I believe there is strong evidence of a consensus around
> this.

<Rohit> I don't know what strong consensus you are referring to. I
haven't seen any such consensus on the mailing list. On the other hand,
some people have expressed support for the draft.

> 
> I believe that there is a concern in this wg that without the
necessary
> changes and additions as proposed in RoHCv2, reordering issues will
not be
> addressed properly.
> 
> In other words, RoHCv2 looks as it is because it contains the changes
> _necessary_ to properly address reordering with RoHC.

<Rohit> A number of changes proposed in RoHC v2 are not meant to handle
reordering. As an example, all the changes made to the packet structures
are not required for support of reordering. So, I don't agree with this
comment at all. The fact is that RoHC v2 contains a number of
significant changes that are not required for reordering support.

> What seems to be misunderstood here is that RoHCv2 differs from
RFC3095
> _because_ it is addressing mainly reordering. It is wrong to believe
that
> only lsb encoding is the issue.
 
<Rohit> RFC 4224 clearly brings up the issues required for reordering
support and draft-kapoor-rohc-profiles-reordering-01.txt handles all
these issues. So, I don't quite follow this.

> Finally, this whole issue is not about a simple review and a blessing,
> this is about properly designing a protocol towards a solution that
> addresses the problem it aims to resolve. I am not seeing this in
draft-
> kapoor-rohc-profiles-reordering-01.txt from the perspective the IETF
> normally takes when designing protocols and publishing specifications.

<Rohit> I think draft-kapoor-rohc-profiles-reordering-01.txt handles all
the issues required for reordering support (all the issues identified in
RFC 4224). I think it addresses the set of changes that are required for
support of reordering, while RoHC v2 makes other significant changes
from RFC 3095. Moreover, draft-kapoor-rohc-profiles-reordering-01.txt
could be applicable not only to 3GPP2 systems, but also other systems
that are looking for changes to RFC 3095 to support reordering (without
other changes).

---

From: "Jin, Haipeng" <[email-masked]>
Date: Tue, 14 Nov 2006 16:51:45 -0800

Hi, Ghyslain,

I wouldn't agree with your assessment of draft-kapoor-rohc-profiles-reordering-01.txt.

The requirement of the draft is simple and clear: adding re-ordering support to U/O mode 3095 profiles. The solution provided in this draft actually follows the guideline provided in RFC4224 very closely. It includes the part about how to modify profiles for more re-ordering tolerance. The implementation enhancements identified in RFC4224 applies generally to both RFC3095 and the modified profile so there is no need to repeat them again. The draft is also clear about limitations (e.g. no support for R-mode). 

I am not sure why you are saying that it is incomplete; could you please identify the re-ordering use cases that are not covered by the draft? 

3GPP2 may be one of the main initial adopters/consumers of the draft, but there is nothing in that draft specific about 3GPP2. That is also why it is important for ROHC WG to review and approve it. 

I support Option 2 in Thomas' original proposal.

Best Regards,
Haipeng

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB) [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 7:51 AM
To: Thomas Narten; [email-masked]
Cc: Mahendran, AC
Subject: RE: [rohc] 3GPP2's need for 

Tomas,

///Ghyslain

 

 

Best regards,

///Ghyslain

---

From: "Wang, Jun" <[email-masked]>
Date: Tue, 14 Nov 2006 21:48:04 -0800

I think to get re-ordering support in IETF ASAP is very critical for VoIP implementation. I also support Option 2 in Thomas' original proposal.

Best Regards,
Jun

-----Original Message-----
From: Jin, Haipeng [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 4:52 PM
To: Ghyslain Pelletier (LU/EAB); Thomas Narten; [email-masked]
Cc: Mahendran, AC
Subject: RE: [rohc] 3GPP2's need for 

Hi, Ghyslain,

Best Regards,
Haipeng

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB) [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 7:51 AM
To: Thomas Narten; [email-masked]
Cc: Mahendran, AC
Subject: RE: [rohc] 3GPP2's need for 

Tomas,

///Ghyslain

 

 

Best regards,

///Ghyslain

---

From: "Trabelsi, Chokri \(Chokri\)" <[email-masked]>
Date: Wed, 15 Nov 2006 02:48:29 -0600

Ghyslain,

A lot of changes made in ROHC v2 are not necessarily needed  to handle reordering. Although I do support ROHC v2, I do also believe that for those that are only concerned about reordering issue, the proposed changes in "draft-kapoor-rohc-profiles-reordering-01.txt " are sufficient and contain the necessary that are required to support reordering on the channel. Therefore I think the proposed option 2 is a good compromise on how to proceed with this issue that has been debated for quite sometime and a number of companies are waiting for resolution on this.

Thanks
Chokri

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB) [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 10:51 AM
To: Thomas Narten; [email-masked]
Cc: AC Mahendran
Subject: RE: [rohc] 3GPP2's need for 

Tomas,

///Ghyslain

 

 

Best regards,

///Ghyslain

---

From: "West, Mark" <[email-masked]>
Date: Wed, 15 Nov 2006 10:35:04 -0000

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.

---

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

Rohit, Thomas, All,

My understanding of draft-kapoor-rohc-profiles-reordering-01.txt is that
it is not a complete solution, and it does not address a complete set of
requirements. Later mails will explain this hopefully better, but I have
a more pressing question in here.

> draft-kapoor-rohc-profiles-reordering-01.txt on the RoHC
> mailing list, which means that people do see some value in this draft.

... then it should not be a problem to get support for this solution in
3GPP2?
... which incidently throws in a question:

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?

The RoHC WG has already a specific set of requirements established via
consensus, and a well advanced work item for its updated profiles that
consider reordering as a working group document. I fail to grasp the
reason why IETF should entertain and consider a duplicate solution that
does not live up to agreed requirements, call it intermediary solution
or anything else does not matter. Do we now actually encourage duplicate
efforts and/or solutions in the IETF???

Don't get me wrong: I'll do my best to help out widespread deployment
and use of RoHC-based solutions that this WG has produced and is
producing (my sponsor quite surely thinks this is good too ... but I'm
just guessing here). I just can't support a solution that I believe has
too many potential issues so that my fingers just can't stop writing
long email answers. We've already had enough work with one implementer's
guide to fix 3095, I don't want us to be left with that again.

Best regards,

///Ghyslain

Kapoor, Rohit wrote:

> <Rohit> All the issues brought up in RFC 4224 have been
> covered by draft-kapoor-rohc-profiles-reordering-01.txt, so
> I'm not quite sure what you are referring to.

Not using normative text.
 
>> RFC3095 _because_ it is addressing mainly reordering. It is wrong to
>> believe that only lsb encoding is the issue.
> 
> <Rohit> RFC 4224 clearly brings up the issues required for
> reordering support and
> draft-kapoor-rohc-profiles-reordering-01.txt handles all
 
> 
>> Finally, this whole issue is not about a simple review and a
>> blessing, this is about properly designing a protocol towards a
>> solution that addresses the problem it aims to resolve. I am not
>> seeing this in draft- kapoor-rohc-profiles-reordering-01.txt from
>> the perspective the IETF normally takes when designing protocols and
>> publishing specifications. 
> 
> <Rohit> I think draft-kapoor-rohc-profiles-reordering-01.txt
> handles all the issues required for reordering support (all
> the issues identified in RFC 4224). I think it addresses the
> set of changes that are required for support of reordering,
> while RoHC v2 makes other significant changes from RFC 3095.
> Moreover, draft-kapoor-rohc-profiles-reordering-01.txt
> could be applicable not only to 3GPP2 systems, but also other
> systems that are looking for changes to RFC 3095 to support
> reordering (without other changes).

---

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

Rohit, Thomas, all,

> I think that draft-kapoor-rohc-profiles-reordering-01.txt
> contains the set of changes that are required to support
> reordering on the channel.

My understanding of draft-kapoor-rohc-profiles-reordering-01.txt is that
it does not address a complete set of requirements. I assume a
discussion on the scope of the draft based on its contents is proper
here if this draft is to follow some IETF path.

Unfortunately, I had to derive the "requirements" from the normative
text of the draft...

Incomplete set of requirements:
===============================
Translating the normative text of the draft, the requirement seems to
be:
o "a solution that allows PT-0 to be decompressed even when reordered"
o "with little modifications to existing implementations"

And on the list:
o "within a 3GPP2 timeline".

Translating the normative text of the draft, one main assumption seems
to be:
o the flows being compressed are well-behaved
o context updates other than the SN will not be needed often.
(the ROHC wg cannot make this assumption, but maybe 3GPP2 can?).

Hence why I stated that draft-kapoor addresses 3GPP2-specific
requirements.

Generally, the more context updates sent from compressor to
decompressor, the more vulnerable it becomes to reordering. This is not
addressed whatsoever in the draft.

Specifically, IR-DYN, UOR-2-EXT3 in particular are not addressed, and
they have much potential to impact the sanity of a context when they are
reordered.

This is not mentionned in RFC4224 because RFC4224 was not meant to
modify the protocol.

IMHO a solution based on draft-kapoor has to meet proper requirements.
The definition that this WG normally use for a specific set of
assumptions is:
- no damage propagation
  (i.e. no erroneous packets propagated to upper layers)
- near-zero loss propagation
  (i.e. the number of additional packets lost because of
  a previous decompression)
- as efficient as possible wrt to compression ratio,
  without impairing the previous points.

Best regards,

///Ghyslain

---

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

Haipeng,

I still support option 4 in Thomas proposal (and I don't mind being the
only one being vocal about it!!!). Option 4 also implies that there is
an AD that is willing to shepherd this draft to produce an AD Shepherded
Informational document, so my impacting the outcome of Thomas's enquiry
seems actually very limited anyway.

Wrt to requirements and to compleness, see the two mails I sent
previously to the list.

I simply want to add that for other "customers", having multiple
solutions (assuming sufficient technical merits) is not a blessing - it
is rather a curse. More code to maintain, more man-hours to implement,
more to test, more options to configure and maybe more mandatory stuff.

It is not my understanding either that this is good praxis in the IETF
to publish different specs that address the same problem: it also
creates confusion to IETF's "customers" about the technical merits of
each alternatives.

Strangely enough, after the WG received the liaison from 3GPP2,
Kristofer and myself did our best to speed up the work to produce RoHCv2
especially for 3GPP2 and its deadlines, and now it seems that I got
stuck in between ... Ah well ...

///Ghyslain

Jin, Haipeng wrote:
> Hi, Ghyslain,
> 
> I wouldn't agree with your assessment of
> draft-kapoor-rohc-profiles-reordering-01.txt.
> 
> The requirement of the draft is simple and clear: adding
> re-ordering support to U/O mode 3095 profiles. The solution
> provided in this draft actually follows the guideline
> provided in RFC4224 very closely. It includes the part about
> how to modify profiles for more re-ordering tolerance. The
> implementation enhancements identified in RFC4224 applies
> generally to both RFC3095 and the modified profile so there
> is no need to repeat them again. The draft is also clear
> about limitations (e.g. no support for R-mode).
> 
> I am not sure why you are saying that it is incomplete; could
> you please identify the re-ordering use cases that are not
> covered by the draft?
> 
> 3GPP2 may be one of the main initial adopters/consumers of
> the draft, but there is nothing in that draft specific about
> 3GPP2. That is also why it is important for ROHC WG to review
> and approve it.
>

---

From: "Jin, Haipeng" <[email-masked]>
Date: Wed, 15 Nov 2006 15:52:37 -0800

Hi, Ghyslain,

Please see my comments in line.

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB)
[mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 6:34 AM
To: Jin, Haipeng; Thomas Narten; [email-masked]
Cc: Mahendran, AC
Subject: RE: [rohc] 3GPP2's need for 

Haipeng,

Wrt to requirements and to compleness, see the two mails I sent
previously to the list.
[Haipeng] The requirement is very clear: provide re-ordering support
based on RFC4224 principle and limit the changes from 3095 if possible.
I understand your concerns that some of the requirements or
recommendations are not phrased in IETF normative style and may not be
crystal clear. That certainly should be clarified.

[Haipeng] Well, talking about "customers", wireless access environment
such as 3GPP2 and 3GPP are really the most important customers of ROHC
documents. They are likely to be the first ones to commercially deploy
ROHC and related profiles. I think it is important for us to understand
and support their needs. 

[Haipeng] I don't think anyone is denying the merit of RoHCv2 work.
Kristofer and your time and effort on v2 are really appreciated. Other
people are also trying to help moving the work forward whenever
possible. However, the issue here, as identified in others' messages
already, is v2 actually introduce much dramatic changes to ROHC
including mode usage, state transition, and packet format changes, in
addition to reordering support. Some of them may be good in general but
are not necessary for solving the re-ordering issue.  The re-ordering
draft clearly limits its scope to solve the re-ordering issue while
trying to provide an easy migration path from 3095. I don't understand
why it is a problem.

Best Regards,
Haipeng

///Ghyslain

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Wed, 15 Nov 2006 19:43:35 -0800

Mark,

Good point. The fact is some of these cases cannot be handled by any RoHC profiles; neither draft-kapoor nor rohc v2. Let me try to define some of the categories of these cases:

1) Updating packet arrives before non-updating packet (which was sent earlier). This can be "corrected" by neither draft-kapoor nor v2. But, as you mentioned, it would be good to add a discussion about this, maybe pointing out that CRC can be used to check this etc.

2) Updating packet (which was sent earlier) arrives after non-updating packet. This can be avoided by making sure that the compressor does the right thing. Meaning, if the compressor sets the "number of repeats" of an updating packet based on its "knowledge" of amount of reordering on the channel, then at least one updating packet should arrive before the next non-updating packet. We propose to add such a discussion in draft-kapoor.

Thanks,
Rohit

-----Original Message-----
From: West, Mark [mailto:[email-masked]]
Sent: Wed 11/15/2006 2:35 AM
To: Trabelsi, Chokri (Chokri); Ghyslain Pelletier (LU/EAB); Thomas Narten; [email-masked]
Cc: Mahendran, AC
Subject: RE: [rohc] 3GPP2's need for

Hi all,

The following sequence:

 1) UO-0
 3) UOR-2 + EXT-3 (TTL)

Cheers,

Mark.

---

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

Rohit, Thomas,

I am still expecting some feedback on this mail, especially on:

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

Regards,

///Ghyslain

Ghyslain Pelletier (LU/EAB) wrote:
> Rohit, Thomas, All,
> 
> My understanding of
> draft-kapoor-rohc-profiles-reordering-01.txt is that it is
> not a complete solution, and it does not address a complete
> set of requirements. Later mails will explain this hopefully
> better, but I have a more pressing question in here.
> 
>> draft-kapoor-rohc-profiles-reordering-01.txt on the RoHC mailing
>> list, which means that people do see some value in this draft.
> 
> ... then it should not be a problem to get support for this solution
> in 3GPP2? ... which incidently throws in a question:
> 
> 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?
> 
> The RoHC WG has already a specific set of requirements
> established via consensus, and a well advanced work item for
> its updated profiles that consider reordering as a working
> group document. I fail to grasp the reason why IETF should
> entertain and consider a duplicate solution that does not
> live up to agreed requirements, call it intermediary solution
> or anything else does not matter. Do we now actually
> encourage duplicate efforts and/or solutions in the IETF???
> 
> Don't get me wrong: I'll do my best to help out widespread
> deployment and use of RoHC-based solutions that this WG has
> produced and is producing (my sponsor quite surely thinks
> this is good too ... but I'm just guessing here). I just
> can't support a solution that I believe has too many
> potential issues so that my fingers just can't stop writing
> long email answers. We've already had enough work with one
> implementer's guide to fix 3095, I don't want us to be left with that
> again. 
> 
> Best regards,
> 
> ///Ghyslain
> 
> 
> Kapoor, Rohit wrote:
> 
>> draft-kapoor-rohc-profiles-reordering-01.txt, so I'm not quite sure
>> what you are referring to.
> 
>>> seeing this in draft-
> kapoor-rohc-profiles-reordering-01.txt from the
>>> perspective the IETF normally takes when designing protocols and
>> handles all the issues required for reordering support (all the
>> issues identified in RFC 4224). I think it addresses the set of
>> changes that are required for support of reordering, while RoHC v2
>> makes other significant changes from RFC 3095.
>> that are looking for changes to RFC 3095 to support reordering
>> (without other changes).

---

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

Thomas,

I see two official liaison letters from 3GPP2 in the documents tracker,
but I cannot find any official answer from the IETF to those letters.
Have such been produced and exchanged (formally or informally) and if
so, where can I find the answers? I would like to understand how we
ended up where we are today, and why we are struggling with this.

I assume that by formally, such an answer would have been also forwarded
to the relevant company members of the 3GPP2 working groups, and that by
informally it might not necessarily be the case.

Best regards,

///Ghyslain

Thomas Narten wrote:
> Lars-Erik Jonsson (ROHC chair), AC Mahendran (3GPP2 Liaison
> to IETF), Thomas Narten (IETF Liaison to 3GPP2) and Rohit
> Kapoor participated in a call on September 18 (and have held
> subsequent discussions) on the topic of the 2 liaison
> statements from 3GPP2 to the ROHC WG:
> 
> We then discussed the various options for producing an
> updated profile that would meet 3GPP2's needs. Four
> possibilities were discussed:
> 
> Does the WG have thoughts on how best to go forward with
> this, and/or which of the above options they would prefer?
> 
> Thomas
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Nov 2006 11:26:54 +0100

Hi,

Based on this discussion there is clearly no consensus (not even rough) 
in the WG to accept this document as something to work on or being 
allowed to publish. In regards to the four ways forward, the lack of 
consensus blocks 1. As the WG is working on solutions in this space and 
which hopefully will produce result in a not that distant future any 
publication using 2 or 3 would be considered an attempt to bypass the 
WG. Thus I see the only acceptable solution is 4.

However this discussion has clearly provide some feedback on the 
proposed solution. I recommend that 3GPP2 if publishing 
draft-kapoor-rohc-profiles-reordering do take these comments into 
account to improve the solution. I also think there are willingness from 
the WG to provide some further comments on updated version of the proposal.

Best Regard

Magnus Westerlund

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------