Subject: RE: [rohc] Questions on compressed lists.

From: Remi Pelland <[email-masked]>
Date: Thu, 9 Oct 2003 10:05:39 -0400

Lars-Erik,

Thanks for your answers.  Please see [RP] inline, I still have some
questions about this.

Thanks,
Rémi.

-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB) [mailto:[email-masked]]
Sent: Thursday, October 09, 2003 7:18 AM
To: 'Remi Pelland'; [email-masked]'
Subject: RE: [rohc] Questions on compressed lists.

Some answers inline...

> -----Original Message-----
> From: Remi Pelland [mailto:[email-masked]]
> Sent: den 26 september 2003 22:54
> To: [email-masked]'
> Subject: [rohc] Questions on compressed lists.
> 
> 
> Hi,
> 
> RFC-3095, section 5.8.6 says that: "... In CSRC lists, the 
> items are CSRC identifiers; in header lists, they are
> uncompressed or compressed headers, as described in 5.8.4.2-4".
> 
> I'm not clear on the "uncompressed or compressed headers" for 
> IP extension headers.  Does this mean that for a given extension
> header type, the associated list "item" may have two different
> formats: compressed or uncompressed?  If this is the case, how
> does a decompressor know when the received items are compressed
> or not?

If it is present (X=1), it is included in its uncompressed form,
otherwise it is not present or in some cases compressed (only SN
and/or AH-data/GRE-chksum).

[RP] In the case where X=0 and the items are sent compressed, these
compressed values are not part of the "item 1, ..., item n" described in
sections 5.8.6.1-4. Right?  (My confusion originates from the fact that
section 5.8.6 gives the details of the compressed list formats and what they
each can include.  The sentence above seemed to imply that "item x"
associated with one of the XIs in the list may be compressed or
uncompressed.)

> The implementer's guide, section 5.4 says that the translation
> table should be updated when a UO-1-ID packet carrying a list
> with "Encoding Type 0" is received.  Shouldn't this also apply
> when new items are received in lists using encoding types 1 and 3?

Impl-guide 5.4 says:
    This section describes the situation when a UO-1-ID packet
    carries a compressed list.  Compressed lists are encoded using
    Encoding Type 0 (section 5.7.5 and 5.8.6.1) and every list may
    have a unique identifier (gen_id).

I.e., the case you mention should not happen.

[RP] I must have missed something, because I don't understand why this
situation could not happen.  Could you please elaborate?  Thanks.

/L-E

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 10 Oct 2003 09:15:17 +0200

Hi Remi,

answers inlined.

/Kristofer Sandlund, Effnet AB

> associated with one of the XIs in the list may be compressed or

The quote you give from 5.8.6, says that the compressed/uncompressed items are 
described in 5.8.4.2-4.
Here's an example from 3095 describing uncompressed/compressed item for the ESP 
NULL header (section 5.8.4.3).

 >   The information which is part of an uncompressed item of a compressed
 >   list is the Next Header field, followed by the SPI and the Sequence
 >   Number.  Padding, Pad Length, Next Header, and Authentication Data
 >   are sent as-is at the end of the packet.  This means that the Next
 >   Header occurs in two places.

<snip>

 >   A compressed item consists of a compressed sequence number.  When an
 >   item is compressed, Padding (if it follows the 1, 2, ..., k pattern)
 >   and Next Header are removed near the end of the packet.
 >   Authentication Data and Pad Length remain as-is near the end of the
 >   packet.

The sequence number is naturally inside the extension 3 sequence number fields 
(5.8.5.1). So, therefore no fields are inside the compressed list. Similar can 
be read in the other sections mentioned above.

I can agree that there could be a "better" explanation of this that covers all 
headers, but I think there's only one possible interpretation of the current 
text. L-E could possibly add an explanation to the implementer's guide?

> situation could not happen.  Could you please elaborate?  Thanks.

The text above from the implementer's guide says that "Compressed lists are 
encoded using Encoding Type 0", i.e. you must use the Generic scheme. Therefore 
it is not legal for the compressor to send type 1,2,3 lists inside a 
UO-1-ID-packet. So if your decompressor sees a UO-1-ID with types 1 or 3, it is 
a bad packet and should not update your translation table.

Hope this helps.