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

From: "Finking, Robert" <[email-masked]>
Date: Fri, 8 Oct 2004 17:01:37 +0100

]Ok, now I have a bit better understanding of how to use the list encoding in the 
]FN, but it seems to be a bit out of synch with what we've said in tcp-07.

Yes, that's because it was written before you and I sorted the list encoding stuff out a month or so back ;-)

]
]    In the definition of the packet formats for ROHC-TCP, the most
]    frequent type of TCP options are described. Each of these options has
]    an uncompressed format, a list_item format and an irregular format.
]

OK, to marry them up, Mark has the following for time stamps:

tcp_opt_tsopt === {

        uncompressed_format = type,   %[ 8 ]
                                length, %[ 8 ]
                                tsval,  %[ 32 ]
                                tsecho; %[ 32 ]

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

        format_tsopt_list_item = tsval,   %[ 32 ]
                                 tsecho,  %[ 32 ]
        {
                tsval ::= irregular (32);
                tsopt ::= irregular (32);
        };

        format_tsopt_irregular = tsval,  % 16, 24 or 32 bits
                                   tsecho, % 16, 24 or 32 bits
        {
                tsval  ::= ts_lsb;
                tsecho ::= ts_lsb;
        };
};

I had this: 

  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);
    };
  };

Apart from formatting and naming issues (e.g. Mark has "tsecho", I have "timestamp_echo_reply"), there are two main differences, I have the "let (this:has_context == ..." lines, which Mark doesn't (we need this for the encoding to know which format to use when), and instead of a single lsb encoding, Mark has used a more efficient encoding method, ts_lsb, which still uses lsb fundamentally, but has a couple of different choices depending on how fast it's changing. Actually, I think what may be adding to the confusion here is, I *think* Mark has mixed up his naming of the two encodings, and has called the wrong one "irregular", but basically, his "format_tsopt_list_item" encoding (i.e. the one that encodes the timestamps using irregular encoding) maps onto my "compressed_format_first".

I have to go now, but hopefully that will give a clue as to how the rest should be translated. I may be able to help with this next week, then again I may get sucked into a hole...

All the best

Raffles

PS Oh yes, and you're right, the spare bit combination for IP ID is fine to use for "reverse byte order sequential" - the reason the comment says not to use it is because it wasn't currently defined, but reverse byte order is an ideal use - go for it =) Have a nice weekend!

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Sun, 10 Oct 2004 15:54:34 +0200

> Apart from formatting and naming issues (e.g. Mark has "tsecho", I have 
 > "timestamp_echo_reply"), there are two main differences, I have the
 > "let (this:has_context == ..." lines, which Mark doesn't (we need this
 > for the encoding to know which format to use when), and instead of a
 > single lsb encoding, Mark has used a more efficient encoding method,
 > ts_lsb, which still uses lsb fundamentally, but has a couple of
 > different choices depending on how fast it's changing. Actually, I
 > think what may be adding to the confusion here is, I *think* Mark
 > has mixed up his naming of the two encodings, and has called the wrong
 > one "irregular", but basically, his "format_tsopt_list_item" encoding
 > (i.e. the one that encodes the timestamps using irregular encoding)
 > maps onto my "compressed_format_first".

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

/Kristofer Sandlund, Effnet AB