Subject: FW: [rohc] Updating the Formal Notation draft

From: "Price, Richard" <[email-masked]>
Date: Mon, 3 Mar 2003 10:50:06 -0000

> I'd also like to propose some terminology changes to make the
> notation draft more readable, and to hopefully fix the
> inconsistencies between the notation draft and other TCP-related
> drafts.  A list of these terminology changes is available from
> http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt

Hi,

For completeness, here is the list of proposed terminology changes
in non-linked form.

Terminology changes:

1. We should give the notation a better name, e.g. ROHC-FN
   (Formal Notation for Robust Header Compression).

2. The "rules" should be called "encoding methods" to bring the 
   terminology in line with RFC 3095.

3. The "labels" should be renamed "temporary variables" to
   make it clearer what they actually do!

4. The names of encoding methods and variables should be
   cleanly separated, e.g. by using lowercase for the names
   of encoding methods and uppercase for variable names.

Regards,

Richard
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 3 Mar 2003 12:54:46 +0100

>    (Formal Notation for Robust Header Compression).

Yes!

>    terminology in line with RFC 3095.

OK!

>    make it clearer what they actually do!

I am not sure, to me "variables" does not make much sense in
a formal notation. I have to think more about this...

>    of encoding methods and uppercase for variable names.

I would leave that for now.

/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 3 Mar 2003 12:55:02 -0000

Hi,

Thanks for your comments!  I've added a couple of replies inline.

Regards,

Richard

> -----Original Message-----
> From: Lars-Erik Jonsson (EAB) 
> [mailto:[email-masked]]
> Sent: Monday, March 03, 2003 11:55 AM
> To: [email-masked]'
> Subject: RE: [rohc] Updating the Formal Notation draft
> 
> 

For this reason, I suspect that using the name "variables" would
be an excellent idea!  From a technical perspective we definitely
have this functionality in the notation - whether it's a good
idea or not is open for debate, but we should at least clarify
that the functionality is there so that folks can argue for or
against it.

The term "labels" is misleading, because it implies that they
take the same constant value for each header.  In fact, the value
of a label can change as the header is being parsed - hence the
term "variable" is more appropriate.

> I would leave that for now.

Ok, I'll stick with what we've got at the moment (lowercase for
encoding methods, mixture of uppercase and lowercase for variables).
This is fine for now.

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 3 Mar 2003 13:27:53 -0000

Hi Carsten,

