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

["Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>]

Richard,

Comments inline...

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

I think referring to EPIC and EPIC-Lite was rather useful here,
because the core of those was actually the glue that, at least
to me, seems to be missing from the current notation->compression
discussion. Last year, we agreed that it is one thing to define 
how to encode each field, and putting all fields together in
compressed headers is another this. The notation obviously covers
the former. The latter includes e.g. how to create the
"discriminator", as Carsten called it. I agree with you that we
do not have to discuss the actual EPIC and EPIC-Lite algorithms
for doing this, but referring to them as Carsten did was still
useful for getting an understanding of the various pieces.
 

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

I do not agree with that. An encoding method, in 3095 terminology,
is a way to compress a field, while the core of EPIC and EPIC-Lite
were the algorithms for combining all fields together into 
"distinguishable bits on the wire".

<scroll down>

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

This is a very generic approach, but you do not get very efficient formats.
With these formats, you have one extra bit for each field, and if you want
to have variable length fields, you get even more control bits. The format
"discriminator" gets large. If we want to define automatic means to create
the compressed formats, we need to have means to affect this and reduce
the number of possible combinations to make the discriminator overhead 
smaller.

Anyway, this was still a very good example, but things get much more
complicated when we start addressing fields that are compressed together,
and when we add context interaction. Static fields are just present in
IR/IR-DYN headers, and those are easily defined without automatic means.

BR
/L-E
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc