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

From: "Finking, Robert" <[email-masked]>
Date: Thu, 7 Oct 2004 11:23:26 +0100

]Since the CO packet formats are "base headers" and are a compressed 
]preresentation for both the TCP header AND the innermost IP header, the 
]uncompressed format should really be one (IPv4 or IPv6) and one TCP header.
]Therefore, I've added something like:
]
]ip_hdr === {
]        uncompressed_format = inner_ip;
]
]        format_inner_v4 = ipv4,
]        {
]		inner_ip ::= ipv4;
]        }
]
]        format_inner_v6 = ipv6,
]        {
]		inner_ip ::= ipv6;
]        }
]
]};
]
]tcpip_co === {
]
]    uncompressed format =  ip_hdr, % 160 or 320 bits
]         		  tcp;    % 160 + n bits
]
]....
]
]Is this possible with FN? If not, any suggestions how to solve this?

Yes, that's totally fine - it is intended to be used in just that fashion. The only restriction on doing that is that both the compressor and the decompressor must be able to disambiguate the two options. The compressor must be able to distinguish between the two, since they have two different semantics; the decompressor for the usual reason! It must always be possible to do this at the compressor end, otherwise you have an ill defined problem - it's just a case of notating it correctly. At the decompressor end, it's dependent on whether the compressed formats have intrinsically any distinguishing features which make it possible to tell them apart. If it's not possible, then you need to add an explicit discriminator, to differentiate between the two compressed formats. Does that answer your question, or did I just confuse things more?

]Issue 2:
]*************************
]default_methods for the tcpip_co. Mark just listed all fields from IPv4 
]and TCP here, but in line with issue 1, this is not really correct.
]It is clearly "enough" information, but how do I express that IPv4 TOS 
]equals IPv6 TC and the same for TTL/HOPLIMIT?

I think the answer is you need to give the fields the same name. So instead of calling it tc in IPv6 and tos in IPv4, call it tos_tc or some similar in both.

]Also, do I need to make some provisions for fields that only appear in 
]one of the IP headers such as DF, MF?

Ag, I don't have enough knowledge of the protocols do know what DF and MF are, so I'm not quite sure what you're asking. Could you explain what it is you want in simple terms - preferably slowly, maybe using examples that only involve sandwiches ;-)

]Issue 3:
]**********************
]List encoding. (once again, this mammoth rises up and bites us all in 
]the ass).
]I must admit that I thought the latest FN (Robert's text) had cleared 
]this up, but now I don't really see how to use it.
]For TCP options, I will define a structure tcp_options, but HOW should I 
]write this (Robert, this is aimed at you)?. I read the examples in FN, 
]but hit a brick wall. What I would have liked would be to have a 
]structure that creates both "list header", "xi_list" and "item_list" 
]instead of having to do each of these separately in each profile using 
]list encoding.
]
]Please provide me with sample FN for this, 'cause I got about this far:
]tcp_options ===
]{
]	list_header;
]	xi_list;
]	item_list;
]};
]Which of course is just BS.

=) The notation does create the "list header", "xi_list" and "item_list" instead of having to do each of these separately.

First off, note that all identifiers for lists start with "list" - this the unique bit of syntax that defines this as a list, rather than a regular structure (unless anybody has a better idea). The second thing, is you have to have a length parameter, which has the fixed name "list_length_in_bytes". All you then need to do is include the encodings for each of the possible items in the list (including the special cases of the terminating item and subsequent padding). To quote the example in the FN draft:

  list_tcp_options(list_length_in_bytes) ===
  {
    end_of_list_sentinel ::= uncompressed_value(8, 0);
    end_of_list_pad      ::= uncompressed_value(8, 1);
       :                        :
    timestamp            ::= tcp_timestamp_list_item();
       :                        :
       :                        :
    etc.
  };

  tcp_timestamp_list_item() ===
  {
    uncompressed_format = type,
                          length,
                          timestamp_value,
                          timestamp_echo_reply;

    default_methods =
    {
      type        ::= uncompressed_value(8, 8);
      length      ::= uncompressed_value(8, 10);
    };

    compressed_format_first = timestamp_value,
                              timestamp_echo_reply
    {
      let (this:has_context == false);
      timestamp_value      ::= irregular(32);
      timestamp_echo_reply ::= irregular(32);
    };

    compressed_format_subsequent = timestamp_value,
                                   timestamp_echo_reply
    {
      let (this:has_context == true);
      timestamp_value      ::= lsb(16, 0);
      timestamp_echo_reply ::= lsb(16, 0);
    };
  };

