Re: [rohc] Congestion window tracking in RoHC-TCP

["West, Mark (ITN)" <[e-mail]>]

Hi Per,

Thanks for your comments.  I've added some of my own...

Cheers,

Mark.


Per Synnergren (EPL) wrote:

  > Dear all,
  >
  > After been reading drafts published in the RoHC-working group I have
  >  a few comments about the proposal for TCP-compression in RoHC.
  >
  > In the following drafts:
  >
  > draft-ietf-rohc-tcp-requirements-03 draft-west-tcpip-field-behavior-00
  >

  > draft-ietf-rohc-tcp-01    (comment about this draft: this draft is
  > dated January 2001, it should be January 2002)
  >
  > the requirements for the RoHC TCP-profile are described , the TCP/IP
  >  field behavior is analysed, and finally a proposal of a RoHC-TCP
  > profile is given.
  >
  > 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!

The core of EPIC(-lite) is the packet generation / profile processing.
The core of TAROC is the congestion window tracking algorithm.

I don't think that congestion window tracking affects the handling of
the IPv4 IP-ID, since this is in a lower protocol layer and independent
from TCP behaviour (but someone may wish to correct me...)

  >
  > Basically congestion window tracking improves the performance of one
  >  of the encoding methods used in RoHC, namely window-based least
  > significant bits encoding. It is also concluded that the robustness
  >  of the TCP-compression scheme might be affected negatively if the
  > congestion window of TCP is under estimated.
  >
  > Questions.  Is it beneficial to use a "congestion window based"
  > compression strategy or what is the "real" gain by using TCP window
  >  estimation?
  >

I'll leave those who understand these things better to give a
quantitative answer, but the intent is to provide a high degree of
robustness, without sacrificing efficiency without needing explicit
feedback.

  > Is the improved compression large enough to compensate for the
  > larger complexity in the compressor and/or the eventual loss in
  > robustness due to the chance of underestimate the congestion window?
  >

Whilst I was one of those who was very skeptical about this approach (as
you may recall from previous IETFs and mailing-list discussion), it is
hard to construct scenarios where under-estimation is possible.
(My only lingering doubt concerns TCP Eifel...)

  > How "correct" is the window estimation and what happens if the
  > window is wrongly estimated (how good is the fallback mechanism)?
  >

If the window is over-estimated you lose efficiency, but remain robust.
If you under-estimate the window you lose robustness.  The latter is
the more serious.
Over estimation is much more likely.  The question is, what effect will
this have on effiency?  Again, I'm unable to put a number on this at the
present moment.

  > 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..?

  > Best regards.
  >
  > /Pelle ____________________________________________ Per Synnergren,
  > Ph.D., Lic. Eng., M.Sc. Research Engineer
  >
  > T/V - Multimedia Technologies AWARE - Advanced Wireless Algorith
  > Research Ericsson Research
  >
  > Ericsson AB Box 920 S-971 28 Luleå, Sweden
  >
  > Tel: [phone] Fax: [phone] Mobile: [phone]
  >
  >
  > _______________________________________________ Rohc mailing list
[e-mail]
  >

  > https://www1.ietf.org/mailman/listinfo/rohc
  >


-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone [phone]   Fax  [phone]

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