[Tsvwg] Re: RTT fairness

Sally Floyd <sallyfloyd@mac.com> Sun, 08 July 2007 20:50 UTC

Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7dhq-0000Ep-FN; Sun, 08 Jul 2007 16:50:10 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I7dhp-0000EF-BO for tsvwg-confirm+ok@megatron.ietf.org; Sun, 08 Jul 2007 16:50:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7dhp-0000Ds-1O for tsvwg@ietf.org; Sun, 08 Jul 2007 16:50:09 -0400
Received: from smtpout.mac.com ([17.250.248.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7dhk-0006eR-J8 for tsvwg@ietf.org; Sun, 08 Jul 2007 16:50:09 -0400
Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/smtpout04/MantshX 4.0) with ESMTP id l68KnhSt005915; Sun, 8 Jul 2007 13:49:43 -0700 (PDT)
Received: from [192.168.1.64] (adsl-70-132-1-225.dsl.snfc21.sbcglobal.net [70.132.1.225]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l68KnfLs026883; Sun, 8 Jul 2007 13:49:41 -0700 (PDT)
In-Reply-To: <E1I7b8n-0007Ot-TZ@palace.statslab.cam.ac.uk>
References: <E1I7b8n-0007Ot-TZ@palace.statslab.cam.ac.uk>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <c80bf8a6242f6445ff9c0a7b8a121ec8@mac.com>
Content-Transfer-Encoding: 7bit
From: Sally Floyd <sallyfloyd@mac.com>
Date: Sun, 08 Jul 2007 13:49:41 -0700
To: Frank Kelly <F.P.Kelly@statslab.cam.ac.uk>
X-Mailer: Apple Mail (2.624)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: tsvwg@ietf.org, mallman@icir.org
Subject: [Tsvwg] Re: RTT fairness
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Frank -

> A quick comment prompted by a paragraph in
> "Comments on the Usefulness of Simple Best-Effort Traffic"
> http://www.icir.org/floyd/papers/draft-floyd-tsvwg-besteffort-00b.txt
>
> The paragraph reads
> "RTT-fairness: What is the desired relationship between flow
> bandwidth and round-trip times, for best-effort traffic?  As shown in
> Section 3.3 of [FJ92], it would be straightforward to modify TCP's
> congestion control so that flows with similar packet drop rates
> but different round-trip times would receive roughly the same
> throughput."
>
> I don't think it would be that straightforward!
> There would be an impact on the stability or speed of convergence
> of the control loop: the modification in [FJ92] would, I think,
> lead to instability on routes where the ratio RTT/rate is large,
> or convergence that is slower than necessary on routes
> where the ratio is small. More detail on why I think this is in
> Section 5.1 of
> "Fairness and stability of end-to-end congestion control"
> http://www.statslab.cam.ac.uk/~frank/PAPERS/fse2ecc.html

Just to be clear, I think it would be a *terrible* idea to make
the change in Section 3.3 of [FJ92], towards long-RTT and
short-RTT flows trying to get the same throughput.  [FJ92]
*never* recommended the change - it just noted how one
would remove the RTT-bias if one wanted to.  It goes on to
say the following"

"There are many open questions concerning alternatives to the TCP
window modification algorithms. If the goal is for each connection
to increase its rate by c pkts/sec each second, how do we choose c?
What would be the impact of connections with large maximum windows
increasing their window much more rapidly than they do now?
...
And the ultimate difficult question: What is the meaning of fair?
At the moment, this section is intended only to suggest that the
current network bias in favor of connections with shorter roundtrip
times is a result of the TCP window increase algorithm, and not of
the performance of Random Drop or of Drop Tail gateways."

I have on my web page "http://www.icir.org/floyd/papers.html",
in the list of internet-drafts on my TODO list, a draft
entitled "Why RTT-Fairness would be Bad for Congestion Control",
along with an abstract, at
"http://www.icir.org/floyd/papers/draft-floyd-tmrg-rtt-fairness 
-00a.txt".

I might or might not ever make it to finish that draft, but if I do,
I will certainly add a pointer to your paper on
"Fairness and stability of end-to-end congestion control".

- Sally
http://www.icir.org/floyd/