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

["Qian Zhang" <[e-mail]>]

Hi Mark and Per,

Thanks for those comments. Please find my comments inline...

BR,

Qian

> Mark wrote:
> 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...)
> 

As Per pointed out, congestion window tracking can improve the
performance of window-based LSB encoding. For those fields that will use
W-LSB encoding method and need to achieve robustness, include IPv4
IP-ID, using this algorithm can help to improve performance.

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

Yes, the intention for congestion window estimation algorithm is to
provide a high degree of robustness, without sacrificing efficiency
without needing explicit feedback. We had compared the performance of
our scheme with the existing schemes, include RFC1144 and RFC2507.
Details please find in
http://www.research.microsoft.com/users/qianz/draft-ietf-rohc-tcp-taroc-
03.txt.


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

Actually we had discussed this issue intensively around August last
year. 

The congestion window estimation algorithm can always over-estimate the
TCP congestion window if the TCP stacks following RFC2581. However, even
if we may under-estimate the congestion window size, we can still
utilize the TCP retransmission mechanism to re-send the incorrect packet
and re-build the context information.

For the TCP Eifel protocol part, we noticed that there is only the
discussion about the Eifel detection algorithm, which allows the TCP
sender to detect a posteriori whether it has entered loss recovery
unnecessarily. No corresponding window adjustment algorithm had been
discussed by now.

Anyway, we had added a minimum and a maximum constrain for the estimated
result, so that we can make sure that there is a minimum level of
robustness, and meanwhile we can avoid sending the context-updating
information too many times.


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

Well, for this issue, we had explained the roles of congestion window
estimation in the last email. Some further discussions will come soon.



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