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

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 9 Oct 2003 13:17:54 +0200

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).

> 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.

/L-E

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

---

From: Remi Pelland <[email-masked]>
Date: Fri, 10 Oct 2003 09:36:51 -0400

Hi Kristofer,

Thanks for your answers, they did help.

For the "compressed/uncompressed" items in 5.8.6, like you I believe that
this is the only interpretation, but if you take the sentence litteraly
(like I did), it does raise some interrogations.  No more concerns on that.

As for IG section 5.4, I'm a little embarrassed to admit that I didn't
realize it was actually making a point of enforcing encoding type 0 for
lists included in UO-1-ID packets.  I know, it's clearly written down, but I
thought the first paragraph was simply providing a background for what is
following (i.e. translation table updates).  Sorry, my mistake.  I was only
focusing on the translation table updates explanation.  

So now I get it finally, UO-1-ID packets can only carry generic lists.
Fine.  What's the motivation behind this?  Is there something in the
compressed list mechanism or in the UO-mode scheme that prevents from using
types 1, 2 and 3 with UO-1-ID? (For my own understanding, I'm not trying to
change anything at this point.)

Thanks again,
Rémi.

-----Original Message-----
From: Kristofer Sandlund [mailto:[email-masked]]
Sent: Friday, October 10, 2003 3:15 AM
To: Remi Pelland
Cc: 'Lars-Erik Jonsson (LU/EAB)'; [email-masked]'
Subject: Re: [rohc] Questions on compressed lists.

Hi Remi,

answers inlined.

/Kristofer Sandlund, Effnet AB

Remi Pelland wrote:
> Lars-Erik,
> 
> Thanks for your answers.  Please see [RP] inline, I still have some
> questions about this.
> 
> Thanks,
> Rémi.
> 
> 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...
> 
> 
> [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 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?

> [RP] I must have missed something, because I don't understand why this
> 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.