Subject: RE: [rohc] PROFILES negotiation and profile "versions"

From: [email-masked]
Date: Wed, 2 Oct 2002 12:52:26 -0500

Hi Mikael,

Thanks for the clarifications. However, the issue here is 
multiple "versions" of the same profile, not that we have 
more than 256 active profiles. 

For example, LLA profile as defined in RFC3242 has profile
number 0x0005. Then, if the new profile with 0-byte support
for R-mode (see rohc-rtp-lla-r-mode-03.txt) is assigned 
with profile number 0x0105, we will have to handle two
"versions" of LLA profile although we only have 6 profiles
in total (0x0000, 0x0001, 0x0002, 0x0003, 0x0005, 0x0105).

One quick solution is to assign profile numbers in sequence
(i.e. differs in LSB) if a new profile is incompatible with
existing profile even though it is a new "version". (To me, 
two versions of incompatible profiles *are* two different 
profiles from protocol point of view.) This simplifies negotiation 
for the first 256 profiles: decompressor announces, compressor 
selects one and signal it in IR header. Of course, even with
this assignment policy, any negotiation still needs to define
extra steps for profile numbers > 0x00FF. But I think it will 
take a *long* time before this WG generates more than 256 
profiles, if ever. So, it's reasonable to make our life easier
for the use of the first 256 profiles. 

BR,
Zhigang

> -----Original Message-----
> From: ext Mikael Degermark [mailto:[email-masked]]
> Sent: September 19, 2002 12:44 PM
> To: Liu Zhigang.C (NRC/Dallas); [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rohc] PROFILES negotiation and profile "versions"
> 
> 
> Hi Zhigang,
> 
> As far as I remember, the 16-bit profile identifiers came 
> into being when we
> tried to project the worst possible scenarios in terms of profile
> proliferation in
> an unknown future. Keep in mind that ROHC is not exclusively for 3G.
> It seems to me that the ROHC framework is versatile enough to 
> be used in
> pretty
> much any environment.
> 
> It certainly seemed that 256 possible profiles was too little.
> On the other hand we had already settled on packet formats and saw
> no good reason to have more than 256 *active* profiles.
> Therefore we didn't see that 16-bit profiles were needed in the packet
> formats, and hence avoided to change the (already agreed) 
> formats of IR
> and IR-DYN packets.
> 
> Therefore this compromise that
> 1) allows many future profiles, and upgrades of profiles.
> 2) still sends only 8 bits of profile for IR and IR-DYN packets.
> 
> So, to make a long story short: I think the 8 bit numbers for active
> profiles came first, and the
> negotiated 16-bit profile numbers came later.
> 
> Carsten, please correct me if you remember this differently.
> 
> Cheers,
> 
> Micke
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Sent: Thursday, September 19, 2002 4:10 PM
> Subject: RE: [rohc] PROFILES negotiation and profile "versions"
> 
> 
> > I agree. But then, what is the real reason behind "abbreviating"
> > the profile number in IR packets? Why didn't we just put
> > 16-bit profile number inside? It simplifies things and does
> > not add much overhead (only 1 byte extra to something >40
> > bytes, and IR packets are only sent at beginning of a new steam).
> >
> > BR,
> > Zhigang
> >
> > > -----Original Message-----
> > > From: ext Carsten Bormann [mailto:[email-masked]]
> > > Sent: September 19, 2002 4:08 PM
> > > To: Liu Zhigang.C (NRC/Dallas)
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]
> > > Subject: Re: [rohc] PROFILES negotiation and profile "versions"
> > >
> > >
> > > > This means after the spec for new version releases, all
> > > implementation
> > > > should upgrade to the new version.
> > >
> > > This ("all") is not going to happen (lots of old devices stay
> > > out in the field).
> > > It's definitely not happening on a "Flag day", so we have to
> > > cope with different
> > > implementation levels out there at the same time.
> > >
> > > > So, if a decompressor offers two 16-bit profile numbers
> > > that differs
> > > > only in MSB (i.e. version) but a compressor does not support the
> > > > higher version, the compression must not use either version.
> > >
> > > But that would punish any decompressor that is trying to
> > > upgrade -- it would no
> > > longer talk (efficiently) to the existing implementations out
> > > there in the
> > > field.  Upgrades that have this property never happen at all.
> > >
> > >
> > > While I do agree with the general sentiment that higher
> > > profile versions are
> > > meant to replace lower versions in the field, this does not
> > > make the job of the
> > > negotiation protocol easier in any way.  (It may change the
> > > sweet spot that you
> > > optimize for, but I don't think that is a big issue here.)
> > > The negotiation
> > > protocol must cope with (i.e. work correctly with) any
> > > feature combination out
> > > there, and its results never may punish the upgrader, or
> > > upgrades won't happen.
> > >
> > > Gruesse, Carsten
> > >
> > >
> >
> 
> _______________________________________________
> 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: "Mikael Degermark" <[email-masked]>
Date: Wed, 2 Oct 2002 23:20:58 -0700

Zhigang, 

I thought you asked about the rationale/history for the
current state of affairs. That is what I explained.

I guess this thread has to do with what profile id to give to 
0-byte for R-mode.
 
I am of the opinion that assinging a version, rather than
a new profile, now would force implementations to get
this negotiation right at this early stage. We would
thus avoid future problems. 

Therefore I would argue that it would be good engineering 
to bite the bullet now, rather than later, and assign profile 
id 0x0105 to 0-byte for R-mode. 

Getting this right now is much less of an effort than fixing
future negotiation incompatibility problems would be. 
I cast my vote is for making our lives easier down the road
rather than right now. 

Cheers, 

Micke