Subject: [Tsvwg] zero advertised window and congestion window validation (RFC 2861)

From: [email-masked]
Date: Tue, 26 Nov 2002 11:45:07 -0600

Hi,

I was trying to analyze what happens when a TCP sender receives a zero flow control window, and I realize that RFC 2861 (congestion window validation) is recommended only if the TCP sender is application limited, not when the sender receives an advertised window of size zero. I'm wondering if it will be useful to use RFC 2861 in this case also. Many TCP senders continue with the old congestion window size after they come out of the zero probe and this causes a lot of burstiness and packet loss if the receiver suddenly advertises a huge window. This hurts the throughput of the entire system (roughly between 6 - 15 % depending upon the AQM) even though the defaulting connection might have a slightly better performance.

In fact along the same lines, I was thinking why can't we use RFC 2861 as the congestion response after a spurious timeout. This scheme is conservative, adaptive (so if the packets were stalled for 10 days in the routers, the TCP sender would not revert the window like Eifel response algorithm does), and works in all cases *except* when a spurious timeout is caused due to change of subnets. Since neither Eifel response nor FRTO seems to be concerned about change of subnets, this RFC should suffice. Besides, the algorithm is already implemented in at least one of the widely used operating system.

Any thoughts?

--yogesh 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Mika Liljeberg <[email-masked]>
Date: 27 Nov 2002 00:45:15 +0200

Yogesh,

[Please enable line wrap]

> I was trying to analyze what happens when a TCP sender receives a zero flow control window, and I realize that RFC 2861 (congestion window validation) is recommended only if the TCP sender is appli…

This would seem to make sense. Pretty much the same rules would apply to
the sender in the application-limited receiver case:
- don't increase cwnd if limited by advertised window
- decay cwnd if nothing is happening

> In fact along the same lines, I was thinking why can't we use RFC 2861 as the congestion response after a spurious timeout. This scheme is conservative, adaptive (so if the packets were stalled for…

I'm not quite sure how you would apply this. RFC2861 talks about
application limited cases, while a spurious RTO is a network limited
case. Do you mean that if the RTO is determined to be spurious the cwnd
&& ssthresh would be restored to some manner of decayed values rather
than the original values?

	MikaL