From: Werner Almesberger <hidden> Date: 2003-01-02 06:08:58
kuznet@ms2.inr.ac.ru wrote:
It does the thing which it is supposed to do: prevents reducing cwnd below
1/4 of original one.
Okay, this it does. I guess the only case where this would make a
difference is if your network duplicates packets.
This was proposed in one of rete-halving related drafts
with title sort of "...boundary checks...", I forgot exact title, can find
it if you are curious.
I searched around but didn't spot anything. A pointer would be
welcome, thanks !
Maybe this is even correct, but I do not see why it can be essential.
cwnd falls too low not due to decrementing due to rate-halving,
but due to draining out in_flight when we are not able to keep pipe full.
Yes, but rate-halving is what causes in-flight to drop in the first
place (assuming we have enough fresh data to send, of course), no ?
Please, show.
I've put graphs of a simulation run (with and without the change) at
http://www.almesberger.net/misc/half.epshttp://www.almesberger.net/misc/quarter.eps
Y-axis is in segments, x-axis is in some arbitrary time unit, RTT is
one initial cwnd (100 packets), path is asymmetric with zero-delay
and loss-less backward channel. (While unusual, this shouldn't
actually affect what TCP does in recovery.) Losses happen right
before the packet hits the receiver.
I've also asked Cheng if he can send you a copy of his simulator.
Thanks,
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
I searched around but didn't spot anything. A pointer would be
welcome, thanks !
I bring apologies for silence. I see you have already found it.
Yes, but rate-halving is what causes in-flight to drop in the first
place (assuming we have enough fresh data to send, of course), no ?
Of course. But draining happens when you received more ACKs than
you sent packets. When such pathalogy happens we just have to do something,
at least to understand when it happens under normal conditions.
Probably, the reason of confusion is that original rh seems to include
some bits of "lost-sensitive recovery", so cnwd really is supposed to shrink
to cwnd/2 - lost there. See? We do not make this, and the check for 1/4 really
look as an alien.
I see. Not quite understand the reason though. :-) You said something
about lost retransmissions... How much of retransmits were lost
in the simulation? Are you aware that each lost retransmission,
if we behaved honestly, would collapse cwnd to 1? :-)
Alexey
So... recovery is supposed to terminate when snd.una reaches 100
(snd.nxt at beginning of fast retransmit). In this case cwnd would
be orig_cwnd/2, as expected. But it did not stop! Hence, something
extraordinary happened while recovery, which resulted in the second recovery.
But I do not understand why snd_ssthresh was not shrinken too.
All this smells like a bug. I do not see from the picture
what was this. Can you make a pseudo-tcpdump instead of picture?
Alexey
From: Cheng Jin <hidden> Date: 2003-01-14 01:20:06
I see. Not quite understand the reason though. :-) You said something
about lost retransmissions... How much of retransmits were lost
in the simulation? Are you aware that each lost retransmission,
if we behaved honestly, would collapse cwnd to 1? :-)
Yes, I am aware of this, and when this happens, cwnd will sit @ 1 until
TCP gets out of recovery (1 retransmits per rtt). It's debatable whether
cwnd should remain 1 for the rest of the recovery period even if really
sever congestion brings cwnd down to 1. For example, if there are 100
pkts to be rexmitted when cwnd gets to 1, it will take at least 100 RTTs to
leave recovery. By then, whatever network condition that causes congestion
in the first place might be long gone already, but one wouldn't know the
true state of the network with such a small cwnd. Maybe cwnd could be
clamped at some minimum value (greater than 1) depending on ssthresh?
From what I have observed, cwnd gets reduced to 1 mainly because of lost
retransmits. I think the tcp_rs can show that. Linux TCP deals with a
lost retransmit by reducing retrans_out by one so in_flight ends up
becoming one less. In tcp_cwnd_down, cwnd is always clamped at in_flight
so if many rexmits are lost (over many RTTs), cwnd gets reduced quite
often. However, when cwnd is small, loss retransmits are not reliable
signals for the severity of congestion, for example, when cwnd is 10,
does losing one pkt mean 10% pkts loss in the network? Again, I am not
saying right or wrong about how cwnd changes, but it is something that
we could think about.
THanks,
Cheng
Yes, I am aware of this, and when this happens, cwnd will sit @ 1 until
TCP gets out of recovery (1 retransmits per rtt). It's debatable
Nothing to debate, really. Following specs lost retransmission must trigger
RTO timeout with sunsubsequent slow start starting from 1.
We are _more_ liberal when SACKs are on, this really can be argued
and I am ready to defend the liberal values. :-) But when we cannot
detect loss opf retransmission, we have to return to standard go-back-n
behaviour.
pkts to be rexmitted when cwnd gets to 1, it will take at least 100 RTTs to
Not a big deal. You have to wait the same 100 RTTs at start of each connection,
even though initial slow start _assumes_ that no congestion is present.
So, when you experienced real congestion, slow start is really fair. :-)
In tcp_cwnd_down, cwnd is always clamped at in_flight
so if many rexmits are lost (over many RTTs), cwnd gets reduced quite
often.
It is (half of) loss-sensitive recovery. Luckily, we are not mad enough
to shrink ssthresh as well. But imagine, month ago I had long boring
argument with a guy who insisted that ssthresh must be shrinken too,
otherwise "cwnd grows too fast". :-)
does losing one pkt mean 10% pkts loss in the network?
Not less than 10% of loss. Maybe, more, but you were lucky and your
packets percolated through deadly congested router. :-)
It is basic assumption of cwnd avoidance: each loss is considered
as loss due to congestion.
Alexey
From: Cheng Jin <hidden> Date: 2003-01-14 01:58:07
quoted
Yes, I am aware of this, and when this happens, cwnd will sit @ 1 until
TCP gets out of recovery (1 retransmits per rtt). It's debatable
Nothing to debate, really. Following specs lost retransmission must trigger
RTO timeout with sunsubsequent slow start starting from 1.
I don't always see time-out+slow-start in this case. I have seen
TCP staying in recovery for a very long time with cwnd=1. I think Linux
TCP has various detection mechanisms for lost rexmit so time-out doesn't
always happen. I think there is lost rexmit detection code at the end of
tcp_sacktag_write_queue.
We are _more_ liberal when SACKs are on, this really can be argued
and I am ready to defend the liberal values. :-) But when we cannot
detect loss opf retransmission, we have to return to standard go-back-n
behaviour.
Yes, Linux does indeed do more aggressive lost detection than what's in
the spec. I am fine with that.
Not a big deal. You have to wait the same 100 RTTs at start of each connection,
even though initial slow start _assumes_ that no congestion is present.
So, when you experienced real congestion, slow start is really fair. :-)
I am not sure what you mean here, slow start takes much faster to
transmit 100 pkts than 100 RTTs. Maybe there is a misunderstanding here,
when cwnd=1 in congestion recovery, it will stay at 1 until it exits
recovery unless some packet times out first.
Not less than 10% of loss. Maybe, more, but you were lucky and your
packets percolated through deadly congested router. :-)
It is basic assumption of cwnd avoidance: each loss is considered
as loss due to congestion.
Certainly. It's difficult to know what the right cwnd should be when this
happens, and a conservative approach may be the best one to take. I am
just curious if people can come up with better ways to set cwnd.
Cheng
I am not sure what you mean here, slow start takes much faster to
transmit 100 pkts than 100 RTTs. Maybe there is a misunderstanding here,
when cwnd=1 in congestion recovery, it will stay at 1 until it exits
recovery unless some packet times out first.
I see! Seems, you spotted a real problem. I missed this.
I feel we should add a trigger stopping such "fast" :-) restransmit
when cwnd falls low. Maybe, the same <cwnd/4 is good criterium.
I need to think, the situation is really weird.
Could you, please, prepare a demo pseudo-tcpdump with your simulator?
just curious if people can come up with better ways to set cwnd.
What would you like to see in the demo? Just the straight output from my
simulator?
Something which will allow to restore history to demonstrate
how it is possible to finish in recovery state with cwnd of 1
and lots of data in flight. I see that this is not impossible,
but simply cannot figure out when this madness happens.
Format does not matter. seq/(s)ack paires are good.
Alexey