RE: [rohc] Role and approach of the ROHC formal notation

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

> >     1) In Richards last e-mails, he seems to say that the notation
> >        itself gives the compressed formats (bits on the wire), and
> >        I do not buy that. How could that be possible?
> > 
> > I believe Richard's/Mark's idea is that the notation defines all the
> > bits in the compressed packet (its "body"), apart from an initial
> > discriminator.  This discriminator is what differs between EPIC and
> > EPIC-lite.  The discriminator carries all the information that is
> > needed to parse the body.  The body carries information that is too
> > big to carry in the discriminator; essentially orthogonally encodable
> > information.  The discriminator can use interesting tricks like EPIC
> > (Huffman on complete discriminators) or, if we want, arithmetic coding
> > (I don't know when those patents run out, though).  The notation
> > supplies everything that is needed to go into the discriminator
> > computation (values, probabilities).

Hi,

It might be simpler to avoid mentioning EPIC and EPIC-lite at this stage,
because the notation can generate a decent set of compressed packet
formats without needing to use either.

In RFC 3095 terminology, both EPIC and EPIC-lite are just encoding
methods, which we may or may not want to use when compressing fields in
a header.  For simplicity let's avoid them for now, and just stick with
the encoding methods that are available in RFC 3095.

In particular, let's try creating a set of compressed packet formats
using the following three encoding methods from RFC 3095:

Static - Encodes a field that takes the same value as in the previous
header.  No "bits on the wire" need to be sent in this case.

Irregular n - Encodes an n-bit field with no discernable pattern (by
sending all n bits in the compressed header).

Self-describing values - Allows a field to be encoded in two different
ways, and sends a 1-bit flag to indicate which way has been chosen.  In
the notation, we denote this encoding method using the symbol "/".

Using these three encoding methods, we can apply ROHC-FN to create a
more complex encoding method designed (say) to handle the TCP Source
Port:

tcp_source_port   ::=   static / irregular (16)

This new encoding method can encode the field either using a single
"0" (if it happens to be the same as in the previous header), or by
sending a "1" followed by the 16-bit Source Port in full.

The new encoding method certainly defines "bits on the wire" - we can
write these out using packet formats as follows:

+-+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|   or   |1|        TCP Source Port        |
+-+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The next field in the TCP header can be encoded in the same way:

tcp_destination_port   ::=   static / irregular (16)

Finally, let's join the two fields together to get a set of packet
formats capable of handling both fields:

mini_tcp_header   ::=   tcp_source_port
                        tcp_destination_port

The corresponding packet formats for these two fields are as follows:

+-+-+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|   or   |1|        TCP Source Port        |0|   or
+-+-+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|     TCP Destination Port      |   or
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        TCP Source Port        |1|     TCP Destination Port      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hopefully it should be clear that we can define how to compress all
of the other fields in a TCP/IP header in a similar manner - then we
just join them up to get our complete "compressed packet formats".

Comments welcome!

Regards,

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