Subject: [rohc] RE: NEW TCP packet formats

From: "Finking, Robert" <[email-masked]>
Date: Tue, 12 Oct 2004 13:48:34 +0100

PS we seem to have strayed off the list again.... (CC'd to the list)

-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB) [mailto:[email-masked]] 
Sent: Tuesday, October 12, 2004 10:25 AM
To: 'Kristofer Sandlund'; Eilert Brinkmann
Cc: Carsten Bormann; Ghyslain Pelletier (LU/EAB); West, Mark; Finking,
Robert
Subject: RE: NEW TCP packet formats

> My view is that we really have a few different "modules"
> in the packet formats:
> static_chain (IR only)
> dynamic_chain (IR, IR-DYN)
> replicate_chain (IR-CR)
> irregular_chain (all CO packets)
> base_header (all CO packets)
> tcp_options_list (which is special, let me get back to this one)
>
> Where sections 6.5.1-6.5.3 of tcp-07 + the new text I proposed
> the other week describes which of these "modules" that the
> compressor is going to use / decompressor is going to expect.

Makes perfect sense to me!

> Therefore, the disambiguating (is this a word?) is handled by 
> which packet format I have I have. So, no need to have any
> form of logic to help decisions on these in the structures
> since the packet format decides what to use for chains and
> base header. Is that what you FN-people also feel or do you
> still feel that the current pf are lacking in this sense?
> If my understanding is correct, I just think that we should 
> use the text I proposed on the list earlier and beef it up
> (perhaps even with a small example section) so that the user
> understands that this is how compressed packets are
> assembled from the items in the FN.

Agree, I assume Ghyslain is updating the TCP profile draft,
we should get a new (WGLC-ready?) version before the ID cut-off.

BR
/L-E

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Thu, 14 Oct 2004 10:32:41 +0200

> From: Finking, Robert [mailto:[email-masked]]
> Sent: den 14 oktober 2004 10:15
> To: 'Kristofer Sandlund'; Carsten Bormann
> Cc: Eilert Brinkmann; Ghyslain Pelletier (LU/EAB); West, 
> Mark; Lars-Erik
> Jonsson (LU/EAB)
> ]Carsten Bormann wrote:
> ]> On Oct 13 2004, at 18:54 Uhr, Eilert Brinkmann wrote:
> ]> 
> ]>> 3. Extend the encoding method descriptions in the draft 
> to explicitly
> ]>>    state that compressed_value binds uncomp_length with 0 and
> ]>>    uncompressed_value binds comp_length with 0. This 
> would have the
> ]>>    advantage that there would be no cases in which 
> encoding methods
> ]>>    leave either the comp_* or the uncomp_* attributes 
> undefined. (But
> ]>>    one would still be free not to mention a field in one 
> of the field
> ]>>    order lists.) Effectively, this would make the following three
> ]>>    encodings equivalent:
> ]>>
> ]>>    compressed_value(0, 0)
> ]>>    uncompressed_value(0, 0)
> ]>>    irregular(0)
> ]> 
> ]> 
> ]> I'm a big fan of this.
> ]> I don't see a need for a field "not to have" one of the two sides 
> ]> (compressed and uncompressed) -- as you say, not 
> mentioning the field in 
> ]> the respective field list is sufficient for that to have 
> no effect on 
> ]> the parent field.
> ]> Not having the concept of "not having one side" simplifies the 
> ]> description significantly.
> ]> 
> ]> Gruesse, Carsten
> ]
> ]I agree that this seems like a good solution.
> ]
> 
> Missed the rest of the thread, but whatever the original 
> reason, I think this is a good idea. Otherwise you could 
> specify both compressed_value and uncompressed_value for the 
> same field name, but the two would be completely unrelated, 
> which would be confusing. I like this idea a
> lot =)
> 
> Cheers
> 
> Raffles

It might not look like it, but I am actually following these threads ; )
... and my first reaction was also that this seems best.

