[rohc] Congestion window tracking in RoHC-TCP

["Per Synnergren (EPL)" <[e-mail]>]

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

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? 

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?

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

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