Subject: RE: [rohc] new-ID: ROHC values for Framed-Compression attribute

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 11 Oct 2005 15:01:57 -0400

Hi Ghyslain,

It is nice to hear from you as well. Thanks for the quick review and
comments. Please see my responses inline...

Regards,
Kuntal

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB)
[mailto:[email-masked]]
> Sent: Tuesday, October 11, 2005 11:11 AM
> To: Chowdhury, Kuntal; [email-masked]
> Cc: Seshadri, Arun
> Subject: RE: [rohc] new-ID: ROHC values for Framed-Compression
attribute
> 
> Hi Kuntal,
> 
> Good to hear from you! I especially liked the following passage in the
> draft:
> 
> "ROHC is being deployed worldwide and it is especially gaining
>    immense popularity in 3G wireless networks."
> 
[KC>] Yep...it is a true statement. AFAIK, ROHC is the only header
compression scheme that the operators are deploying in 3G.

> Seriously, here are my comments on your draft (actually, I mainly have
> questions because I don't know enough about Radius):
> 
[KC>] No problem.

> 1) Comparing Description in 5.13 of 2865 and your draft, I can't parse
the
> 3rd sentence of the first paragraph:
> 
> >     an Access-Request packet as a hint to the server that the NAS
> >     would prefer to use that compression, but the server is not
> >     required to honor the hint.
> 
> <     Access-Request packet as a hint to the server that the NAS would
> <     prefer to supports the use that a compression scheme, but the
RADIUS
> <     server is not required to honor the hint.
> 
> It seems that you redescribe the "use of" a compression scheme to
"support
> for". Is it the intention?
> Is this used as some sort of "parameter negotiation" within an
> authentication/authorization mechanism?
> 
[KC>] You are right. By including this attribute in Access-Request the
NAS indicates that it prefers to use the specified compression scheme
for the session. This is as per the RFC 2865 text. The text in this ID
is broken...we will fix it.

BTW, what I intended to say was "by including this attribute in
Access-Request the NAS indicates its header compression capability e.g.
ROHC to the RADIUS server."

Here are some of my thoughts:

a. How does the NAS indicate its capability to support multiple
compression schemes e.g. ROHC, VJ, IPX header compression etc.?
According to RFC 2865, the Framed-Compression attribute can be repeated
in the same message. But it is not clear whether the NAS can include
multiple instances of this attribute in the Access-Request to indicate
its capability-set to the RADIUS sever or it is just the RADIUS server
that can include multiple instances of this attribute in the
Access-Accept for the NAS to apply on the session. May be this can be
clarified in this ID.

b. May be the Framed-Compression attribute definition part should be
left as is to align with RFC 2865. However a new attribute can be
introduced to indicate NASs capability to the RADIUS server w.r.t. ROHC.
May be this attribute can have a bit-mask encoded value to indicate
multiple ROHC scheme or ROHC profile support at the NAS.

I would like to hear from you and others on these thoughts.

> The only other diff until the Value element is the addition of "in the
> same Radius message", which I understand as a clarification not being
a
> change from 2865.
[KC>] Yes.

> Then comes additional values:
> 
> >  TBD-1    RObust Header Compression [RFC3095].
> >
> >  TBD-2    VJ TCP/IP header compression and RObust Header Compression
> >           [ROHC-VJ].  When this value is negotiated, VJ compression
> >           is used for all TCP/IP traffic and ROHC compression is
used
> >           for remaining traffic (UDP/IP, RTP/IP, ESP/IP).
> >
> >  TBD-3    Link Layer Assisted RObust Header Compression [RFC3242].
> 
> So, bearing in mind again that I know nothing about Radius, I have the
> following questions:
> 
> 2) why values that relate to single (RoHC) profile (TBD-3) and single
> algorithm
>    (VJ, ...), are mixed with values that relate to many (RoHC)
profiles
>    (TBD-1 -> profiles 0, 1, 2, 3).
>    This seem to depart from the way values for this attribute are
> specified in 2865.
[KC>] Note that TBD-2 is an attempt to convey two things in one shot
i.e. use VJ for TCP flows and use ROHC for UDP/RTP/ESP/IP flows. This is
somewhat the same idea as bit-mask encoding. TBD-3 is specifically
called out with an explicit value here because it requires LLA support
from the RAN (radio access network). Not all NASs will have LLA support
even if it supports ROHC.

