[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] Role and approach of the ROHC formal notation
> 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.
Hi,
If EPIC and EPIC-lite are useful to get an understanding of a
complete notation-based solution, then it's good that Carsten
mentioned them ;-)
However, one point I'd like to clarify is that algorithms like EPIC
and EPIC-lite are for -generating- packet formats, whereas the
notation is for -describing- packet formats. Another way of
generating packet formats is of course to design them by hand! But
even if we choose to do this, the notation can still be used to capture
the exact hand-crafted packet formats that we want to use.
I've had a go at explaining this distinction in a bit more detail
using some examples (see below).
> > 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".
Is it always the case that an encoding method compresses exactly one
field? What about list encoding from RFC 3095?
> > 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.
Absolutely - all the original example tries to do is to demonstrate how the
notation gives "bits on the wire".
> 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.
Ok, let's try something more complicated ;-)
Using the same three encoding methods, we can put in a little more effort
and create the following encoding for the TCP ports:
mini_tcp_header ::= format_1 / (format_2 / (format_3 / format_4))
format_1 ::= static ; TCP Source Port
static ; TCP Destination Port
format_2 ::= irregular (16)
static
format_3 ::= static
irregular (16)
format_4 ::= irregular (16)
irregular (16)
This corresponds to the following packet formats:
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| or |1|0| TCP Source Port | or
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0| TCP Destination Port | or
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|1| TCP Source Port | TCP Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These packet formats are more efficient than the ones I gave previously,
because a single 1-bit discriminator can be used to indicate that both
the Source and Destination ports are static.
The point I'm trying to make with all of this is that the notation is
just a way of describing how to compress and decompress headers. If
you use the encoding methods from RFC 3095 then you can create packet
formats just like the ones in 3095, and capture your design decisions
via the formal notation.
Using the notation without EPIC or EPIC-lite can still be quite useful -
the packet formats are "formally" defined, meaning that the notation can
be compiled into executable code. This saves a lot of implementation
effort!
However, on its own the notation won't reduce the amount of effort
needed to devise efficient new packet formats - for this we need EPIC
or EPIC-lite...
> 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.
This is where EPIC and EPIC-lite come in. They both offer more efficient
ways of adding discriminators to the compressed header, without having
to go to the trouble of designing the packet formats by hand.
Let's try the above example using EPIC-lite. We can replace the old
"self-describing values" discriminator (denoted by "/") with a new
discriminator generated by EPIC-lite (which we'll denote using the
symbol "|").
The description of the TCP ports in the formal notation then becomes:
mini_tcp_header ::= tcp_source_port
tcp_destination_port
tcp_source_port ::= static 90% | irregular (16) 10%
tcp_destination_port ::= static 90% | irregular (16) 10%
Note that EPIC-lite needs an additional parameter whenever we offer a
choice of encoding methods - namely the probability that each encoding
method will be used. EPIC-lite uses this extra information to work out
the best discriminator for each packet format.
In the above example (ignoring byte-alignment and reserving the ROHC
framework indicator bits), EPIC-lite calculates the overall probability
that each packet format will be needed, and assigns shorter discriminators
to the more common formats:
Format: Source Port: Destination Port: Probability: Discriminator:
1 static static 81% "0"
2 irregular static 9% "10"
3 static irregular 9% "110"
4 irregular irregular 1% "111"
EPIC-lite then sticks the correct discriminator onto the front of each
packet format. So, we get exactly the same set of packet formats as the
ones we designed by hand above, but generated automatically by the
EPIC-lite algorithm:
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| or |1|0| TCP Source Port | or
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0| TCP Destination Port | or
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|1| TCP Source Port | TCP Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 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.
Fields that are compressed together are easy to handle using the
appropriate encoding method. For example, suppose that we want to
compress the IP-ID as an offset from the Master Sequence Number. We can
write this in the notation as follows:
ip_id ::= inferred_offset (16, MSN)
lsb (4, 0) / lsb (8, 0) / irregular (16)
The first line subtracts the Master Sequence Number from the IP-ID. The
second line compresses the resulting offset by sending a choice of 4 LSBs,
8 LSBs or the 16-bit field in full.
Context interactions are also easy to describe using the notation. By
default every encoding method automatically updates the context - if
we don't want this to be the case for whatever reason then we can write
the following:
tcp_source_port ::= no_update (static / irregular (16))
This allows us, e.g. to prevent the context from being updated if the
packet format doesn't include enough bits of CRC.
Regards,
Richard
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc