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

From: "Sarkar, Biplab" <[email-masked]>
Date: Wed, 23 Aug 2006 15:10:40 +0530

Rohit,

I think the new draft is not backward compatible to RFC-3095's IR pkts
because of the new field for 'p'. 

Won't that be a problem?

Thanks

Biplab

________________________________

From: Kapoor, Rohit [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 6:12 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Trabelsi, Chokri (Chokri)
Subject: [rohc] 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" <[email-masked]>:
>
> > 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
> >
> >
>
>
>

"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: "Kapoor, Rohit" <[email-masked]>
Date: Wed, 23 Aug 2006 12:22:25 -0700

Biplab,

It is not intended to be backward-compatible. The profile numbers in the
draft will be different from (or newer versions of) the 3095 profile
numbers. So, there should not be any problem.

Thanks,

Rohit

From: Sarkar, Biplab [mailto:[email-masked]] 
Sent: Wednesday, August 23, 2006 2:41 AM
To: Kapoor, Rohit; [email-masked]
Cc: [email-masked]; [email-masked]; Trabelsi, Chokri (Chokri)
Subject: RE: [rohc] FW: Comments on
draft-kapoor-rohc-profiles-reordering-00.txt

Rohit,

Won't that be a problem?

Thanks

Biplab

Ghyslain,

believe
insufficient.

provided

Thanks,
Rohit

their
that
inspired
easier
member
deployments of
minor
re-ordering.
> > Rohit, Chokri and Qinqing

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

---

From: [email-masked]
Date: Wed, 23 Aug 2006 22:36:22 +0200

Rohit,

I think that Biplab meant that the packet format that is defined in section 
4.1, where the "RR" field is placed in one octet between the profile and CRC 
octets, is not compatible with the general format of the IR packet, as defined 
in section 5.2.3 of RFC3095. Thus this change is not compatible with the RoHC 
_framework_.

Biplad's observation is entirely correct - it will be a problem in the format 
that is proposed.

It can easily be solved by moving any profile-specific octet after the CRC 
field, i.e. somewhere in the profile-specific part of the IR format.

///Ghyslain

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Wed, 23 Aug 2006 13:41:01 -0700

Biplab and Ghyslain,

Thanks for pointing this out. I will make the appropriate change in
version 01.

Thanks,
Rohit

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2006 1:36 PM
> To: Kapoor, Rohit
> Cc: Sarkar, Biplab; [email-masked]; [email-masked];
[email-masked];
> Trabelsi, Chokri (Chokri)
draft-kapoor-rohc-profiles-reordering-
> 00.txt
> 4.1, where the "RR" field is placed in one octet between the profile
and
> CRC
> in section 5.2.3 of RFC3095. Thus this change is not compatible with
the
> RoHC