I don't like option 1) because the field does sometimes appear in the uncompressed header (and that would somewhat go against the idea behind uncompressed_format), I don't like 2) because it does abuse the irregular coding method. And option 3 does make complete sense!

(so no surprise from my side later on ; )

I will do the necessary changes to the FN draft.

BTW, I am copying the mailing list with included original message from Eilert - because this leads to a change to the draft.

/Ghyslain

> From: Eilert Brinkmann [mailto:[email-masked]]
> Sent: den 13 oktober 2004 18:55
> To: Kristofer Sandlund
> Cc: Carsten Bormann; Lars-Erik Jonsson (LU/EAB); Ghyslain Pelletier
> (LU/EAB); 'West, Mark'; Finking, Robert
> Subject: Re: NEW TCP packet formats
> 
> 
> Kristofer Sandlund wrote:
> > **********
> >          format_not_present = item, %[ 0 ]
> >          {
> >                  let (flag == 0);
> >
> >                  item ::= compressed_value (0, 0); % FIXME: 
> uncompressed_value?
> >          };
> > No, it should be "compressed value" since this field is not even
> > present in the uncompressed packet in this case. The field is only
> > sometimes in there.
> 
> No, it has a length of 0 bits in this case (which is true for the
> compressed side as well), but according to the specification it is
> present. The complete structure looks like this:
> 
> optional32 (flag) ===
> {
>         uncompressed_format = item; % 0 or 32 bits
> 
>         format_present = item, %[ 32 ]
>         {
>                 let (flag == 1);
>                 item ::= irregular (32);
>         };
> 
>         format_not_present = item, %[ 0 ]
>         {
>                 let (flag == 0);
>                 item ::= compressed_value (0, 0);
>         };
> };
> 
> Formally the field "item" is always part of the uncompressed format,
> although it's length might be 0 bits, so the field's uncompressed side
> must be bound. According to the current FN draft compressed_value "is
> used to define fields in the compressed header for which there is no
> counter-part in the uncompressed header", i.e. we can not use it in
> cases like this where the field is mentioned in the field order list
> of uncompressed_format. The description does not even say that the
> compressed_value encoding method binds uncomp_length with 0, so it's
> effect on the uncompressed side is currently undefined. (With
> uncompressed_value it's the other way around.)
> 
> I see three solutions:
> 
> 1. Remove item from the field order list in format_not_present and use
>    the uncompressed_value encoding method to bind item:uncomp_value
>    with 0, i.e. the compressed format's field list will be empty:
> 
>         format_not_present =
>         {
>                 let (flag == 0);
>                 item ::= uncompressed_value (0, 0);
>         };
> 
> 2. Use irregular(0) to bind item:uncomp_length as well as
>    item:comp_length with 0:
> 
>         format_not_present = item, %[ 0 ]
>         {
>                 let (flag == 0);
>                 item ::= irregular (0);
>         };
> 
>    A variant of this would be the use of only one compressed format in
>    this structure with a variable-length irregular encoding as once
>    suggested by Robert:
> 
>      optional32 (flag) ===
>      {
>         uncompressed_format = item; % 0 or 32 bits
> 
>         compressed_format = item, % 0 or 32 bits
>         {
>                 let (flag == 0 || flag == 1);
>                 item ::= irregular (32 * flag);
>         };
>      };
> 
> 3. Extend the encoding method descriptions in the draft to explicitly
>    state that compressed_value binds uncomp_length with 0 and
>    uncompressed_value binds comp_length with 0. This would have the
>    advantage that there would be no cases in which encoding methods
>    leave either the comp_* or the uncomp_* attributes undefined. (But
>    one would still be free not to mention a field in one of the field
>    order lists.) Effectively, this would make the following three
>    encodings equivalent:
> 
>    compressed_value(0, 0)
>    uncompressed_value(0, 0)
>    irregular(0)
> 
> Am I wrong with this or does anyone see other and possibly better
> solutions?
> 
> Regards
> 
> Eilert