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" <[email protected]>
To: <[email protected]>
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
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
