Thanks for the many responses. Some have raised the same concerns,
so I'll answer them as one.
Mark Allman wrote:
> congestion avoidance is designed so that you probe the network very
> slowly so that you do not overrun the intermediate queues by more
> than a packet (which is a nice theory, but competing traffic can
> screw this up...).
You don't even need competing traffic. Consider a www server sending
a file to a www client across the internet, the last link being a
modem link with a much lower bandwidth than the rest. Say the modem
buffer can buffer 25 packets total and already has 17 packets
buffered and the window size is now 16 packets, which the server now
sends. 8 of those will get dropped.
Mark Allman wrote:
> See PSC's auto-tuning. Buffers are set on the fly by the operating
> system.
This sets the buffer sizes only at the end points, not in the routers
and only *after* tcp has figured out how big to make them.
Mark Allman wrote:
> Right. This has been observed. See the TCP Vegas work. The idea
> is similar to yours, but the details are a little different.
> Essentially they attempt to infer congestion based on the RTT
> compared to some BaseRTT (the minimum RTT observed).
No. They infer congestion based on throughput. Quote from TCP Vegas:
"Intuitively, the farther away the actual throughput gets from the
expected throughput, the more congestion there is in the network". Well,
I disagree. This may be true on the highway, but not on the information
super highway. When a highway is jammed, and the cars at the front
start to move, the ones at the back don't. They need to wait for a
space to appear in front of them. This is because fast moving cars
are farther apart than slow moving ones. In a TCP connection, throughput
is just as great when the pipe is nearly full as when it is nearly empty.
It is when the pipe is filling up that throughput will be lower. so
it is the rate of change of congestion, not the congestion itself that
TCP Vegas is measuring. So, it's window can drift.
On the other hand, rtt varies directly with the level of congestion,
so appears to me to be a more reliable measure of congestion than
throughput is. The difficulty with rtt is how to harness it well.
Figuring out what is a good rtt is easy: it's just the quickest one
measured. How high an rtt is bad is more difficult to judge. When it
reaches rto, it is definitely bad, because now you are getting a
retransmission, so I just chose a point halfway between the minimum
rtt and the rto as the threshold at which to throttle the congestion
window. I am open to suggestions as to how to better choose that point.
Mohit Aron wrote:
> It seems you're not aware of TCP Vegas (proposed in a paper in SIGCOMM '94)
> that already has most of what you're proposing. It has the same notion of
> minimum rtt but it uses sending rate (which is much more robust than rtt) to
> make decisions about changes in congestion window.
Can you make a case to support this ? Above is a case for the opposite.
Mark Allman wrote:
> It seems to me that with ample buffers (host and gateway), a modern
> version TCP and an active queueing mechanisms (and possibly ECN)
> there is no need for such a mechanism. It seems to me that a
We don't have ample buffers. True, newer routers have bigger buffers,
but newer hosts also have more memory and use tcp connections with
ever larger windows and even use many tcp connections at once over
a modem link.
Mark Allman wrote:
> Congestion control is employed to make the network robust in the
> face of lots of competing traffic. To avoid congestion collapse,
> there is a price. And, that price is performance. TCP with the
> current congestion control mechanisms does sacrifice performance of
> individual flows for the stability of the entire network. Trading
> in this robustness in for marginal performance gains (maybe) is
> dubious, at best.
I am not suggesting to trade any robustness. My proposal is only a
way to reduce the congestion window, not increase it.
Mohit Aron wrote:
> I'll also point out a flaw in your proposal. The rto is supposed to closely
> track the rtt in a way that it is always greater than rtt. Thus for a
> very stable network rtt would be almost constant and thus rto should be very
> close to rto. Also the minimum rtt would be close to rto. In such a situation
> you'll end up unnecessarily decreasing the congestion window.
Fred Baker wrote:
> the mean rtt has been deduced. But if stable times are achieved, then rto
> should approach min_rtt, as min_rtt and mean_rtt are presumably close to
> each other and the mean variance reduces. Does the fact that the rtt
> measurement has stabilized mean that we trigger a congestion-detected event?
If rtt reaches rto, a retransmission occurs. I did say that the algorithm
only applies if the difference between the minimum rtt and rto is greater
than 2 clock ticks, just for this reason. Also, such a connection is not
just in danger of reducing its window, it is also in danger of retransmitting.
Fred Baker wrote:
> The issue that comes to mind is the definition of min_rtt. Let's imagine
> that a TCP session is blazing along, has developed a reasonable rto and
> min_rtt value, and now routing changes. There are two possible cases.
>
> Case 1, routing got better, and delay has decreased, so a new min_rtt value
> is recognized. Case 1a, it isn't so very much better that it triggers the
> algorithm, and the TCP starts to adapt. Case 1b, it triggers the algorithm.
> In this latter case, why does it not trigger on every message until the
> adaptation has progressed enough to be within range? I should think that we
> want to adapt like this at most once per RTT.
My algorithm throttles the congestion window. Cases 1a, 1b do not trigger it.
Fred Baker wrote:
> Case 2, routing got worse, so the min_rtt is no longer a reasonable
> comparison value. Unlike case 1, there is probably a hiatus here - a line
> failed or something, and routing isn't fixed until the failure is detected
> and routed around. There are again 2 sub-cases: 2a, it isn't worse enough
> to trigger the algorithm, so what we have done is created a hair trigger -
> it will trigger as soon as even a moderate increase is detected, far less
> than the average of the two values. 2b, it does trigger the change.
>
> It seems to me that you want min_rtt to be the least rtt measured over the
> past few (10-20) RTTs, as opposed to the least RTT measured during the life
> of the connection. And you want to trigger this change at most once per RTT
> (which you may have said or intended, but I didn't find that in your note).
I suggested a slow 1st order filter to track up and a minimum detector
to track down. Your suggestion may be better.
Natchu Vishnu Priya wrote:
> there is no randomness here.. (synchronistion problems??)
It doesn't add any randomness, but doesn't subtract any either.
Natchu Vishnu Priya wrote:
> also this is an additive increase/ additive decrease scheme.. so it'll
> have problems of stability.... fairness problems..
It does not increase cwnd any more than before. It only decreases it. If
an unstable feedback loop were to develop, a dropped packet would dampen
it. This is no different than before.
Natchu Vishnu Priya wrote:
> Also for an algo like this we need to know if a set of connections which
> started in a congested environment will strive to keep the network
> congested later on too.... again questions of stability but from the
> network perspective.
My algo strives for less congestion.
[KC]onstantinos Dovrolis wrote:
> Right. But RED buffers can force TCP connections to a window size
> that is low enough for not having persistent congestion, and large
> enough for high throughput. In other words, TCP+RED move
> in the direction of maximizing the global network power, which is
> the utopia of networking.
>
> Having an Internet with TCP sources but not RED buffers, BTW, is like
> driving a Ferrari with diesel instead of gas.
Mark Allman wrote:
> True, but SACKs help if more than one segment is dropped. And,
OK, I agree that RED and SACK will do a pretty good job of getting good
throughput in the face of congestion. My algorithm is not in conflict with
those, I believe that a www server will get better throughput with it
when sending to a client with a modem and no SACK implemented. Even
fast retransmit/fast recovery is not implemented everywhere. My algo
does not make tcp more aggressive, in fact it will cause less dropped
packets.
/*******************************************************************\
* Jacob Heitz Tel:510-747-2917/Fax:2859 home:510-888-9429 *
* Ascend->Engineering->Software->Alameda mailto:[email protected] *
\*******************************************************************/
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:42 EST