Subject: RE: [rohc] TCP packet formats (help me!)

From: "Finking, Robert" <[email-masked]>
Date: Mon, 11 Oct 2004 10:02:13 +0100

Hi Kris,

Thanks for the reply. My own understanding of list encoding here is
probably faulty - questions in line below =) However, there was an
intention to provide a modicum of generalisation here too, which Mark
requested for the packet formats. I don't think anybody was replying to my
mails at the time, so I'll fully agree there was no consensus on it, other
than between Mark an I, and that was most definitely off the list - it was
verbal! So I'll try and describe things below and then we can all discuss
it.

]I'm not sure that I agree here. My view is that if there is a list in
]the compressed packet, then items are either present in the LIST
](_list_item form) or present in the IRREGULAR CHAIN (_irregular form).
]In the former case, the _list_item has only one possible format and in
]the latter case then the entry in the list is always empty so it's one
]format here as well (nothing).

Hang on isn't it the other way around? I.e. I am reading your above
paragraph as though the irregular form is always absent, and the static
form is always present, but I thought it was the other way around?:

       "   X = 1 indicates that the item corresponding to the Index
                 is sent in the item 0, ..., item n list.
           X = 0 indicates that the item corresponding to the Index is
                 not sent.
        <snip>

        Item 1, ..., item n:

           Each item corresponds to an XI with X = 1 in XI 1, ..., XI m."
RFC 3095

So that items only appear in the list if it isn't in the table already -
or is that what you were saying - sorry if I've misunderstood, I think I
am perhaps confusing "irregular chain" with "list" - are they the same
thing? If not, please help me out =)

]Therefore, only one format is needed for
]creating the list entry for each type, while the irregular stuff is just
]independent of this and not part of the list.
]So, what I've done is the following:
]
]list_tcp_options(list_length_in_bytes) ===
]{
]         % Length is not known a priori on decompressor, so we use a
sentinel.
]         end_of_list_sentinel ::= uncompressed_value(8, 0);
]	end_of_list_padding  ::= uncompressed_value(8, 1);
]
]         mss            ::= format_mss_list_item;
]         wscale         ::= format_wscale_list_item;
]         tsopt          ::= format_tsopt_list_item;
]         sack           ::= format_sack_list_item;
]         sack_permitted ::= format_sack_permitted_list_item;
]         eol            ::= format_eol_list_item;
]         nop            ::= format_nop_list_item;
]         generic        ::= format_generic_list_item;
]};
](the _list_item encodings are almost unchanged from Mark's packet
formats).
]
]This way, the FN should know that if one of them is not present, no
]encoding method needs to be applied to that specific item and removing
]the need for "has_context" stuff that anyway seems to be outside the
]scope of FN.
]Or?

Yes, this makes sense. However, Mark requested access to the context bit
(i.e. "X" in 3095), so that we could explicitly provide two different
encodings to get maximum efficiency. What this means is, if X=1 we have
one encoding, if X=0 we have another. At present, if X=0 we automatically
default to using static encoding and hence the item is absent from the
list (if I have understood correctly) - this just gives us a mechanism to
override that default encoding.

Some items, such as end of list, have a permanently fixed value, so there
is no point in having two different encodings for that item. Other items
fit more nicely into the 3095 pattern and need defining as irregular
initially, and after that as static. However a lot of items have e.g. a
fixed length, so it is wasteful to send the whole thing as irregular, you
just need to send the type and value - the length can be encoded with
uncompressed_value. After that, the type and length may be static, but the
value may change, so in that case we don't want to just use static
encoding by default as it will fail.

Having said this, I realise there is a mistake in my example, in that I've
encoded the type field for tsopt as uncompressed_value also, which means
that the decompressor has no way of telling which list item it is dealing
with - D'oh!

Does this make sense?

I guess it comes down to whether we want the facility to squeeze those
extra bits out or not.

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Mon, 11 Oct 2004 11:50:24 +0200

Hi Robert!
Comments inline.

> form is always present, but I thought it was the other way around?:

Nope. You need to take a look at the TCP profile (-07.txt).
The "irregular chain" is something that you use in all packets (but it can be 
empty if the item is supposed to be non-changing). An option's list item is 
included there is it is present in the context, and we decided that constuction 
of this is defined in english.
The list_item is present or not present every time a list is trasnmit.

> override that default encoding.

Noooooo. When X=0 there is no item whatsoever. It is always empty, both in 3095 
and in TCP.

> encoding by default as it will fail.

Again. Irregular chain, not in list. You don't win anything by having multiple 
formats when we have the irregular chain instead. The list itself should only be 
sent when the structure of the list changes (insert/delete of new options).

> that the decompressor has no way of telling which list item it is dealing

Some of the items will have reserved index values (see tcp-07) and therefore 
only a few of them need to explicitly send type.

/Kristofer