Subject: [rohc] Small thingy for the implementer's guide

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 23 Aug 2005 14:56:44 +0200

5.8.4.  Special handling of IP extension headers

   In CSRC list compression, each CSRC is assigned an index.  In
   contrast, in IP extension header list compression an index is usually
   associated with a type of extension header.  When there is more than
   one IP header, there is more than one list of extension headers.  An
   index per type per list is then used.

Suggested clarification:
-------------------------
The text in section 5.8.4 should read "In CSRC list compression, each CSRC is assigned an index.  In IP extension header list compression, an index is associated with each individual extension header, i.e. where the same index is used for a header with a specific protocol number for which a field that is not part of the general packet format in section 5.7 have the same values.  When there is more than one IP header, there is more than one list of extension headers and a translation table is maintained for each list independently of one another."

Why? First, the destination option in IPv6 can occur twice, hence the (already void) sentence that says "usually" can be misleading. Second, it may be obvious that there is one TT for each IP layer, but section 6.5.1 could then have said it clearer (for example):

   UO_IETT: IPv6 Extension Header Translation Table(s) in U/O-mode

instead for:

   UO_IETT: IPv6 Extension Header Translation Table in U/O-mode

Tiny detail, I know I know... Funny enough, it seems that it would be possible to implement a compressor with one single TT for both IP levels and this would still be interoperable with any decompressor. The opposite (the decompressor with only one TT) would however lead to interop problems. So I thought it could be useful to fix these little things just in case. More clarity normally don't hurt?

... assuming everyone agrees with the above proposal, of course.

/Ghyslain 

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 24 Aug 2005 10:55:19 +0200

Ghyslain,

You're right, this is indeed confusing.
See comments on your proposed text below.

/L-E

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) 
> Sent: den 23 augusti 2005 14:57
> To: Lars-Erik Jonsson (LU/EAB); [email-masked]
> Subject: Small thingy for the implementer's guide
> 
> 
>    In CSRC list compression, each CSRC is assigned an index. 
>    In contrast, in IP extension header list compression an
>    index is usually associated with a type of extension header.
>    When there is more than one IP header, there is more than
>    one list of extension headers. An index per type per list
>    is then used.

I agree that "usually" is not an appropriate word to use here.

> The text in section 5.8.4 should read "In CSRC list 
> compression, each CSRC is assigned an index. In IP extension 
> header list compression, an index is associated with each 
> individual extension header, i.e. where the same index is 
> used for a header with a specific protocol number for which a 
> field that is not part of the general packet format in 
> section 5.7 have the same values. 

Wow, that was a long sentence. It might be correct, but it is
hard to parse. I think one first troublesome flaw is the "i.e."
since it is not clear whether the second part of the sentence
is restating and clarifying what the first part says, or if it
is actually a necessary complement to the first part.

Secondly, "for which a field.....have the same values", means
we are looking at several occurrences of the same field. With
a header compression mindset, it is natural to think the text
talks about same values in consecutive packets, but after 
looking at it several times, I guess you are addressing the
scenario where the same extension type is present several
times in one single extension header chain, i.e. you are
trying to make clear that for such cases one would have to
use different indexes.

> When there is more than 
> one IP header, there is more than one list of extension 
> headers and a translation table is maintained for each list 
> independently of one another."

Good point.

Suggested section for the implementer's guide:

5.8.  Translation tables and indexes for IP extension headers

  Section 5.8.4 aims at describing how list indexes are
  associated to list items and how table lists are built for
  IP extension headers. However, the text is not very clear
  about these things.

  In IP extension header list compression, an index is associated
  with each individual extension header. When there are multiple
  occurrences of the same extension type within a header chain,
  each will have to be given its own index (assuming they are not
  identical).

  When there is more than one IP header, there is more than one
  list of extension headers, and a translation table is maintained
  for each list independently of one another.

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Wed, 24 Aug 2005 11:40:10 +0200

> is actually a necessary complement to the first part.

Either way.
 
> trying to make clear that for such cases one would have to

Should have said "for which fields that are not part of the
general packet format in section 5.7 have the same values".
 
>   for each list independently of one another.

Actually, I care only about the last paragraph above and for the clarification regarding the sentence "An index per type per list is then used" from the original text from 3095, which I believe is not correct. 

Otherwise how to formulate this is up to the editor - provided we agree on those two small things. In other words, it is not really important for me if we explain further how the mapping of indexes is made since this is up to the compressor implementation and don't impact interoperation.

/Ghyslain

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 24 Aug 2005 13:03:47 +0200

Ghyslain,

> Actually, I care only about the last paragraph above and for 
> the clarification regarding the sentence "An index per type 
> per list is then used" from the original text from 3095, 
> which I believe is not correct. 

Agree!!

> Otherwise how to formulate this is up to the editor - 
> provided we agree on those two small things. In other words, 
> it is not really important for me if we explain further how 
> the mapping of indexes is made since this is up to the 
> compressor implementation and don't impact interoperation.

I've rewritten it as follows:

  Section 5.8.4 aims at describing how list indexes are associated to
  list items and how table lists are built for IP extension headers.
  However, the text is not very clear, and it is actually wrong to just
  say that an index per type is used, since the same type can appear
  several times with different content in one single chain.

  In IP extension header list compression, an index is associated with
  each individual extension header of an extension header chain. When
  there are multiple occurrences of the same extension type (Protocol 
  Number) within a header chain, each will have to be given its own
  index (assuming they are not identical). When content of extension
  headers changes, an implementation can choose to either initiate a
  new index, or update the existing one. Note that some extensions can
  be compressed away also when some fields change, as there are other
  means to explicitly or implicitly convey the changes.
 
  When there is more than one IP header, there is more than one list of
  extension headers, and a translation table is maintained for each
  list independently of one another. 

BR
/L-E