Many thanks for these comments.  I've added some further comments
on the proposed changes that I'd like to make in the next version
of the notation draft.  The remaining issues just relate to the
syntax of the notation - we can finalise these later on (e.g. after
we've chosen between Haskell/Prolog etc.).

Regards,

Richard

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 7:51 PM
> To: [email-masked]
> Subject: [rohc] Updating the Formal Notation draft
> 
> 
> ROHCers,
> 
> some comments (WG chair hat off) on
> http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt below.
> 
> Gruesse, Carsten
> 
>     Based on our implementation experience we'd like to propose a
>     few changes to the current formal notation draft (see
>     <draft-ietf-rohc-formal-notation-00.txt>):
> 
>     Terminology changes:
> 
>     The following changes have no technical effect on the notation,
>     but will hopefully make the draft easier to understand:
> 
> If, as you explain in a later message, it is just about packet
> formats, it probably should be named ROHC-FNPF or some such?

It might be better to keep the name of the notation more generic, at
least for the time being.  As Lars-Erik pointed out the final scope
of the notation may change...

> d/c (don't care).

Ok, I'll use the term "encoding methods" - should make the draft a
bit clearer.

> Hmm, this creates the impression the notation has imperative
> semantics.  I thought we were trying to avoid this.  Bindings?

The term "labels" (or "bindings") implies that each label name refers
to a fixed value for each header.  This isn't currently the case -
labels can change their value as the header is parsed, so the term
"variable" is more appropriate.

Obviously it would be nicer to avoid having variables in a notational
language - it's an open issue whether we can do this or not.

> This might conflict with the choice of Haskell (uppercase is reserved
> for specific things in that language).  (It also would conflict with
> Prolog.)

That's ok - it doesn't matter which is uppercase and which is
lowercase, so long as they are cleanly separated.  I'll stick with
what we've currently got (we can always change it later if it
conflicts with our choice of well-known language).

>     Miscellaneous changes:
> 
>     The following changes aren't required to make the notation
>     Haskell-compatible, but we think that they're a good idea anyway:
> 
>     1. We should add "Self-describing variable-length values" from
>        Section 4.5.6 of RFC 3095 to the library of encoding methods.
> 
> Sure. The Library will grow with our use of the notation.
> 
>     2. A function for calculating an n-bit CRC should be added to
>        the maths library.
> 
> Sure.

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 3 Mar 2003 14:43:18 +0100

Richard,

> language - it's an open issue whether we can do this or not.

What do you mean with "header is parsed"? We are talking about a 
"language" to describe how header fields are to be compressed (not
field data from a specific packet header), and to me "parsing" sounds
like something you do with an actual packet header.

I have to re-read the draft, but I will wait for the updated version.

/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 3 Mar 2003 15:39:46 -0000

Hi,

Yes, I meant "parsing" as in compressing actual packet headers.  The
temporary variables are used by the notation to store certain fields
from a header - I've had a go at explaining why this is useful below:

It's often the case that two fields in a header have related behaviour
(e.g. RTP Sequence Number and Timestamp).  Obviously these dependencies
need to be taken into account when encoding the fields - this means that
the encoding method for the RTP Timestamp must have the RTP Sequence
Number available before it can work out the compressed version of the
Timestamp.

ROHC-FN captures these field dependencies using "temporary variables".
In a description of RTP, the encoding method for the RTP Sequence
Number would create a new temporary variable called, say, "RTP_Seq"
for storing the RTP Sequence Number.  The encoding method for the RTP
Timestamp would retrieve the Sequence Number from the variable "RTP_Seq"
and use it when compressing the Timestamp.

When parsing a specific RTP header, the temporary variable "RTP_Seq"
would contain the specific value of the RTP Sequence Number for that
particular header.  If we want to parse two different RTP headers then
the temporary variable will generally take a different value in each
case - hence the term "variable" is appropriate.

> I have to re-read the draft, but I will wait for the updated version.

I've just submitted the updated version of the draft.  It might be
worth checking out the worked example for IPv6, which makes use of two
temporary variables called "Next_Header" and "Remaining_Data".

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 4 Mar 2003 14:35:20 -0000

Hi,

Thanks for all of these comments - hopefully I managed
to take them into account in the updated version of the
notation draft.  I've added a few clarifications inline,
particularly regarding the scope of ROHC-FN (where more
discussion is clearly required).

Regards,

Richard

> Sent: Friday, February 28, 2003 3:14 PM
> To: [email-masked]'
> In general, I think we should not make any changes to the
> actual notation at this point (although the draft might be
> updated for other reasons), as we do not have a common view
> either of how to proceed with this, or for example if we 
> should do this "Haskell"-step, or something similar using
> another functional language. We need to discuss this more,
> then we can get a stable ground for the content before we
> do the changes.

Absolutely - there's no need to update the syntax of the
notation at this stage.  It's more important to clarify the
scope of the notation draft, and to make sure that we
understand how it fits into the overall ROHC solution.

> However, we might want to update it just to change the title,
> and maybe some of the "environmental texts". I've provided
> some comments on this below.
> 
> BR
> /L-E
> 
> 
> > Section 4.6 on "control fields" is redundant given the
> > information contained in <draft-ietf-rohc-tcp-03.txt>.  
> 
> Well, it might be worth mentioning that information that
> can be noted is either original header fields, or additional
> control fields introduced by the compression scheme.

Ok, I mentioned this briefly in the updated draft.

> > I propose to leave the ROHC-TCP draft as it is and delete
> > Section 4.6 from the formal notation.
> 
> Of course, the TCP control field can not be discussed as
> part of the general notation.

Good point - Section 4.6 talks about specific control fields
such as the "Master Sequence Number", which is used exclusively
by ROHC-TCP.  So it's definitely out of scope of the formal
notation draft.

> > Conversely, one issue that the current draft doesn't explain
> > very well is the scope of the formal notation - what it does,
> > what it doesn't do, how it relates to the ROHC framework and
> > to ROHC profiles etc. 
> 
> This is indeed very important, and should be done before we
> go much further. However, I do not think we do have a common
> understanding about that, as it has never been settled.

I think that the first step is to explain the scope of the
current notation draft.  Once we've clarified this, we can
decide whether the scope is correct, or whether it's too broad,
too narrow etc.

> > I'd like to add a new section to clarify this issue:
> > 
> > 3.X. Scope of ROHC-FN
> > 
> >    The following section describes the scope of ROHC-FN, and
> >    explains how it relates to the overall ROHC framework and to
> >    specific ROHC profiles.
> > 
> >    The ROHC framework is common to all profiles, and provides
> >    generic features such as padding and segmentation of the
> >    compressed packets (useful if the link layer can only handle
> >    a limited range of packet sizes).
> 
> Well, the framework provides the base for all ROHC compression.
> It defines the profile concept, which makes ROHC a general platform
> for compression schemes. It sets link layer requirements, and 
> especially negotiation requirements for all ROHC profiles. It 
> defines a set of common functions, as segmentation, CID's, and
> padding. It also defines common packet formats (IR, IR-DYN, Feedback,
> Short-CID expander, etc), and it defines a generic, profile
> independent, handling of feedback. One can also say that it defines
> the general principles for doing ROHC compression.
> 
> >    A ROHC profile is a description of how to compress a certain
> >    protocol stack over a certain type of link.  For example, ROHC
> >    profiles are available for RTP/UDP/IP and many other protocol
> >    stacks.
> > 
> >    Each ROHC profile can be further subdivided into the following
> >    two components:
> > 
> >    a)  Packet formats for compressing and decompressing headers
> 
> I would say "compressed packet formats"

