Subject: Header compression in the LINK draft (or a new draft?)

From: "Jan Kullander (ERV)" <[email-masked]>
Date: Tue, 11 Apr 2000 14:48:13 +0200

Hi,

It is obvious to a link designer that extra money could be earned if header
compression is made non-transparent (i.e. if e.g. IP ID is generated by the
decompressor, the header checksum is recalculated, not all TCP timestamp
options are transferred etc.). There are however no guidelines describing
consequences (cost) of lost transparency other than general wording. I see a
need for a detailed consequence description of lost transparency for each
specific TCP/UDP/RTP header field. The consequences should be related to the
standards as they are, to current implementations as known and maybe even to
currently proposed standards as they often seem to superimpose new
functionality on existing fields.

I've noticed that the ROCH charter requires the decompressed result to be
semantically identical to the original. This decision has surely been
preceded by discussions that could be documented.

maybe it could be a draft of its own If the detail level of my proposed
documentation doesn't fit in the LINK draft ?

/Jan Kullander

----------------------------
Ericsson Mobile Data Design AB
Jan Kullander
Tel (Direct):  +46 31 344 6057   Fax:  +46 31 344 6033
Email:  [email-masked]
Address:   S:t Sigfridsgatan 89   /   412 66 Gothenburg   /   Sweden

---

From: Vern Paxson <[email-masked]>
Date: Tue, 11 Apr 2000 10:42:05 PDT

> preceded by discussions that could be documented.

Actually, "semantically identical" was chosen over "bitwise identical"
to allow for some wiggle room, and the hairsplitting arguments about
just what are the semantics have *not* yet been thrashed out.  This
would be a good discussion to have.

		Vern

---

From: "Jan Kullander (ERV)" <[email-masked]>
Date: Wed, 12 Apr 2000 10:45:20 +0200

>would be a good discussion to have.

Not being American I missed that nicety...

Still, I think a documentation on the consequences of breaking the
e2e transparency for each field would be more beneficial than a
general discussion of principles. A ban on non-transparency will
not prevent link designers from doing it but if they know the
consequences, at least there will be fewer surprises.

/Jan Kullander