Note the use of the has_context attribute, and the fact that the "with context" encoding doesn't have to be static, and that the "without context" encoding doesn't have to be irregular.

I hope this helps! Please feel free to ask more questions - I'm quite pleased with the list notation =)

Cheers

Raffles

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2004 12:27:35 +0200

On Oct 07 2004, at 12:23 Uhr, Finking, Robert wrote:

> The compressor must be able to distinguish between the two, since they 
> have two different semantics; the decompressor for the usual reason! 
> It must always be possible to do this at the compressor end, otherwise 
> you have an ill defined problem

My view is that it's perfectly legal to have ambiguous compression -- 
obviously, you can always send an IR but there may be one or more other 
matches.
It is a quality of implementation issue, not an issue that needs to be 
covered in the FN specification, to select a match that results in the 
smallest number of bits (for this and, likely, for the following 
packets).

The decompressor, on the other hand, is better not requested to solve a 
riddle.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2004 12:33:49 +0200

On Oct 07 2004, at 12:23 Uhr, Finking, Robert wrote:

> Also, do I need to make some provisions for fields that only appear in
> Ag, I don't have enough knowledge of the protocols do know what DF and 
> MF are, so I'm not quite sure what you're asking. Could you explain 
> what it is you want in simple terms - preferably slowly, maybe using 
> examples that only involve sandwiches ;-)

A field like MF that always has a specific value in the packets we want 
to compress is expressed by

	mf ::= uncompressed_value(1, 0);

DF is more interesting -- an IPv6 packet feels like an IPv4 packet for 
which DF has been set.
One way to reflect this in the FN is to have a field that is seen 
neither on the compressed nor on the uncompressed side:

uncompressed_format ::= a, b, c;

compressed_format_1 ::= a, b, c {
	a ::= ...;
	b ::= ...;
	c ::= ...;
	df ::= uncompressed_value(1, 1);
}

This is, of course, only useful if some other part of the spec is 
looking for a DF field.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2004 12:35:10 +0200

>     timestamp            ::= tcp_timestamp_list_item();

Can't parse this.

Gruesse, Carsten

---

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 07 Oct 2004 12:43:08 +0200

Hi Raffles and thanks for the explanations.
Comments inlined.

> Yes, that's totally fine - it is intended to be used in just that fashion. The only restriction on doing that is that both the compressor and the decompressor must be able to disambiguate the two o…

Wow. I actually managed som FN!
Now, how to make this work on the decompressor side; then I will have to 
open up a can of worms that I just managed to close (the chain stuff). 
To say if the innermost is v4 or v6, the decompressor must inspect the 
static chain previouly received (the version field of this one), so I 
guess I'd in that case have to provide a version argument to this 
structure, but where to I get that one from? I need to think more about 
this obviously. Good ideas appreciated as usual.

> ]Issue 2:

Ok, that's a good idea. I'll try that.

> Ag, I don't have enough knowledge of the protocols do know what DF and MF are, so I'm not quite sure what you're asking. Could you explain what it is you want in simple terms - preferably slowly, m…

So for example, the DF bit is "Don't fragment" in IPv4 and no equivalent 
exists in the IPv6 header, so the IPv6 would ALWAYS set this field to 
zero in the compressed packet, while nothing ends up in the uncompressed 
header. For IPv4, the fields can take on different values in the 
compressed and uncompressed headers.
Should I set some control field for those in the v6 part so that they 
always exist? (if sandwiches are needed in the example, the DF bit would 
be like you have to swallow the sandwich whole and not chew it)

> ]List encoding. 
<snip>

This will require a bit more thinking, so I'll get back on that later.

BR,
	Kristofer