As I'm not 100% sure what exactly is meant by a "packet format"
(compressed or otherwise), it might be useful to capture in more
detail what information needs to be defined to get interoperable
ROHC profiles:

What we're really trying to define is a *function*, whose inputs are
the uncompressed header and the context, and whose outputs are the
compressed header and a (possibly updated) version of the context:

                          function
uncompressed header   <-------------->   compressed header
context                                  updated context

So, as well as specifying which fields are in the compressed header,
we also need to define how to map between the uncompressed version
and the compressed version of each field.  For example, if a
particular field is compressed using LSB encoding, then we need to
to define the interpretation interval, whether the field is
compressed as an offset from a different field etc.  We also have to
define whether each field updates the context or not.

Does the term "compressed packet formats" cover all of the above
information?  If so, then great!  If not, then a different term might
be more appropriate.

> >    b)  State machine
> 
> I am not sure "state machine" captures all the rest that is there,
> but I'll think more about this.

Again, it would be useful to capture exactly what needs to be
defined, so that we can see whether the term "state machine" is
appropriate or whether another term would be better.

I think that the following features are needed in conjunction with
the ROHC framework and the above "compressed packet formats":

1.  Deciding when to delete context entries from the sliding window
    (e.g. optimistic approach, ACKs etc.)
2.  Deciding when the context needs to be refreshed (e.g. timeouts,
    NACKs etc.)
3.  How to recover from decompression failure
4.  Context replication

I'm not sure whether context replication is within the scope of
the state machine - perhaps a more general term that captures all of
the above would be "context management" issues?

> >    ROHC-FN is designed to help provide the packet formats for use
> >    in new ROHC profiles.
> 
> It is a notation form for the information to compress, it is not clear
> to me at this point how far you really get with the notation.

A description of, say, TCP/IP in the formal notation will give you
exactly what is defined in a) above.  You get a function whose inputs
are the uncompressed header and the context, and whose outputs are the
compressed header and a (possibly updated) version of the context.

I suspect that more explanation of how exactly the notation defines
this function would be useful - I'll have a go at providing this in
a separate post.

> > Comments on the above text would be much appreciated!
> 
> This is a good start, as I think it is essential that we try to define
> what the notation is, what it will be used for, and how it fits in
> the "big ROHC picture".
>

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 5 Mar 2003 12:43:49 +0100

Richard,

