Subject: [rohc] Comments on ROHC-FN -05 (draft-ietf-rohc-formal-notation-05.txt)

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 23 Feb 2005 16:54:01 +0100

I've reviewed the FN draft and I can notice that it has improved
significantly during the last year. It is today both clearer what
is the actual purpose of the notation, how it works, and how it is
supposed to be used, and it is more compact than ever (actually
only 32 pages). However, we are not finished with it yet, and my
comments are the following:

More significant issues:

- Section 3.1 + Terminology->Profile:
     I am very uncomfortable with the simplistic description of
     what constitutes a profile, i.e. that it is simply about 
     "1. Packet formats" and "2. State machine". I can accept the
     first part, packet formats, i.e. the bits on the wire, but
     I really think "state machine" is a bad high level label 
     for all the rest. Further, the "state" term is so overloaded
     in ROHC that it also therefore should be avoided. The text in
     3.1 gives indeed a good overview what a profile is about, and
     I do not really think the document benefit from having the
     high level labelling of profile functionality as it currently
     has. 

  I therefore propose to update the second part of 3.1 (from "Each
  ROHC profile...") with something along these lines:

    "On a high level, one can say that each ROHC profile is built up of
     packet formats (defining the bits on the wire) along with a set of
     rules that control compressor and decompressor behavior.
   
     The purpose of the packet formats is to define how to compress and
     decompress headers.  The packet formats define one or more 
     compressed versions of each uncompressed header; inversely, the
     packet formats define how to relate a compressed header back to
     the original uncompressed header.

     The packet formats will typically compress headers relative to a
     context of field values from previous headers in a flow, improving
     the overall compression by taking into account redundancies
     between headers of successive packets.
     
     Apart from the packet formats, a profile thus has to specify how
     to manage these contexts at the compressor and the decompressor,
     define when and what to send in potential feedback messages from
     decompressor to compressor, outline compression strategy principles
     to make the profile robust against bit errors and dropped packets,
     etc. All to ensure that the compressor and decompressor contexts
     are kept synchronised, while still achieving best possible
     compression performance.

     The ROHC-FN is designed to help in the specification of the packet
     formats used in ROHC profiles.  It offers a library of encoding
     methods for compressing fields, and a mechanism for combining these
     encoding methods to create packet formats tailored to a specific
     protocol stack. Note however that the scope of ROHC-FN is limited
     to specifying the packet formats, while all the control logic for
     the profile behavior is to be defined by other means, to form a
     complete profile specification."

  The Terminology->Profile should then also be updated so that it does
  not overload the profile definition in 3095, based on the above text:
    
    "A ROHC (RFC 3095 [4]) profile is a description of how to compress
     a certain protocol stack over a certain type of link. Each
     profile is built up of packet formats (defining the bits on the
     wire) along with a set of rules that control compressor and
     decompressor behavior."

- Let statements:
  I find the let statements rather confusing. First of all, the name is
  not very informative, and the use of let seems to be twofold. The 
  general purpose (as described) seems to be to assert, so why not call
  it "assert" or "if" instead, that would make the name much more 
  informative. However, from how I read the third bullet on page 17,
  let seems to be used also for a non-assert purpose, so maybe we should
  have a let statement also, for that purpose. This third bullet really
  confused me, and I do think we will have to redefine/rewrite this
  part!!! The assert purpose is not very clear on a general level, it
  is useful to be able to capture the conditions for when a format can
  be used, but then we should explain better that this is part of the
  notation, and also make the mechanism more intuitive. It is never 
  defined anywhere what it really means that a format "succeeds".

- Section 4.8 is to me mainly stating a number of obvious things, and by
  having a section like that it created more questions than it answers.
  The FN itself has no productive value before it is actually used in a
  profile specification, and then the scope of that usage is of course
  local to that profile specification. I propose to basically keep the
  content of the first paragraph of 4.8, but rewrite the rest and make
  the whole section much shorter, e.g. to have the following 4.8 text:

 "4.8  Profile-specific Encoding Methods

    The library of encoding methods defined by ROHC-FN provides a basic 
    and generic set of field encoding methods. When using ROHC-FN in a
    ROHC profile specification, some additional encodings specific to
    the particular protocol header being compressed may however be
    needed, such as methods that infer the value of a field from other
    values. These methods are to be based on the properties of the
    protocol being compressed, and will thus have to be defined within
    the profile specification itself. Such profile-specific encoding
    methods, defined using either ROHC-FN syntax or in plain text, can 
    be used as part of a formal definition of the packer formats of the 
    profile, as any other methods from the ROHC-FN library."

- Appendix A: Can this appendix really be justified to keep in the
              document, I can not see that it is needed. I would say
              we should remove it.

- Appendix B: Is this appendix up-to-date? And should we still keep it?
              The TCP profile is also an example, although it is much
              more complicated. I do not have a clear opinion, what do
              others think?

Nits, editorials, and other minor issue:

- Abstract: Remove the reference, i.e. replace:
     "...ROHC (RFC 3095 [4])..."
  with:
     "...ROHC (RFC 3095)..."

- Terminology->Field: It is not the FN that divides the header
                      into fields, that is something the profile
                      designer do. But FN *operates on* fields.
  I suggest replacing the Field definition with something like:
     "ROHC-FN is to be used to define the mapping between uncompressed
      and compressed headers in ROHC profile specifications. It is
      applied to a set of contiguous bit patterns, commonly referred to
      as fields. It should be noted that how the header is divided into
      fields is decided by the profile designer, and must not
      necessarily be identical to the one given by the specification(s)
      for the protocol header being compressed."

- Last sentence in 3.2.1 says "Otherwise, the binding will fail and an
  alternative encoding method must be used". However, the text is in the
  decompressor text, but should instead be part of the compressor text.
  The consequence of an unsuccessful binding at the decompressor is
  rather that the packet will have to be discarded, and the context
  probably invalidated (but that is part of the profile logic to
  specify).

- Section 3.2.2:
  * It is unclear whether "structure is a reserved word", better to
    use e.g. "example_structure === ..."
  * The field names confused me, why 1,2, etc and then a,b, etc? Should
    not all field_* be a,b,c...etc?

- Second paragraph on page 9, add comma and replace "an" with "a", i.e.:
  "In the example, packet formats defined by "co_format" also indicate a
   list of..."

- Third paragraph on page 9, add a "not" on the third line:
  "...but which do not have an..."
                   ^^^
- What happened to the last paragraph of section 3.2.2???

- Last paragraph of section 4.2, add comma x2:
  "Because the FN is referentially transparent, constants are entirely
   equivalent to the value they refer to, and are completely
   interchangeable with that value."    ^     ^
                                        ^     ^
- Second last paragraph of 4.3, remove "it":
  "...appear in it the uncompressed header."

- Section 4.3.1, just an observation: Could we have a better example 
  than a control fields, and maybe make clearer where attribute ref's 
  would be useful?

- Third paragraph of 4.4, remove "it":
  "...appear in it the uncompressed header."

- End of 4.4, please explain also WHY the tcp_list_length example is
  illegal, one sentence after the example.

- Section 4.4.4, second bullet "down to the next lowest" sounds strange:
  Suggestion: "...down to the nearest integer."

- Last paragraph of section 4.6, replace "then" with "them"
  "...when inserting them into the..."

- Section 4.7, suggest to rename to:
  "Library of Encoding Methods" or "Encoding Methods Library"

- End of section 4.7.1: Explain what nbits is in the example.

- 1st sentence of section 4.9.2.1, should "that" be replaced by "they"?
  "...in the order they appear in..."

- End of third paragraph of section 4.9.2.1, missing "least"??
  "...to represent the least significant part."

- 1st paragraph of section 4.9.4.3, second sentence: Some words are
  missing here, it says:
  "...if no encoding method for that field elsewhere."

- Explain the example in 4.9.4.3, specifically, what is the effect of
  the let statement there?

- I do not know, but the last part of 4.9.4.3 is not very clear to me, 
  where default method overriding, and "uc_format" field encoding lists.

- Section 4.9.4.4, last sentence, should an "also" be added?

- Section 4.9.5, first sentence, should it not be "any field", not
  "any fields", i.e. remove "s"?

- Second paragraph of section 4.9.5 is actually discussing a potential
  profile design choice. I suggest rewriting it as follows:

  "For example in IP, the behaviour of the IP-ID field in a flow varies
   depending on how the endpoints handle IP-IDs. Sometimes the behaviour
   is effectively random, sometimes the IP-ID follows a predictable
   sequence, and at other times it stays fixed at zero. How the IP-ID
   behaves is information that is never communicated explicitly in the
   uncompressed header, but a ROHC profile can still be designed to 
   identify the behavior and adjust the compression strategy according 
   to the identified behavior, thereby improving the compression
   performance. To do so, the profile can introduce an explicit field
   to communicate the IP-ID behaviour in compressed headers, and in
   ROHC-FN terms this is done by introducing a control field:"

- The second example in 4.9.5:
  * "format" should be "co_format_***", right?
  * can we have a more specific example name than "ctrl_field", e.g.
    "scaled_field"
  * "length" should be "uncomp_length", right?
  * This example, and also other examples, should have a few words
    explaining it, so that the example becomes more useful to a reader.

- "Contributors" sections are usually used when only the editor is
  listed on the front page, while a number of authors have contributed
  with text to the RFC. I think this acknowledgement to Richard should
  be put first in the "Acknowledgements" section, and remove the initial
  seven words before the comma. 

- References must be split in Normative and Informative. From looking at
  them, I conclude that:
  [1] is never used, remove!
  [2] is Normative
  [3] is Informative, as it is only referred to in an informative manner
  [4] is Informative, as it is only referred to in an informative manner

- Add section number also to Authors' Addresses, i.e. section 8
  (assuming current section 6 is merged into current 7).
  Also correct Ghyslains address, write it "Lulea".

- Check the document for nits at:
   http://ietf.levkowetz.com/tools/idnits/idnits.pyht

BR
/Lars-Erik

-----------------------------------
Lars-Erik Jonsson, M.Sc.
Senior Research Engineer
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]                      /"\
Phone: +46 8 404 29 61                                      \ /
Fax: +46 920 996 21               ASCII Ribbon Campaign      X
Home: +46 920 999 57           against HTML email & vCards  / \

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.

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