Subject: RE: [rohc] Congestion window tracking in RoHC-TCP

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Mon, 11 Mar 2002 09:44:52 +0100

Mark, Per & others,

> > I assume that RoHC-TCP is built upon EPIC-LITE even though the
> > enhanced version EPIC also exists. Hence, the proposal presents an
> > EPIC-LITE/TCP-profile, which was previously known as TAROC, that
> > uses congestion window tracking in order to achieve better
> > performance when handling the problem fields in Ipv4 and TCP
> > (IPv4-ID, TCP seqnr, TCP acknr, TCP window, TCP timestamp, etc).
> 
> Profile definitions are common to EPIC and EPIC-lite.  We 
> have suggested that the base solution be EPIC-lite, since
> we make no IPR claim on this. However, the same profile can
> be run through EPIC to generate the more efficient headers,
> should you wish!

Remember that the compressed header set is also part of the profile,
either the headers are written down manually in byte-aligned formats
or written as BNF for the "ROHC compressed header generator"
(EPIC-Lite). The "header generator" will produce different compressed
headers for optimal EPIC, so there will have to be two similar
ROHC profiles defined if one wants to define both Lite and the optimal
encoding. In general, we use to avoid multiple solutions and other
options, and we should probably do so also in this case. There
is always a tradeoff between simplicity, performance and also IPR
concerns.

> > Even in the case that this approach (the congestion window tracking)
> > is the best solution for TCP/IP compression, should it be in the
> > standard?
> >
> > My point of view, at this time is that it should be up to the
> > implementers of RoHC if they want to use congestion window tracking
> > rather than it becomes a standard. Hence, it might be explained in
> > an implementation issues chapter. Reason: "the bits in the air"
> > are not influenced by the use or no-use of congestion window
> > tracking. The motive to make something a standard must be: is the
> > method absolutely vital to guarantee functionality.
> 
> This is an interesting point.  It is certainly true that it 
> only affects the implementation of the compressor.  I'm sure
> others have an opinion on this..?

This was pointed out and briefly discussed in SLC, and there were no
arguments for mandating it in the protocol. The algorithm could
still be explained in an "implementation issues" section of the TCP
profile, but the protocol would not have to be built on this explicit
method for finding out the right number of bits to send.

Cheers,
/L-E

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Mon, 11 Mar 2002 23:22:20 +0000

> is always a tradeoff between simplicity, performance and also IPR

Fair point.  Perhaps I should say that the *input* to the header 
generation process (with respect to the protocol description) is 
identical in both cases, but that the output depends upon the generator 
used..?

[this also seems to include a sensitivity to the use of the word 
'profile' which I shall try to be careful of in future...]

Regards,

Mark.

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)