Re: [rohc] TCP compression profile (described using ROHC-FN)

["Richard Price" <ellyptic@hotmail.com>]

> The updated notation draft has indeed taken a step backwards in
> scope and optimization, but it has also taken a few steps forward
> in clarity.

Hi,

There seems to be some confusion between the notation draft itself,
and the implementation that we just published!

The updated notation draft contains no technical changes from the old
draft, so its scope and optimization remain exactly the same.  However,
the implementation that we made available to the WG only includes a
subset of the features documented in the notation draft - enough to
demonstrate the notation in action, but not enough for an "optimally"
efficient set of compressed TCP packet formats.

> My interpretation of the TCP example from Richard is thus that it
> is just a simple example to show how the notation can be applied.
> We will of course have to continue with both the notation work
> and the TCP profile specifics, as the TCP profile document does
> not even have any packet formats defined yet. The WG has not
> come that far yet.

Exactly.  The example TCP packet formats only use encoding methods
supported by our published implementation, so there's plenty of room
for improvement.

> > 1. This scheme is quite in-efficient. Since each field needs a bit to
> > indicate whether it exists or not, the smallest packet size is 5 bytes
> > (just to represent a header without sequence number or acknowledgement
> > number change). Moreover, we need another byte for the packet type.

We can generate more efficient indicator bits by taking into account the
probability that each field encoding will be used.  This feature is
available
in the current notation draft (Section 6.4.3), but we haven't used it in the
TCP packet formats just yet because it's not supported in the
implementation.

> > 2. The presentation ability is quite weak. For example, it is hard to
> > encode the TCP option part. Moreover, for ROHC-RTP case, how to encode
> > list type of things?

Both of the above can be compressed using the "list" encoding method
(Section 6.5.1 of the notation draft).  We'll use this to compress the TCP
options as soon as we've added it to the published implementation.

Regards,

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