> 3) what is [RoHC-VJ]? I see the reference points to ROHC-TCP.
>    Do you mean the ROHC-TCP profile? The text does say VJ (1144) for
TCP
>    traffic and "ROHC compression" for other traffic.
>    I get completely confused. Honestly, I wouldn't know what the value
>    would mean as part of this attribute even if I'd be allowed to
guess!
[KC>] I see your point here and I apologize for the confusion. The
intent was to say VJ (1144) and ROHC (3095). We will fix this.

> 4) Is it not possible to define one value for ROHC only instead, no
matter
> what
>    profile is being used? Or is it useful to know what profile aka
type of
>    traffic is being compressed?
[KC>] I think it is useful to define separate values for different ROHC
profiles. In practice, a single value for ROHC may be too broad and NASs
may not support all ROHC profiles. I would request you and others to
chime in here.

> 5) How does this relate to the supported set of profiles being
negotiated
>    during the ROHC channel establishment? Does it have to be
absolutely
>    coherent with the profile set?
[KC>] The supported set of ROHC profiles are negotiated between MN and
the NAS. Hence, I would assume that the NAS would negotiate only those
profiles with the MN that it supports and that are returned in the
Access-Accept from the RADIUS server. Do you think we need this
clarification in this ID?

> 6) Assuming that the answer to 4) is no, and that each profile must
have
>    its own value, should values be also added for other ROHC profiles,
> e.g.
>    IP-Only profile, UDP-Lite, ROHC-TCP?
> 
> However, because 2865 says:
> 
>   "Some Attributes MAY be included more than once.  The effect of this
>    is Attribute specific, and is specified in each Attribute
>    description"
> 
> I would assume that it is possible to define one value per compression
> algorithm (in the case of ROHC preferably one value for all ROHC
traffic,
> alternatively one value for each ROHC profile), and then send multiple
> Framed-Compression attributes for each algorithm supported/used. Is
this
> correct? If it is, why not do so?
> 
[KC>] If we decide to have one value per ROHC profile, then we should
use a different attribute, IMHO. The (new) attribute can have bit-mask
encoded field to indicate multiple ROHC profiles. Otherwise, the NAS and
the RADIUS servers may need to include too many instances of the
Framed-Compression attribute in the RADIUS messages.

> How often do you have comments on a draft that are actually longer
than
> the draft itself ; )
[KC>] Not too often :o) Thanks again.

> /Ghyslain
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
Of
> > Chowdhury, Kuntal
> > Sent: den 11 oktober 2005 17:23
> > To: [email-masked]
> > Cc: Seshadri, Arun
> > Subject: [rohc] new-ID: ROHC values for Framed-Compression attribute
> >
> >
> > Hi all,
> >
> > We submitted the following draft to define the RADIUS
Framed-Attribute
> > values to support ROHC, LLA-ROHC and ROCH-TCP. Here is the abstract:
> >
> > "
> >    The definition of RADIUS attribute "Framed-Compression" in RFC
2865
> >    does not include values for new Header Compression schemes
> > like ROHC,
> >    ROHC-TCP.  This document defines the new values to the "Framed-
> >    Compression" attribute.
> > "
> >
> >
> > http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radiu
> > s-attribut
> > es-00.txt
> >
> >
> > We appreciate your comment on this.
> >
> > Regards,
> > Kuntal
> >
> >
> >
> >
> > "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
> >

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

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Wed, 12 Oct 2005 17:11:03 +0200

> negotiated during the ROHC channel establishment? Does it
> have to be absolutely coherent with the profile set?

[LEJ]: I might be a good idea to read the 3095 implementer's guide
section that talks about the PROFILES negotiation.

/L-E