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

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Fri, 23 Sep 2005 17:11:27 +0200

comments inline.

> 
> See notes below:
> 
> Kristofer Sandlund (LU/EAB) wrote:
> > Hi Joe,
> > 
> > just to provide some feedback on your high-order comments 
> below (wearing my
> > ROHC-TCP co-author hat).
> > 
> ...
> >>
> >>My personal impression is that this notation hurts more 
> than it helps,
> >>and should not be pursued further.
> >>
> >>Joe
> > 
> > About half the WG have fought to drop the FN altogether 
> since we also felt that it 
> > gave no real benefit compared to the box notation. The 
> other half did not feel that 
> > way, and after we had repeated that discussion many times, 
> the decision was taken 
> > to go with the FN. I never really felt that it was the 
> right way, but that's 
> > the consensus decision that was taken. Of course it is 
> never too late to change 
> > such a decision, but this is the kind of feedback that 
> would have been more useful 
> > in any of the first 100 discussions on this topic than at 
> the time we actually
> > have a working version :) Trying to swap back to box 
> notation would set us back
> > quite a long time with the TCP profile, and honestly, I'm 
> not sure it is worth
> > the "cost" of doing that in this late stage.
> 
> IMO, the cost is very small, and the cost to keeping the 
> current doc as
> depending on a dense, 50-page notation spec is very high - to EVERY
> reader thereafter.
> 
> I'm sorry that I wasn't part of that earlier discussion, but you asked
> for detailed feedback from some folkes in TCPM, and I did what I could
> by the time I knew about it.

I wasn't trying to point finger, I really appreaciate you guys taking
the time to review our documents, and comment on them.
I'll look over your comments on the TCP draft as soon as I can and give
my views on those.

> 
> > Note: We also have had very long discussions on the 
> "normative comments", and the
> > reason why they are as they are today is also a consensus 
> decision, but here
> > I think we reached the correct decision, since it would 
> open up a whole can of
> > worms if we were to make these normative (the reasons 
> should be somewhere in the
> > ROHC mail archive even if I can't recall them right now).
> 
> That's worse, IMO - it's a very clear indication that the 
> notation fails
> exactly where it's needed, and again a case for going back to the box
> diagrams.
> 
> ----
> 
> While I appreciate that the IETF process revolves around consensus,
> sometimes that spirals into designing something that everyone 
> can agree
> to but does not solve the original problem.

Well, the latest revision of the FN actually does solve the problem in the
sense that it _works_, but I agree that it does not help the readability
very much. But the earlier versions actually tried to specify a compiler
that could "run the FN", so we're at least a lot better off now.

> 
> To me, for notation, utility, clarity, and brevity are paramount, and
> all seem to have been sacrificed for consensus, unfortunately.

Like I said before, I've been opposing this time and time again and
I'm a huge fan of the box notation, but when more than half the people
writing the specs are all for the FN, there's not that much more we could do
than use what has been decided.

BR,
	Kristofer

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Sep 2005 10:49:55 -0700

...
> I'll look over your comments on the TCP draft as soon as I can and give

FWIW, I'm not trying to point fingers either. I appreciate that a lot of
work went into these docs. I'm more interested in ongoing utility,
rather than avoiding the 'loss of effort' which I appreciate would be
disappointing if these docs were not ultimately useful.

> that could "run the FN", so we're at least a lot better off now.

What does "it _works_" mean if the notation lacks something so
fundamental that there are pseudonormative ways of commenting the
notation that end up being used throughout?

> than use what has been decided.

I would ask "will the people reading the specs appreciate the FN",
rather than weighing the position of spec authors in that regard.
Ultimately, they're the ones who pay the price if it obfuscates the spec...

Joe

---

From: Mark West <[email-masked]>
Date: Mon, 26 Sep 2005 10:46:20 +0100 (BST)

Joe, Kris,

It's extremely useful to have a new perspective on this stuff, since we've
pretty much kicked it to death within the group.  (Adding my sincere
thanks to Joe for his very detailed review.)

I would like, though, to make sure that we're all talking about the same
thing since I, at least, am slightly confused...

What exactly do you mean by 'box notation'?  And what is the problem for
which we are arguing about the solution?

Here's a bit of box-notation taken from the current TCP profile:

   0   1   2   3   4   5   6   7
 +---+---+---+---+---+---+---+---+
 | 1   0   1   1   1   1   1   0 |
 +===+===+===+===+===+===+===+===+
 |              SN...            |
 +---+---+---+---+---+---+---+---+
 |              ...SN            |
 +---+---+---+---+---+---+---+---+
 |      MSN      |PSH|    CRC    |
 +---+---+---+---+---+---+---+---+

This tells me that I have 16 bits of sequence number.  Great!  How do I
map those bits to a decompressed SN value?  Well, that may be different
for every compressed packet type in which SN bits appear.

What about the *absence* of a field?  If IP ID is not encoded, does that
mean that it's unchanging?  That it appears somewhere else in the
compressed header structure?  That it should be inferred?  That it isn't
present at all?  All are possible.

So I don't understand how 'box-notation' can specify the (de)compression
of a field that does not appear in the compressed header.  Or am I missing
something?

My understanding is that we are trying to solve two problems:

- identifying and specifying a toolbox of 'methods' that can be used to
  compress header fields within a ROHC profile; and

- specifying which set of methods applies to all fields of the
  uncompressed header for any given compressed header.

How do you think these *should* be solved?

I'm not going to try and argue whether or not *the* notation is the right
answer.  However, I do still believe that there is utility in *a* notation
that formalises things (compared with English language).  (I guess I'm
asking if you think that the concept was inherently stupid, or if it was a
failure to realise the concept in a useful way.)

Thanks,

Mark.

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Sep 2005 08:31:44 -0700

Hi, Mark,

Notes below...

> which we are arguing about the solution?

The diagram that follows immediately below.

> Here's a bit of box-notation taken from the current TCP profile:

It tells me that I have 16 bits of sequence, and where those 16 bits are
relative to all other fields.

I don't think anyone is arguing that box notation without text is useful.

> present at all?  All are possible.

It depends - as exactly with the FN, whether it exists in a substructure
- i.e., other box or encapsulated description. Its absence in a
particular FN section - just like a box - doesn't tell you much either.

> of a field that does not appear in the compressed header.  Or am I missing

It doesn't, but neither is that necessarily encoded in FN.

> How do you think these *should* be solved?

The toolbox of methods: pseudocode, where well-known operators aren't
used rigorously (<, <=, etc.) or changed (let, =, etc.) somewhat
arbitrarily.

Specifying which set applies to all fields: text notation. I found
figuring this out from the FN to be a very complicated process where
meaning (e.g., whether something is a control field) to be inferred from
something that could be buried many sections away.

> failure to realise the concept in a useful way.)

The notation is close enough to C structures; why not use that as the
pseudocode? at least it might compile ;-) you could always add
additional structure/rules, akin to making a library or (gasp) an object
class.

The point is that there COULD be a notation with utility, but there
would be a few constraints:

	- MUST NOT require 'formal comments' to be useful

	- MUST be capable of compiling to something useful
	maybe not running code, but outputting boxes for each
	header would be useful, or listing all control variables,
	etc.

The other example of this would be EBNF, which does compile to something
useful - a parser that can verify syntax.

Joe

	-