Subject: [rohc] ROHC-FN and TCP Profile - Version 3

From: "Price, Richard" <[email-masked]>
Date: Thu, 1 May 2003 17:59:41 +0100

Hi Yousuf and others,

We've updated our implementation to print out a list of the
TCP/IP packet formats. A copy is available at:

http://sigcomp.srmr.co.uk/~rjp/ROHC-FN_Version_3.zip

Just type "build(n)." where n = 0, 1 or 2 depending on how much
information you'd like to be displayed:

n = 0: Prints the 'core' packet formats only, excluding any fields
       compressed using list encoding (such as the TCP options).
n = 1: Prints the packet formats in full, including any fields
       compressed using list encoding.
n = 2: Prints all packet formats. If a variable-length compressed
       field is encountered, the formula for calculating its length
       is also displayed.

The results are saved in the file "output.txt" for later reference.

As an example, Packet Format 0 (the simplest one) is as follows:

Packet Format 0:

   discriminator:        00
   header_crc:           3 bits
   master_seq_number:    2 bits
   tcp_psh_flag:         1 bit
   tcp_checksum:         16 bits

Let me know if you have any suggestions for improvements!

Regards,

Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2003 9:43 PM
> To: Price, Richard; [email-masked]
> Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2
> 
> 
> Hi Richard,
> I think it would be useful to have the pictorial format generation. 
> 
> Thanks,
> Yousuf
> 
> -----Original Message-----
> From: ext Price, Richard [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2003 9:51 AM
> To: Saifullah Yousuf (NRC/Dallas); [email-masked]
> Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2
> 
> 
> Hi Yousuf,
> 
> Drawing the Version 2 packet formats out pictorially might
> be a bit of a challenge, as they're a *lot* more complex
> than the Version 1 formats. They're now roughly as
> complicated as the packet formats in RFC 3095, so the
> pictorial form plus accompanying text will be around 100
> pages long  - a non-trivial amount of effort to generate
> by hand ;-)
> 
> A possible solution would be to modify our implementation
> so that it can automatically convert a ROHC-FN description
> of the packet formats into a pictorial one. If you think
> this feature would be useful, let me know so that we can
> add it to the next version of the implementation.
> 
> Regards,
> 
> Richard
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, April 25, 2003 6:07 PM
> > To: Price, Richard; [email-masked]
> > Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2
> > 
> > 
> > Hi Richard,
> > Could you please share the version 2 for the TCP compression 
> > profile in the pictorial form with textual description 
> > (basically, in the I-D format). Something similar you did for 
> > the previous version.
> > 
> > Thanks,
> > Yousuf
> > 
> > -----Original Message-----
> > From: ext Price, Richard [mailto:[email-masked]]
> > Sent: Wednesday, April 23, 2003 6:49 AM
> > To: [email-masked]'
> > Subject: [rohc] ROHC-FN and TCP Profile - Version 2
> > 
> > 
> > Hi,
> > 
> > Now that Easter's out of the way, it might be a good
> > time to restart the discussion on ROHC-FN and the TCP
> > compression profile. In the interests of getting the
> > discussion going, here's a link to Version 2 of our
> > implementation:
> > 
> > http://sigcomp.srmr.co.uk/~rjp/ROHC-FN_Version_2.zip
> > 
> > For the updated implementation we've added all of the
> > encoding methods not supported in Version 1, including
> > Huffman-based discriminator encoding (i.e. EPIC-lite)
> > as well as "list" encoding for the TCP options and
> > the IP extension headers. We've also added support for
> > real IR packets with the correct indicator bits.
> > 
> > The TCP packet formats have been updated to take
> > advantage of the new encoding methods - we can now
> > compress various TCP options using list encoding, and
> > have a single discriminator for the header as a whole.
> > Minimum compressed header size is now 3 bytes.
> > 
> > One other issue - the updated implementation is
> > written in a different language from the original
> > (namely Prolog rather than Haskell). We're still
> > working on the Haskell code, but we're turning it into
> > a "proper" implementation (with full debugging and a
> > nice user interface).
> > 
> > A suitable Prolog interpreter can be downloaded from:
> > 
> > http://www.swi-prolog.org/download.html
> > 
> > For simplicity, the implementation is provided as a
> > single Prolog source file. Just open it and type
> > "comp_list(tcp_test_n)." where n is the TCP test flow
> > to be compressed.
> > 
> > Regards,
> > 
> > Richard
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> > 
> 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 9 May 2003 11:18:25 +0100