I'm still not sure "Variable" is the right word for this at
the notation level, and as you say we should investigate if
we can avoid having this at all. The examples you have shown
seem to be about compressing fields together, i.e. using
another field as a reference for compressing a field. Would
"Reference" be a potential word if we have to keep this?

BR
/L-E

> From: Price, Richard [mailto:[email-masked]]
> Sent: den 3 mars 2003 16:40
> To: Lars-Erik Jonsson (EAB); [email-masked]

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 5 Mar 2003 15:16:08 +0100

Some more comments (next cycle, we should try to reduce the
number of parallel threads)...

> decide whether the scope is correct, or whether it's too broad,

Yes, and this would hopefully mean that we all could start
using the same terminology and get a common view. We are not
there yet, but these discussions are helping a lot to move
forward on that path.

> > >    The ROHC framework is common to all profiles, and
> > >    provides generic features such as padding and
> > >    segmentation of the compressed packets (useful if
> > >    the link layer can only handle a limited range of
> > >    packet sizes).

I noticed that you did not manage to get this paragraph enhanced
in the submitted draft. That is fine for now, just make sure to
do it in the next revision, using e.g. material from below...

> > Well, the framework provides the base for all ROHC
> > compression. It defines the profile concept, which makes
> > ROHC a general platform for compression schemes. It sets
> > link layer requirements, and especially negotiation
> > requirements for all ROHC profiles. It defines a set of
> > common functions, as segmentation, CID's, and padding.
> > It also defines common packet formats (IR, IR-DYN,
> > Feedback, Short-CID expander, etc), and it defines a
> > generic, profile independent, handling of feedback.
> > One can also say that it defines the general principles
> > for doing ROHC compression.

> As I'm not 100% sure what exactly is meant by a "packet
> format" (compressed or otherwise), it might be useful to
> capture in more detail what information needs to be defined
> to get interoperable ROHC profiles:

I think all existing header compression schemes should serve
as rather good references for what a compressed header format
is. Regarding capturing all that is needed to get interoperable
ROHC profiles, that is the role of the profile specification 
and not within scope for the notation.

> What we're really trying to define is a *function*, whose
> inputs are the uncompressed header and the context, and
> whose outputs are the compressed header and a (possibly
> updated) version of the context:
> 
>                           function

There is an inconsistency here. We have already agreed that
generating packet formats are not within scope for the notation.
The notation defines the content of the compressed header "body"
(using Carsten's terminology), but to compress the header and
get a compressed output, one have to generate the compressed
header format, and that is another step. 

> I'm not sure whether context replication is within the scope
> of the state machine - perhaps a more general term that
> captures all of the above would be "context management" issues?

Might be ok!

> A description of, say, TCP/IP in the formal notation will
> give you exactly what is defined in a) above.  You get a
> function whose inputs are the uncompressed header and the
> context, and whose outputs are the compressed header and a
> (possibly updated) version of the context.

Once again, this does not make sense. The notation itself only
defines the content of compressed header, not the actual
formats. You would have to take additional steps before you
can actually get a compressed header to send. (see Carsten's
mail).

/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 5 Mar 2003 16:49:28 -0000

> do it in the next revision, using e.g. material from below...

Oops!  Thanks for reminding me - I've added your text to the
source file so that it will be in the next revision of the draft.

> is.

I'm still not 100% clear about this - e.g. does a compressed
header format include a description of which fields update the
context?

> Regarding capturing all that is needed to get interoperable

However, the notation could itself be part of a normative
profile specification.  In this case it's important to
understand exactly what it does and does not define (so we
know how much else needs to be done before we have a complete
ROHC profile).

> generating packet formats are not within scope for the notation.

