Subject: RE: [rohc] Limiting the number of IP header in IP-only profile

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 11 May 2004 14:47:21 +0200

Me and Kristofer have discussed this issue further and come up with
a change proposal. Please let us know what you think, both about the
technical issue/resolution as well as how we should move on with it.
Kristofer has convinced me that this is important for real-world
implementations, so our take on it is that we should try to get this
into the IP profile before publication, if at all possible.

BR
/L-E 

***** CHANGE PROPOSAL FOR THE IP PROFILE *****

OLD:
3.1.  Static Chain Termination
   One difference for IP-only compression, compared to IP/UDP
   compression, is related to the termination of the static chain in IR
   headers. For the UDP profile, the chain always ends with a UDP header
   part, which per definition provides the boundaries for the chain. The
   UDP header is also the last header in the uncompressed packet (except
   for a potential application header). For the IP-only profile, there
   is no single last header that per profile definition terminates the
   chain. Instead, the static chain is terminated if the "Next Header /
   Protocol" field of a static IP header part indicates anything but IP
   (IPinIP or IPv6).

NEW:
3.1.  Static Chain Termination
   One difference for IP-only compression, compared to IP/UDP
   compression, is related to the termination of the static chain in IR
   headers. For the UDP profile, the chain always ends with a UDP header
   part, which per definition provides the boundaries for the chain. The
   UDP header is also the last header in the uncompressed packet (except
   for a potential application header). For the IP-only profile, there
   is no single last header that per profile definition terminates the
   chain. Instead, the static chain is terminated if the "Next Header /
   Protocol" field of a static IP header part indicates anything but IP
   (IPinIP or IPv6). Alternatively, the compressor can choose to end the
   static chain at any IP header, and indicate this by setting the MSB
   of the IP version field to 1 (0xC for IPv4 or 0xE for IPv6). The
   decompressor must store this indication in the context for correct
   decompression of subsequent headers. Note that the IP version field
   in decompressed headers must be restored to its original value.

OLD (part of 3.2):
   As explained above, the static chain within IR packets can be of
   arbitrary length, and the chain is terminated by the presence of a
   non-IP header (not IPinIP nor IPv6). The dynamic chain is structured
   analogously.

NEW (part of 3.2):
   As explained above, the static chain within IR packets can be of
   arbitrary length, and the chain is terminated by the presence of a
   non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be
   explicitly terminated with a special IP version number, as described
   in section 3.1. The dynamic chain is structured analogously.

OLD (part of 3.5):
   1) By using an IR packet as in ROHC UDP, where the profile is
      0x0004, and the static chain ends with the static part of an
      IP header, where the Next Header/Protocol field has any value but
      IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is
      initialized to a random value when the first IR packet is sent.

   2) By reusing an existing context. This is done with an IR-DYN
      packet, identifying profile 0x0004, where the dynamic chain
      corresponds to the prefix of the existing static chain, ending
      with an IP header where the Next Header/Protocol field has any
      value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor,
      SN is initialized to a random value when the first IR-DYN packet
      is sent.

NEW (part of 3.5):
   1) By using an IR packet as in ROHC UDP, where the profile is
      0x0004, and the static chain ends with the static part of an
      IP header, where the Next Header/Protocol field has any value but
      IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field
      indicates termination (see section 3.1). At the compressor, SN
      is initialized to a random value when the first IR packet is sent.

   2) By reusing an existing context. This is done with an IR-DYN
      packet, identifying profile 0x0004, where the dynamic chain
      corresponds to the prefix of the existing static chain, ending
      with an IP header where the Next Header/Protocol field has any
      value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP
      version field indicates termination (see section 3.1). At the
      compressor, SN is initialized to a random value when the first
      IR-DYN packet is sent.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 11 maj 2004 10:51
