Subject: [rohc] Updating the Formal Notation draft

From: "Price, Richard" <[email-masked]>
Date: Wed, 26 Feb 2003 17:33:17 -0000

Hi,

Now that our TCP compression code is available, I'd like to
think about updating the Formal Notation draft.

As usual I've left this till the last minute, so there's no
time left to discuss any major technical changes - fortunately
I don't think that any are required at this stage.  Based on
our implementation experience, the only technical changes I'd
like to propose are the following:

1. We should add "Self-describing variable-length values" from
   Section 4.5.6 of RFC 3095 to the library of encoding methods.

2. A function for calculating an n-bit CRC should be added to
   the maths library.

Obviously, both of the above would be nice to have when
generating the final TCP profile.

I'd also like to propose some terminology changes to make the
notation draft more readable, and to hopefully fix the
inconsistencies between the notation draft and other TCP-related
drafts.  A list of these terminology changes is available from
http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt

Comments on the above proposed changes would be much appreciated!

Regards,

Richard

-----Original Message-----
From: Price, Richard 
Sent: Wednesday, February 26, 2003 2:35 PM
To: [email-masked]'
Subject: [rohc] TCP compression profile

Hi,

In the interests of kick-starting the discussion on TCP
compression, we'd like to make our current implementation of a
TCP profile available to the WG.

We've based the implementation on the latest published TCP
compression drafts, filling in the gaps where necessary to get a
working solution.  The main piece currently missing from the drafts
is a description of how to encode each field in the TCP/IP header,
so we've added a very simple proposal for this based on the current
behaviour draft.

We're hoping that the profile will evolve based on further input
from the WG, so any comments would be gratefully received ;-)

You can download the complete implementation from:

http://sigcomp.srmr.co.uk/~rjp/RohcFn_Tcp.zip

The zip file contains the following 5 modules, described below:

http://sigcomp.srmr.co.uk/~rjp/RohcFn_TcpEncoding.hs
http://sigcomp.srmr.co.uk/~rjp/RohcFn_StandardLibrary.hs
http://sigcomp.srmr.co.uk/~rjp/RohcFn_Primitives.hs
http://sigcomp.srmr.co.uk/~rjp/RohcFn_Harness.hs
http://sigcomp.srmr.co.uk/~rjp/RohcFn_Tests.hs

TCP encoding:  Defines how to compress each field in a TCP/IP
header, using encoding methods from the standard library (see
below).  The choice of encoding methods is based on the behaviour
draft <draft-ietf-rohc-tcp-field-behavior-01.txt>, but greatly
simplified - we'd appreciate suggestions on how to make the profile
more efficient, robust and future-proof.

Standard library:  The library of encoding methods from Chapter 7
of <draft-ietf-rohc-formal-notation-00.txt>.

Primitives:  The basic maths functions and encoding methods from
Chapter 6 of <draft-ietf-rohc-formal-notation-00.txt>.

Test harness:  A simple front-end that can compress and decompress
headers.  It includes a really simple state machine based on
<draft-ietf-rohc-tcp-03.txt> - all it does at present is store the
context between successive headers in a flow.  More complex state
management stuff (feedback, context replication) is on the to-do
list.

Tests:  Some example TCP/IP flows, and a generic test suite to
make sure that the implementation is working correctly.

There's also some documentation, namely:

http://sigcomp.srmr.co.uk/~rjp/RohcFn_Instructions.txt
http://sigcomp.srmr.co.uk/~rjp/RohcFn_To_Do_List.txt
http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt

Let us know if you have any problems running the code, or any
suggestions for improvements etc.

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: Thu, 27 Feb 2003 17:24:24 -0000

Hi,

I have a couple of editorial proposals for making the notation
draft a bit simpler and more readable.  Comments welcome!

Section 3.1 talks about ordinary BNF, which is irrelevant to
the definition of the formal notation.  For clarity I propose
to delete this section from the draft.

Section 4.6 on "control fields" is redundant given the
information contained in <draft-ietf-rohc-tcp-03.txt>.  Since
Ghyslain explains how control fields work much better than I
do, I propose to leave the ROHC-TCP draft as it is and delete
Section 4.6 from the formal notation.

Conversely, one issue that the current draft doesn't explain
very well is the scope of the formal notation - what it does,
what it doesn't do, how it relates to the ROHC framework and
to ROHC profiles etc.  I'd like to add a new section to
clarify this issue:

3.X. Scope of ROHC-FN

   The following section describes the scope of ROHC-FN, and
   explains how it relates to the overall ROHC framework and to
   specific ROHC profiles.

   The ROHC framework is common to all profiles, and provides
   generic features such as padding and segmentation of the
   compressed packets (useful if the link layer can only handle
   a limited range of packet sizes).

   A ROHC profile is a description of how to compress a certain
   protocol stack over a certain type of link.  For example, ROHC
   profiles are available for RTP/UDP/IP and many other protocol
   stacks.

   Each ROHC profile can be further subdivided into the following
   two components:

   a)  Packet formats for compressing and decompressing headers
   b)  State machine

   The job of the packet formats is to define how to compress and
   decompress headers.  The packet formats must define the
   compressed version of each uncompressed header (and vice versa).

   The packet formats will typically compress headers relative to
   a "context" of field values from previous headers in a flow.
   This improves the overall compression ratio, due to taking into
   account redundancies between successive headers.

   The job of the state machine is to ensure that the profile is
   robust against bit errors and dropped packets.  The state
   machine manages the context, providing feedback and other
   mechanisms to ensure that the compressor and decompressor
   contexts are kept in sync.

   ROHC-FN is designed to help provide the packet formats for use
   in new ROHC profiles.  It offers a library of encoding methods
   for compressing fields, and a mechanism for combining these
   encoding methods to create new packet formats tailored to a
   specific protocol stack.  Note however that the state machine
   for the new profiles is beyond the scope of ROHC-FN, and must
   be provided separately.

Comments on the above text would be much appreciated!

Regards,

Richard

-----Original Message-----
From: Price, Richard 
Sent: Wednesday, February 26, 2003 5:33 PM
To: [email-masked]'
Cc: 'Lars-Erik Jonsson (EAB)'
Subject: [rohc] Updating the Formal Notation draft

Hi,

Regards,

Richard

-----Original Message-----
From: Price, Richard 
Sent: Wednesday, February 26, 2003 2:35 PM
To: [email-masked]'
Subject: [rohc] TCP compression profile

Hi,

Regards,

Richard