Subject: [rohc] FW: [tcpm] WG last-call of TCP header compression

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 22 Sep 2005 15:45:33 +0200

These comments were sent to me and Carsten long ago, I thought
they were part of the mail I just forwarded. Joe, if these are
not complete, please send the full set of notation comments to
the rohc list.

Thanks!
/L-E

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]

-------

draft-ietf-rohc-formal-notation-09.txt

Overall comments:

	the notation description is easy to read, but has areas that
	don't make sense:
		- if every header has two (uncompressed, compressed)
		or three (+ control) parts, why not define the structure
		that way? right now it looks too much like free-form
		C structures on which you impose rules, but it is hard
		to _see_ whether the rules are followed

		- if there are alternate formats, why not list them
		as alternates (using BNF "|") rather than new names?
		i.e., why use co_format as a prefix, rather than
		say:

			header === {
				<base format>
				COMPRESSED
				cf1 = ...
				cf2 = ...
			}

		i.e., omit the word uc_format, and the prefix co_format,
		and use a single keyword to separate the parts;
		allow the co_format headers to be named without
		requiring prefixes
	overall, it would be useful if the notation ended up being
	somewhat self-descriptive; this seems very contorted to me

	the examples tend to show the exceptions rather than the rules;
	get the base rules out, then show exceptions

	there should, IMO, be exactly one way to describe things
	in the basic language; having equivalent expressions is a
	good way to end up with incomparable alternates

MAJOR QUESTIONS:

*notation appears to ignore reordering?

	mentions loss and corruption, but not reordering

*is there any notion of keeping multiple states
	i.e., keeping K parallel interleaved streams -
	which can tolerate reordering up to K-1 packets,
	but which are all associated with a single stream?

*4.9.4.2
	if the compressor can pick any format that succeeds,
	does this mean it cannot pick the 'better' format, for
	some definition of 'better'? (shorter, uses more recent
	context, etc.)

MINOR OBSERVATIONS and QUESTIONS:

4.9.2.1
	discusses LSB-ish fields of seq nums, but suggests the
	field be split into two, rather than LSB-encoded
	this is a poor example, IMO

4.7.4
	*static is defined as 'same as previous packet's value',
	but should be 'constant within a flow'
	the two do not seem the same - are IDs static if prev
	packet's 'more fragments' bit==1?

notation comment
	::= is EBNF - it might be useful to use something that
	indicates that the encoding is bidirectional, and which
	is the larger, e.g., <=-> or <<--> or somesuch

	the way in which control_field_3 is different should be
	more readily apparent from the syntax (sec 3.2)

	constants are defined and structures defined using the
	same operator (=)

	log2(w) seems misnamed; bitsize(w) is more descriptive

	are boolean operators short-circuit? (doesn't matter
	if there are no side-effects)

	why do compressed values have shortcuts of 'xx', where
	there is no shortcut for uncompressed values?

	irregular seems an odd term; why not just indicate the
	length and let the encoding be left absent?

	it would be useful to define CRC as taking a list of
	polynomials as an argument, or provide an equivalence macro
	(sec 4.7.6)

	why have LETs and encoding methods? why not define one, and
	let there be an optional macro that equates the two? (4.8)

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Sep 2005 11:36:24 -0700

> not complete, please send the full set of notation comments to

Sure - the high order 'bit' of feedback on the formal notation:

I find header layout diagrams useful, and wish that the current notation
would add to what they communicate.

In their current form, they don't - the biggest example of this is the
use of structured comments _outside the language spec_ that indicate
basically what header layouts would (bitfield size and order in a single
place). It would be nice if the current notation could be 'compiled'
into the layout diagrams (at least), but that seems to be hard to do in
its current form.

As I hinted originally, it's not at all evident that this 50-page
document - a prerequisite to the TCP doc - makes any of the TCP doc
easier to understand or implement.

My personal impression is that this notation hurts more than it helps,
and should not be pursued further.

Joe

- ---------------------

Some additional comments noted on a second pass; some of these may be
redundant with those previously noted:

- - the notation is BNF-like in some places (::=), C-like in others, and
decidedly bizarre (IMO) in others (===). If there is a reason this
doesn't look basically like a combination of C-structures and C-code
(maybe, *gasp*, C++ -like?), a case needs to be made.

- - keywords are very hard to distinguish from variable names; the use of
structured keywords (co_format_a, co_format_b, etc.) is extraordinarily
cumbersome, esp. since it can be easily replaced by a structure
(co_format[a], co_format[b], e.g.)

- - it doesn't seem that control fields can be conditional - is there a
reason?

- - the notation appears to imply that there is a 1:1 correlation between
compressed and uncompressed messages; is this necessary, and does it
inhibit some forms of compression (e.g., ACK compression could be
performed by an intermediary)

- - the use of control fields, which hvae no uncompressed value, should
not need to be explained - it should be highlighted in the structure.
right now, the only way to find such fields is exhaustive search of the
structure.

- - some of the terms are obscure, e.g. why use "uncompressed_value" as a
function rather than the obvious term "constant" or "fixed"? or
"irregular" vs the term "raw" or "uncompressed"? "log2" really means
"bitsize", since it is more like ceil(log2(N)).

- - the discussion of the IP checksum on page 12 failes to indicate what
fields the checksum is inferred from; that seems more important than the
opaque function "inferred_ip_v4_header_checksum" - which isn't listed as
taking arguments.

- - 4.1 talks about the spec being written in 7-bit ASCII; it's in 8-bit
(in Internet RFCs), although it uses a subset of values from 7-bit ASCII.

- - 4.2 should indicate whether 'alphabetic' is case sensitive or not;
later it specifies that constants must use uppercase and others must use
lowercase; this is archaic, IMO.

- - in 4.2.2 it makes no sense that bits on the wire are always
interpreted as unsigend, but the notation supports negative values. They
should be consistent. and if the value is -1, then it should evaluate to -1.

- - in 4.5, why is the example of tcp_list_length illegal? would it be
illegal if it were:
	tcp_list_length:uncomp_value ::= (data_offset + 20) / 4;
if so, why is the notation so pedantic here, and allows inferences
elsewhere about value/size?

- - 4.5.1 "-10" is "negative ten" commonly; the term 'minus' usually
refers to the infix binary operator, not the prefix unary operator

- - 4.3.5 should discuss whether these logical operations are
short-circuit or not

- - 4.5.4 it seems odd to round to negative infinity, esp. since the
document goes to great lengths to explain that values are unsigned. why
not say 'round to zero'? and even if signed values are used, why is
round to negative infinity useful or appropriate?

- - 4.5.5. what can be tested - only values, or formats too?

- - 4.6 the use of the "until EOL" comment character is OK, but there
should be an alternative which allows blocks of code to be commented out
as well (a paired comment delimeter)

- - 4.7.1 why is it not easier to say the following, esp. if the length of
the field is already constrained?

	field:uncomp_value ::= 3;

I.e., why do you need both the uncomp_value selector and the
uncompressed_value function?

- - 4.7.2 why are quotes even needed? and why are only binary strings
allowed? i.e., why not use the notation consistently:

	discriminator ::= 0b01101;

- - 4.7.4 static seems to apply (IMO) to all headers in the flow, not just
'the same as for a previous header in the flow'.

- - 4.8 why is 'let' needed? why not just allow as above - i.e., the use
of the selector to indicate that only this portion is set?

	field:uncomp_value ::= 3;

also, this section says that lets must be used only inside a field
encodings list, but also discusses the use of boolean expressions.

Huh?

why not use an 'if' or 'test', like other modern notations?

- - 4.9.5 as with the TCP doc, the IP ID cannot be valid if it is zero;
this should be omitted from the discussion

- - A.3 "using this simple scheme" - the fixed values are per flow, or per
protocol? if the latter, they MUST be dependent on the version number of
the protocol

- - A.5 the example should use version numbers; otherwise, what heppens
when a new version appears?

- - pg 44 discussion on using 0 vs 01 - 'care' shouldn't be needed; the
notation should suggest this.