Yes, the notation itself doesn't help us to generate packet
formats (only to capture what's been generated afterwards).

> (using Carsten's terminology)

Unfortunately, I think that there might be a mistake in Carsten's
email which is causing some confusion:

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

This isn't the case - in fact the compressed headers generated by
EPIC and EPIC-lite have completely different bodies as well.

> but to compress the header and get a compressed output, one have
> to generate the compressed header format, and that is another step. 

From the notation's point of view, there's no difference at all
between the "discriminator" bits and the "compressed body".  In
each case, the notation just runs the relevant encoding method
to convert the uncompressed data into compressed data.

I'll try to explain this using an example.  Suppose we define how
to compress the TCP Source Port using the formal notation:

tcp_source_port   ::=   static / irregular (16)

On its own this description means nothing.  However, once we've
defined how the three encoding methods (static, irregular and "/")
actually work, then the notation specifies the exact bits on the
wire that need to be sent to compress the TCP Source Port.

Note that the "irregular" encoding method outputs bits that can
be considered to be part of the compressed body, whereas the
"self-describing values" encoding method (denoted by "/") outputs
a 1-bit indicator flag that can be considered to be part of the
discriminator.  However, the notation doesn't care which is which,
because all it does is invoke the encoding method and then stick
whatever bits it generates onto the compressed header.

EPIC and EPIC-lite work in the same manner.  If we want to use
EPIC-lite to compress the TCP Source Port instead, then we can
write the following:

tcp_source_port   ::=   static 90% | irregular (16) 10%

When the notation encounters the symbol "|", it invokes EPIC-lite
to generate a suitable discriminator for the compressed header.

> can actually get a compressed header to send. (see Carsten's

The only additional step needed to get "bits on the wire" is
to define all of the basic encoding methods that the notation
draft invokes.  However, from the notation's perspective there's
no difference between the "discriminator" and the "compressed body".
If we use LSB encoding, say, to generate the compressed body then
a definition of LSB encoding must of course be provided before
we get the compressed headers.  Equally, if we use EPIC-lite to
generate the discriminator then we have to define how EPIC-lite
encoding works.  Once this is done, the notation defines the exact
bits on the wire for each compressed header.

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 6 Mar 2003 10:07:14 -0000

Hi,

Referencing fields is certainly the main use of "temporary
variables", but there are some others that might be worth
taking into account.

In general, we use the variables to store any miscellaneous
information that an encoding method needs to compress a field,
but which isn't available in the uncompressed packet or in
the context.  I've had a go at listing all of the places where
temporary variables come in handy below:

1.  Using another field as a reference to compress a field

This is the example mentioned above.  Currently we store the
actual value of the field in a temporary variable, but it
would be ok to instead store a pointer to where the field can
be found in the uncompressed packet.  So the term "reference"
would be fine in this case.

2.  Using a "control" field to compress a field

In some cases the field that we want to use might be a
control field, i.e. one created by the compressor and not
found in the uncompressed packet.  An example for TCP/IP
compression would be the "Master Sequence Number".  I'm not
sure how we could do this as a reference, since the control
fields aren't stored anywhere in the uncompressed packet.

3.  Other values that might be needed for compression.

We also use temporary variables to store other values, which
can't really be considered to be "fields" at all (since they're
not part of the compressed or uncompressed packets).  Here are
some examples:

   a.  Remaining_Data : The number of bits remaining in the
       uncompressed packet.

   b.  Index : A pointer to the current context entry.

   c.  No_Update : Set to 1 if the encoding method is not
       supposed to update the context.

I'm not sure that "references" captures all of the above, but
there are probably better terms than "variables" which we could
use.  Comments welcome!

Regards,

Richard

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 6 Mar 2003 16:41:15 +0100

> header format include a description of which fields update the

Both yes and no. The format is the "bits on the wire", but how
to interpret these might of course depend on the state of the
context(s). As an example, in the RTP profile, some formats are
interpreted different depending on the current mode of operation.

> profile specification.

Well, the notation is just a notation, right? A profile 
specification might define new "encoding rules" in addition to
more general ones, but the notation document we are now working
with should be generally applicable. 

> formats (only to capture what's been generated afterwards).

Afterwards? Rather what should be used as input to the actual 
format generation, I think.

> wire that need to be sent to compress the TCP Source Port.

Yes, but the "/" encoding method is rather different from the
other two. static and irregular are only about the content to be
compressed, while "/" would also define how to combine things
together, i.e. create discriminators.

> draft invokes. 

Let me know if you have a different view, but the notation draft 
defines a notation "language", used to notate things. An
implementation of a notated profile might invoke encoding methods
described by the notation draft, but not the opposite.

/L-E