> To: 'Kristofer Sandlund'; [email-masked]
> Subject: RE: [rohc] Limiting the number of IP header in 
> IP-only profile
> 
> 
> Kristofer,
> 
> I understand your concern and agree with your point. I also find
> your proposal reasonable. The question is, what should we do at
> this point? We could argue for making this change to the IP
> profile before publication, as it is a new problem that is
> unique for the IP profile, and it would be bad to not have
> that resolved. I am not sure this is a sufficiently significant
> problem in practice, but it might be tricky to implement it
> without the ability to limit the compressed chain length.
> 
> So, while we are anyway waiting for the IANA action, let's figure
> out what text should had been in the document. If we can agree on
> that, we can consider whether we should bother the AD's with it
> at this point.
> 
> /L-E
> 
>  
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Kristofer Sandlund
> > Sent: den 10 maj 2004 16:54
> > To: [email-masked]
> > Subject: [rohc] Limiting the number of IP header in IP-only profile
> > 
> > 
> > Hi all!
> > 
> > I know I'm a bit late here since the IP profile has passed 
> > last call, but 
> > there's one feature that I think could be quite useful to add.
> > 
> > Section 3.1 in ip-only-05.txt says:
> >     Instead, the static chain is terminated if the "Next Header /
> >     Protocol" field of a static IP header part indicates 
> > anything but IP
> >     (IPinIP or IPv6).
> > 
> > It would be useful for the compressor to decide to only 
> > compress a few of the IP 
> > headers instead of having to compress "all or none".
> > 
> > To do this, the compressor would somehow have to indicate in 
> > the static chain 
> > that an IP header is the last compressed IP header, even if 
> > the protocol field 
> > indicates the prescence of more IP headers.
> > 
> > Since only the IPv4 header has "reserved bits" (the 4 bits 
> > right after version), 
> > there are no free bits that work for both IPv4 and IPv4. But, 
> > since we're 
> > sending all 4 of the IP version bits, while we anyway only 
> > handle them to be "4" 
> > and "6", the IP only could be extended to work with some 
> > extra bit patterns.
> > 
> > The only of these four bits that actually needs to be read 
> > from the static chain 
> > is the third one (4=0100 and 6=0110) so any of the other 
> > three bits could be 
> > used to mark the end of the static chain. So, let's say that 
> > we use the top bit 
> > to indicate the end of the static chain, the version field would be:
> > 
> > 0100= IPv4 non-final header
> > 0110= IPv6 non-final header
> > 1100= IPv4 final header (end of static chain)
> > 1110= IPv6 final header (end of static chain).
> > 
> > Obviously, these changes would only need to apply to the IP 
> > profile since that 
> > is the only one that can terminate in an IP header, so this 
> > would not have any 
> > impact on any other profiles. If it can be added to the 
> > current IP-only profile 
> > that would be great but otherwise it might be something for 
> > the next revision of 
> > the profile.
> > 
> > Rgds,
> > 	Kristofer Sandlund, Effnet AB
> 
> _______________________________________________
> 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: "West, Mark" <[email-masked]>
Date: Tue, 11 May 2004 23:47:49 +0000 (GMT)

Hi all,

Looks like a reasonable proposal to me...  I'm not *completely* convinced
that manipulating the version field in this way doesn't come under the
heading of 'hack', but it strikes me as a pretty rational hack! :-)

My only observation would be that this allows a compressor to limit the
number of headers that it has to store in its contexts, but the
decompressor can only REJECT the flow (if it has insufficient storage).
That is, there's no 'reason code' for the decompressor to be able to say
'I can't handle that many headers' or for the decompressor to be able to
advertise, 'I can handle up to n IP headers'...

Cheers,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

On Tue, 11 May 2004, Lars-Erik Jonsson (LU/EAB) wrote:

> Date: Tue, 11 May 2004 14:47:21 +0200
> From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
> To: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>,
>      'Kristofer Sandlund' <[email-masked]>, [email-masked]
> Subject: RE: [rohc] Limiting the number of IP header in IP-only profile
>

---

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 12 May 2004 08:16:50 +0200

Hi Mark.

Since we added the CONTEXT_MEMORY feedback to the IP profile, the decompressor 
has a way of saying that "this specific flow should be compressed less 
agressively" instead of just REJECT. At reception of a CONTEXT_MEMORY, the 
compressor can choose to reduce the number of IP headers compressed instead of 
performing a profile downgrade to uncompressed. I agree that is it not an 
_exact_ reason, but with this, the "toolbox" for the compressor is improved.

Rgds,

---

From: "West, Mark" <[email-masked]>
Date: Wed, 12 May 2004 07:49:55 +0000 (GMT)

Hi Kristofer,

I must be getting old..!  I'd forgotten about the CONTEXT_MEMORY feedback
(as you could probably tell!)  Of course that will do the job just fine.

In which case, the proposed changes look good to me.

Cheers,

Mark.

On Wed, 12 May 2004, Kristofer Sandlund wrote:

> Date: Wed, 12 May 2004 08:16:50 +0200
> From: Kristofer Sandlund <[email-masked]>
> To: "West, Mark" <[email-masked]>
> Cc: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>,
>      [email-masked]
> Subject: Re: [rohc] Limiting the number of IP header in IP-only profile
>
> Hi Mark.
>