RE: [rohc] TCP compression profile

["Price, Richard" <richard.price@roke.co.uk>]

> > 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

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

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.

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

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

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

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

Regards,

Richard
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc