Subject: [rohc] TCP compression profile

From: "Price, Richard" <[email-masked]>
Date: Wed, 26 Feb 2003 14:34:41 -0000

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

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 27 Feb 2003 11:13:08 +0100

Richard,

I hope this input will be useful for the further TCP profile work,
i.e. for defining the compressed header formats, but it is a rather
substantial material to read and understand (especially considering
previous problems of getting people involved in these notation
discussions) so we will have to give this some time.

Anyway, I have to provide some comments and guidelines on procedural
matters, considering this input. This is an IETF WG, and input is
expected to be provided either:
1) in internet-drafts, or
2) in messages to the WG mail list 

Some material, like implementations, might of course be difficult
to provide through those channels, and then exceptions may have to
be made. However, such exceptions should only be made when really
necessary, both because we have common IETF principles to simplify
for all involved parties and be consistent, and because of archival
reasons. Except for implementations, material for the WG to consider
must be posted through our official channels (drafts or mail list).

/L-E

--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: [email-masked]
Phone: +46 920 20 21 07
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 27 Feb 2003 11:15:35 +0100

> 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 behavior draft.

How to encode the original fields are rather well "suggested" in the
behavior draft, but what we are still missing in the profile draft
is (1) a description and summary of what "control information" is
needed (e.g. context replication), (2) a summary of how we then have
decided to compress each piece of information (original fields+control),
and (3, most concrete) defining the actual compressed header formats,
i.e. the bits on the wire. 1) is partially already done in the draft,
but some pieces are still missing. The notation was intended to either
be used as a descriptive language to do 2) in the draft, or be used as
a tool to by-pass 2) and together with some encoding method produce 3)
directly for inclusion in the draft. It is not clear to me at this
point whether people are considering the former or the latter approach.
If we do put 2) in the profile draft, we have taken one step and may
then decide how to go further to define the actual compressed formats.
On the other hand, if we decide to go directly to 3), we need to agree
on how to use the notation as a tool to generate compressed header
formats, and we must find a good way of documenting these in the
profile specification. A third approach is of course not to use the
notation at all, but just define the compressed formats as we did in
RFC 3095.

Assuming that we do not take this third approach, the first step would
in any case be to agree on the notation. Any opinions on if the
notation would be about the same independent of how it will be used.

BR
/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 27 Feb 2003 12:49:09 -0000

Hi,

So, just to check, is there any part of our implementation that
would be useful to document separately (either in internet-drafts
or on the mailing list)?

The implementation has two new encoding methods not currently
described in the notation draft (see my previous post on updating
the formal notation).  I believe it would be good to add these to
the next version of the draft - if no-one objects, I can make this
update before the deadline next week.

The other new material that we've provided is a set of test
vectors for the implementation (including some TCP flows, as
well as some generic tests to make sure that the implementation
is working correctly).  Might it be worth putting these in a
draft at some stage, like we did for the SigComp torture tests?

Regards,

Richard

> -----Original Message-----
> From: Lars-Erik Jonsson (EAB) 
> [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 10:13 AM
> To: Price, Richard; [email-masked]'
> Subject: RE: [rohc] TCP compression profile
> 
> 
> Richard,
>

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 27 Feb 2003 15:55:11 -0000

> behavior draft

This certainly seems to be the case based on our initial test TCP flows.
One interesting open issue, however, is the level of complexity needed
in the final TCP encoding.  Our current implementation only uses a very
basic set of packet formats, designed specifically to be human-readable.
We could improve the efficiency, robustness and future-proofing by
following the behaviour draft more exactly, at a cost of making the
resulting packet formats harder to understand.

> but what we are still missing in the profile draft

If we choose the former approach then the notation defines which
encoding methods are applied to which fields (including the "control"
fields not present in the original TCP/IP header).  To get from this to
"bits on the wire", we just need to define a library of 4 or 5 basic
encoding methods for the notation to use.

> notation at all, but just define the compressed formats as we did in

The above is a good summary of the two ways the formal notation could be
used to provide the "bits on the wire" for the TCP profile.  In both cases
we need to somehow define a basic library of encoding methods - in
RFC 3095 this is just done by hand, and in the current notation draft we
do exactly the same.

The difference between the two approaches is therefore quite simple: we
need to define "packet formats" that apply one or more encoding methods
to each field, and we can do this either using the formal notation, or
in the "RFC 3095 style" using a combination of diagrams and accompanying
text.

Which of the above approaches to use is a matter of opinion (we could
even provide the packet formats using both, although I'm not keen on
this as we then have the additional worry of synchronising the two
approaches and making sure that they define the same bits on the wire).

My own preference is that the packet formats should be defined using the
formal notation (not that I'm biased of course!).  The main advantage of
this is that, as Carsten pointed out in Atlanta, several programming
languages have a compiler for the formal notation already built-in.  So
all of the packet formats can be implemented for free, just by pasting
the description of TCP/IP into the compiler.  As a bonus, this will help
to eliminate misunderstandings about how the packet formats behave (e.g.
which fields update the context, which offsets to use for LSB encoding
etc.)

> notation would be about the same independent of how it will be used.

I don't believe that the notation will need to change depending on which
of the above approaches is used.

Regards,

Richard