RE: [rohc] 3GPP2's need for

["Trabelsi, Chokri \(Chokri\)" <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, November 14, 2006 10:51 AM
To: Thomas Narten; [e-mail]
Cc: AC Mahendran
Subject: RE: [rohc] 3GPP2's need for 

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

> Some of the issues that were discussed:
> 
>   - There is (and has already been) testing with updated profiles that
>     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.
 
>   - Operators hope to begin deployments starting next year, and are
>     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.
 
>   - 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. 

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

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

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.

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

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

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?

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

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: [phone]
 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.
-----------------------------------

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

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