Hi William,
 
The FIELD(n) encoding method takes the next n bits from the
uncompressed header and stores them in a temporary variable
called Field_Value.  The NEXT_FIELD encoding method works
in a similar manner, but rather than taking the bits from the
uncompressed header, it takes them from a labelled field instead.
 
As you spotted in the TCP/IP profile, it's possible to encounter
an instance of NEXT_FIELD immediately followed by an instance
of FIELD(n).  In this case the NEXT_FIELD encoding method is
considered to "win" - i.e. the Field_Value is taken from the
labelled field rather than from the uncompressed header.  We
can see that this is the case from the following pseudocode, taken
from the definition of FIELD(n):
 
   If Field_Value == Null then set Field_Value:= F and set  
   Remaining_Data := Remaining_Data - n.

So, the FIELD(n) encoding method must first check whether
the Field_Value temporary variable already contains a field value
or not.  If it doesn't then the next n bits are extracted from the
uncompressed header as expected.  However, if the NEXT_FIELD
encoding method has been used previously, then Field_Value
will already be set and the FIELD(n) encoding method will be
ignored.
 
This behaviour is a little clumsy, so why do we need it?  The
benefit is that we can compress labelled fields using ordinary
encoding methods such as STATIC and IRREGULAR, e.g:
 
                            next_field(order)++
                            static // irregular(24)++
                            next_field(presence)++
                            static // irregular(8).
 
As you pointed out, the STATIC and IRREGULAR encoding
methods both call an instance of FIELD(n) to extract some
bits from the uncompressed header.  Using the NEXT_FIELD
encoding method we can "override" this default behaviour and
force them to compress a labelled field instead.
 
If you can think of a neater way of doing this then please let
me know ;-)
 
Regards,
 
Richard

-----Original Message-----
From: william zheng [mailto:[email-masked]]
Sent: Friday, May 09, 2003 3:40 AM
To: Price, Richard
Subject: Re: [rohc] ROHC-FN and TCP Profile - Version 3

Hi, Richard,

I am confused on the definition of FIELD and NEXT_FIELD.

According to ROHC-FN draft, FIELD encoding method extracts an n-bit field from the uncompressed packet and stores it in a temporary variable. It means this encoding method operates on the header rather than any label or temporary varialbe. NEXT_FIELD instead operates on labeled field. See the example where NEXT_FIELD is used as follows. 

tcp_options           -->   list(data_offset,1,32,-160,
                             [optional(tcp_sack),
                              optional(tcp_timestamp),
                              optional(tcp_end),
                              optional(tcp_no_operation),
                              optional(tcp_no_operation),
                              optional(tcp_generic),
                              optional(tcp_generic),
                              optional(tcp_generic)])++
                            next_field(order)++
                            static // irregular(24)++
                            next_field(presence)++
                            static // irregular(8).

The encoding method that follows the next_field is either STATIC or IRREGULAR, both further using FIELD encoding method via RANGE. It seems quite difficult to understand we can use FIELD encoding method when a labeled field is expected to be encoded/decoded. Consider that following next_field(order)++ we expect to add the labeled field 'order' to the compressed header, but when we use static or irregular(24), we point to the uncompressed header and try to shift the 'remaining_data'. But this is not the action we want to take, is it right?

Thanks.

RGDS,

William 

  _____  

The new MSN 8: <http://g.msn.com/8HMCEN/2737??PS=>  smart spam protection and 2 months FREE*