Subject: RE: [rohc] Query

From: "Sarkar, Biplab" <[email-masked]>
Date: Mon, 31 Jul 2006 16:49:58 +0530

Ghyslain/All,

I was thinking of negotiating some ROHC version with some off-band signaling, like the "max-cid" parameter, so that we can go ahead implementing the ROHC stack as per RFC3095 and later on put the enhanced version with different ROHC versions. Since I see there are a lot of discussions regarding robustness (Rohcv2  drafts) and avoidance of drastic changes (draft-kapoor-rohc-profiles-reordering-00.txt).

This way we can easily go for back ward compatibility as well as future enhancements.

Thanks
Biplab

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 4:04 AM
To: Sarkar, Biplab
Cc: [email-masked]
Subject: Re: [rohc] Query

Hi Biplab,

I am not exactly sure I understand your query.

My understanding is that the terminoöogy "RoHCv2" simply means the set of 
profiles that updates the profiles based on RFC3095, which later got the 
nickname "RoHCv1". However, the profile identifier used by RoHC as defined in 
RFC3095 and in the framework document (e.g. profile 0x0001 for "RoHCv1" RTP 
profile, and 0x0101 for the "RoHCv2" RTP profiles) already provides for 
backward compatibility over the ROHC channel defined in the framework.

Note also that the framework draft simply defines the framework separatedly 
from the profiles, but it is by all means entirely compatible with the 
definition in RFC3095. Actually, it is the same, some things might however be 
expressed more clearly.

So, the framework does not change because of RoHCv2 profiles, thus the 
requirements for the negotiation are exactly the same. The profile identifiers 
follow the framework definition, and thus makes RoHCv2 and RoHCv1 profiles 
compatible for both negotiation and usage over the same RoHC channel.

So, what did you have in mind with respect to "introducing some protocol 
version"? Maybe I have missed your point?

Regards,

/Ghyslain

Quoting "Sarkar, Biplab" <[email-masked]>:

> All,
> 
>  
> 
> Is there a plan to implement some sort of protocol version for ROHC
> compression for proper negotiation and backward compatibility? Since now we
> have ROHCv1 and ROHCv2, will it be a good idea to introduce some protocol
> version too?
> 
>  
> 
>  
> 
> Thanks
> 
> Biplab 
> 
> 

"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: "Lars-Erik Jonsson" <[email-masked]>
Date: Mon, 31 Jul 2006 13:42:34 +0200

Any change we do would mean we have created a new profile or profile 
set, and our profile number space should be more than enough to identify 
the different profiles this WG can reasonably be expected to produce (as 
well as potential profiles developed by others). Thus I do not see a 
need for additional version numbers, especially not "dirty implicit 
interpretations". The profiles we are currently chartered to develop are 
not many, but of course some may be added through the normal process of:
- Showing a *real* need for additional profile(s)
- Getting people willing to do the work
- Convincing the WG and the AD/IESG about the need for the IETF do 
produce these profiles

I do not expect many new profile suggestions to make it through the 
above process, while we have many profile numbers to make use of.

Cheers,
/L-E

----- Original Message ----- 
From: "Sarkar, Biplab" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 31, 2006 1:19 PM
Subject: RE: [rohc] Query

Ghyslain/All,

I was thinking of negotiating some ROHC version with some off-band 
signaling, like the "max-cid" parameter, so that we can go ahead 
implementing the ROHC stack as per RFC3095 and later on put the enhanced 
version with different ROHC versions. Since I see there are a lot of 
discussions regarding robustness (Rohcv2  drafts) and avoidance of 
drastic changes (draft-kapoor-rohc-profiles-reordering-00.txt).

This way we can easily go for back ward compatibility as well as future 
enhancements.

Thanks
Biplab

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 25, 2006 4:04 AM
To: Sarkar, Biplab
Cc: [email-masked]
Subject: Re: [rohc] Query

Hi Biplab,

My understanding is that the terminoöogy "RoHCv2" simply means the set 
of
profiles that updates the profiles based on RFC3095, which later got the
nickname "RoHCv1". However, the profile identifier used by RoHC as 
defined in
RFC3095 and in the framework document (e.g. profile 0x0001 for "RoHCv1" 
RTP
profile, and 0x0101 for the "RoHCv2" RTP profiles) already provides for
backward compatibility over the ROHC channel defined in the framework.

Note also that the framework draft simply defines the framework 
separatedly
from the profiles, but it is by all means entirely compatible with the
definition in RFC3095. Actually, it is the same, some things might 
however be
expressed more clearly.

So, the framework does not change because of RoHCv2 profiles, thus the
requirements for the negotiation are exactly the same. The profile 
identifiers
follow the framework definition, and thus makes RoHCv2 and RoHCv1 
profiles
compatible for both negotiation and usage over the same RoHC channel.

Regards,

/Ghyslain

> have ROHCv1 and ROHCv2, will it be a good idea to introduce some 

"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: Mon, 31 Jul 2006 18:18:49 +0200

Hi Biplab,

Then I understood you correctly ... and I think that my previous answer is 
still applicable to your query.

> I was thinking of negotiating some ROHC version with some off-band signaling,
> like the "max-cid" parameter, so that we can go ahead implementing the ROHC
> stack as per RFC3095 and later on put the enhanced version with different
> ROHC versions.

I don't see why there would be any new requirements on the negotiation or needs 
for out-of-band signalling other that what the RoHC framework already requires 
(see also RoHc-over-PPP fopr example) from the fact that we are proposing to 
update some of our existing profiles. The RoHC framework is already providing 
all the necessary means for these profiles to be negotiated unambiguously via 
the profile identifier.

Furthermore, out-of-band signalling is somewhat outside the scope of this WG 
anyway once e.g. the profiles identifiers and the common packet type 
indentifiers are defined at the framework level.

> Since I see there are a lot of discussions regarding
> robustness (Rohcv2  drafts) and avoidance of drastic changes
> (draft-kapoor-rohc-profiles-reordering-00.txt).

I have not yet seen anything that leads me to believe that there is a necessity 
for the framework to be modified from these discussion. It is true however that 
we have proposed a new parameter for the negotiation part (REORDERING_DEPTH) 
but this was meant to be optional, and alternatives (e.g. a feedback parameter 
that is profile specific) are also possible. In any case, our proposed 
parameter is not bound to a specific profile, and is optional, therefore it has 
no impact on backwrd compatibility.

And I don't think that the current discussions related to robustness inclduing 
reordering have any impact on the RoHc framework that would impact backward 
compatibility, no matter how many profiles and in what shape these come out of 
our disussions.
 
> This way we can easily go for back ward compatibility as well as future

As said, the RoHC framework already provides all the convenient facilities to 
achieve this already, in my understanding.

Regards,

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