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

From: [email-masked]
Date: Thu, 19 Sep 2002 18:10:08 -0500

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

---

From: "Mikael Degermark" <[email-masked]>
Date: Thu, 19 Sep 2002 10:47:55 -0700

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"

---

From: "Mikael Degermark" <[email-masked]>
Date: Thu, 19 Sep 2002 10:44:19 -0700

Hi Zhigang,

Cheers,

Micke
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>