[rohc] RE: Comments on draft-kapoor-rohc-profiles-reordering-00.txt

Ghyslain,

I would like to reiterate what has been said before in previous emails
that reordering support in RoHC is very important for 3GPP2. We
understand that there other issues as specified in RFC4224, but we are
( extremely ) very  interested in a quick fix to make the current
implementation based on RFC-3095 standard compliant. The RoHCv2 contains
a number of significant changes from the RoHC v1 profiles defined in RFC
3095. However, since work for support of VoIP over 3GPP2 air interface
is already at an advanced stage, we were looking for minor enhancements
to RFC-3095 profiles to include support for re-ordering and more
specifically fixing the interpretation interval offset, "p" value is one
of the main issue!
Having said that I am not sure why you would like to oppose to the draft
mentioned by Rohit, as such a draft is quite important for those
companies who have already implemented RoHC based on RFC-3095 and close
to commercial delivery. Certainly we agree with you that RoHCv2 will
address all the identified issues and this "quick fix" draft address a
very specific issue, but from 3GPP2 perspective we do believe as initial
deployment it would be sufficient to implement RoHC based on RFC-3095
but with fixing the "p" values and hence the important of this "quick
fix" draft.

Chokri

________________________________

	From: Kapoor, Rohit [mailto:rkapoor@qualcomm.com] 
	Sent: Monday, July 24, 2006 8:42 PM
	To: pelle@cdt.luth.se
	Cc: rohc@ietf.org; qinqing@lucent.com; Trabelsi, Chokri (Chokri)
	Subject: FW: Comments on
draft-kapoor-rohc-profiles-reordering-00.txt

	Ghyslain,

	Thanks for your comments. As some 3GPP2 companies have indicated
earlier, the need for this draft arises from the fact that 3GPP2
companies are close to commercial deployments having implemented RFC
3095 profiles. On top of this, reordering support is essential for good
performance in 3GPP2 systems. Thus, 3GPP2 companies are only looking for
small enhancements to RFC 3095 for efficient support of reordering.
Given commercial timelines, it would not be possible for 3GPP2 companies
at this stage to implement the newer RoHC v2 profiles for the upcoming
deployments.

	Please find some more comments below.

	> My comments:
	> ------------
	> On a high level I am not sure where a "quickfix" for
reordering for
	> RFC3095
	> profiles fits in the working group list of work items. I do
not believe
	> that
	> this is on our "menu" in that shape. Probably because both the
	> "Improvements"
	> draft and RFC4224 makes clear that this would be technically
insufficient.
	>

	<Rohit> Since this draft is essential for 3GPP2 companies, I
think it can be progressed in addition to the RoHC v2 draft. The RoHC v2
draft is addressing more issues than merely reordering, whereas this
draft is addressing only reordering issues.

	> Secondly, I think that RFC4224 is rather clear that the issue
on
	> reordering is
	> not limited to the interpretation interval offset. I have also
provided
	> more
	> information on this in my presentation in Montreal, see my
slides at:
	> http://www3.ietf.org/proceedings/06jul/slides/rohc-2.ppt
	>
	> Finally, I am personally opposed to this kind of quickfix
proposal
	> because:
	> - the draft and the proposed solution does not address
	>   all the potential issues related to reordering and
	>   the header compression algorithm it tries to modify;
	>   there is no clear analysis of what the remaining effects
	>   would be. Fixing "p" is not enough, this leaves open
	>   other issues. Lack of verification of some control fields
	>   is one for example.

	<Rohit> I think the draft addresses the other concerns brought
up in your slides by making recommendations for use of certain features
as Segmentation, List Compression etc (as described in RFC 4224). As far
as verification of some control fields, this issue also exists in RFC
3095 profiles and this draft is not adding further concerns on top of
those for RFC 3095. Moreover, the new field added to the IR packet in
this draft is covered by a CRC, so extra vulnerability is not being
added. Are there any other concerns you have?

	> - the proposal does not meet the content of the
	>   Improvements" draft, which represents the wg consensus
	>   and has done so for quite a long time now.

	<Rohit> This proposal is not meant to address all the contents
of the "Improvements" draft. This proposal only addresses a particular
need of 3GPP2 companies.

	> - RFC4224 already provides all the possible implementation
	>   guidance for mitigating effects of ooo delivery on
	>   RFC3095 profiles, i.e. it already pushes RFC3095 as far
	>   as it can go in this respect.
	>

	<Rohit> The proposal presented in the draft follows from the
examples in RFC 4224, particularly Section 6.2.2. So, it is based on the
recommendation of RFC 4224 on how to define new profiles with reordering
support.

	> Some other quick comments on the contents of this new
individual
	> submission:
	> - my understanding is that the proposed numbering of the
	>   profiles in page 3 is inconsistent with the RoHC WG praxis

	<Rohit> Thanks for pointing this out. We will look into this
issue.

	> - the proposal adds one octet to the already large IR
	>   header. We've tried to avoid this on purpose, because
	>   we feel that the IR should not be expanded beyond the
	>   size of the original header that it compresses.
	>

	<Rohit> IR packets are typically a small fraction of the total
packets in a flow. Thus, the addition of 1 octet to IR packets is
*almost* no impact at all. Also, even with RFC 3095 profiles, the IR
header size can exceed the size of the uncompressed IP headers.

	Thanks,
	Rohit

	>
	> Quoting "Kapoor, Rohit" <rkapoor@qualcomm.com>:
	>
	> > RoHCers,
	> >
	> >
	> >
	> > We have submitted the draft
	> > draft-kapoor-rohc-profiles-reordering-00.txt, which defines
RoHC
	> > profiles for RTP/UDP/IP, UDP/IP and ESP/IP that inherit most
of their
	> > functionality from ROHC v1 profiles described in RFC 3095,
except that
	> > efficient support for reordering is added.
	> >
	> >
	> >
	> > Note that the mechanism for reordering support in this draft
is inspired
	> > by and is very similar to that in the RoHC v2 profiles
draft,
	> > draft-pelletier-rohc-rohcv2-profiles-00.txt. This should
make it easier
	> > for implementations that wish to support both these as well
as v2
	> > profiles.
	> >
	> >
	> >
	> > The URL for this Internet-Draft is:
	> >
http://www.ietf.org/internet-drafts/draft-kapoor-rohc-profiles-reorderin
	> > g-00.txt
	> >
	> >
	> >
	> >
	> >
	> > The motivation for this draft comes from requirements of
3GPP2 member
	> > companies. During implementation and testing, 3GPP2
companies have
	> > noticed that adding re-ordering support to RoHC vastly
improves the
	> > overall system performance.
	> >
	> >
	> >
	> > Moreover, 3GPP2 member companies have already implemented
solutions
	> > based on RFC 3095 and are planning to roll out commercial
deployments of
	> > HRPD Rev-A based on RFC 3095 profiles. So, they are looking
for minor
	> > enhancements to RFC 3095 profiles to include support for
re-ordering.
	> > This draft describes RoHC profiles which capture such small
	> > enhancements.
	> >
	> >
	> >
	> > Comments are welcome.
	> >
	> >
	> >
	> >
	> >
	> > Thanks,
	> >
	> > Rohit, Chokri and Qinqing
	> >
	> >
	>
	>
	>