[Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps?

[Richard Scheffenegger]

Unfortunately, timestamps are only reliable as long as there is no 
forward-path loss.

Also, in order to use timestamps as input to any congestion control 
strategy, you would want to exclude varations in the return channel from 
your measurement (currently, timestamps, and the measurement of RTT is not 
designed to do that; however, one-way delay variation measurements can be 
done by means of timestamps, if the timestamp clock rate of the opposite 
host is known locally. See Chirp-TCP and Mijra Kuehlewind/Bob Briscoes work 
in that area. Last, there are security / integrity concerns. Some early 
versions of BIC / CUBIC used timestamps directly as input signals. A 
malicious stack can modify the timestamp, and thereby influence the reaction 
of the senders congestion control algorithm (typically, to get an unfair 
large share of the bandwidth for this session).

Linux addressed these problems by a number of fixes, which are however, 
completely unfeasible in any other stack...

Mirja and I have written a very first sketch of tcp timestamp signalling 
improvements, to enable the use of timestamps for such uses (addressing 
integrity/security concerns, to make it a mroe reliable input signal into a 
congestion control scheme, and exchanging the local tcp timestamp clock 
rate, to enable one-way delay variance measurements; last, the improvements 
also allow a more reliable signal during loss episodes, so that synergistic 
methods to recovery more rapidely from lost retransmissions (1 rtt after the 
2nd loss, instead of 2+ rtts as linux currently does; btw, no other stack 
performs lost retransmission detection).

http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-01

(again, this draft is still in a very early stage, only sketiching the 
envisioned modifications and their potential use).

I invite everyone to join the TCPM session at IETF80 in prague, and 
participate in the discussion.

Best regards,

   Richard

----- Original Message ----- 
From: "Jim Gettys" <jg at freedesktop.org>
To: <bloat at lists.bufferbloat.net>
Sent: Tuesday, March 15, 2011 11:36 AM
Subject: [Bloat] Random idea in reaction to all the discussion of 
TCPflavours - timestamps?


> I've been watching all the discussion of different TCP flavours with a 
> certain amount of disquiet; this is not because I think working on 
> improvements to TCP are bad; in fact, it is clear for wireless we could do 
> with improvements in algorithms.  I'm not trying to discourage work on 
> this topic.
>
> My disquiet is otherwise; it is:
>     0) the buffers can be filled by any traffic, not necessarily your own 
> (in fact, often that of others), so improving your behaviour, while 
> admirable, doesn't mean you or others sharing any piece of your won't 
> suffer.
>     1) the bloated buffers are already all over, and updating hosts is 
> often a very slow process.
>     2) suffering from this bloat is due to the lack of signalling 
> congestion to congestion avoiding protocols.
>
> OK, what does this mean?  it means not that we should abandon improving 
> TCP; but that doing so won't fundamentally eliminate bufferbloat 
> suffering.  It won't get us to a fundamentally different place, but only 
> to marginally better places in terms of bufferbloating.
>
> The fundamental question, therefore, is how we start marking traffic 
> during periods when the buffers fill (either by packet drop or by ECN), to 
> provide the missing feedback in congestion avoiding protocol's servo 
> system. No matter what flavour of protocol involved, they will then back 
> off.
>
> Back last summer, to my surprise, when I asked Van Jacobson about my 
> traces, he said all the required proof was already present in my traces, 
> since modern Linux (and I presume other) operating systems had time stamps 
> in them (the TCP timestamps option).
>
> Here's the off the wall idea.  The buffers we observe are often many times 
> (orders of magnitude) larger than any rational RTT.
>
> So the question I have is whether there is some technique whereby 
> monitoring the timestamps that may already be present in the traffic (and 
> knowing what "sane" RTT's are) that we can start marking traffic in time 
> prevent the worst effects of bloating buffers?
>             - Jim
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat