Subject: [Tsvwg] Re: TRFC's response to application-limited flows

From: Sally Floyd <[email-masked]>
Date: Thu, 19 Dec 2002 09:54:42 -0800

I have made two changes to the TFRC implementation in the NS
simulator to improve its performance with application-limited flows.
For those interested, the log message is at
"http://www.isi.edu/cgi-bin/nsnam/cvsweb/ns-2/tcp/tfrc.cc".

In the TFRC sender, when a timer expires saying that no status
report has been received from the receiver, the old code always
halved the allowed sending rate.  The new code only halves the
allowed sending rate when a packet had been sent within the most
recent two round-trip times, or when the current rate was greater
than four pkts per RTT.  Thus, in the new code, then the timer
expires because no packets had been sent by the sender, the allowed
sending rate is not reduced below two packets per RTT.  This gives
a response to a quiescent period that is similar to that of TCP
in RFC 2861.

This use of a lower bound is not mentioned in the TFRC spec,
so this requires further investigation and documentation.

- Sally
http://www.icir.org/floyd/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Sally Floyd <[email-masked]>
Date: Tue, 31 Dec 2002 16:52:29 -0800

Andrei -

>Aren't we allowed to speak about fairness on the timescales larger than one
>RTT? Say, if a person X wasn't using the net for some time and the person Y
>is downloading a Linux DVD image, isn't it "fair" if X's flows push Y's
>flows aside for a while? In this view it should be ok for ON/OFF sources to
>downgrade concurrent TCP sources during their ON times. TCP flows could
>catch up then ON/OFF flows are in the OFF state.

But that implicitly assumes that all of the competing TCP flows are 
long-lived bulk-data transfers that only care about the overall transfer
time.  This is not necessarily correct.  For example, some of the TCP
traffic is carrying streaming media that would prefer not to be "pushed
aside" because some ON/OFF flow wants the bandwidth.

>The scenario when there are no concurrent TCP flows to push aside looks
>worrisome because it can create heavy transient congestion when several
>ON/OFF flows wake up simultaneously. Although, is it realistic with
>currently ~95% of all traffic being TCP?

Well, if a protocol was only safe to deploy when less than 5% of the
traffic on the congested link was using that protocol, then, in my
opinion, you would want some mechanism to *ensure* that this condition
held on all of the congested links along the path before deploying
this protocol.

>Shouldn't IETF (or IRTF?) consider longer term fairness in transport
>protocols?
>This is purely speculative since no tests have been run yet, but one example
>could be changing AIMD constants in TCP congestion control as the cumulative
>amount of transferred data by the connection increases. Hence, long-lived
>connections would become more conservative. It then would be ok to allow
>application-limited and short-lived transaction flows to be more aggressive
>without causing a heavy transient congestion.

My own opinion would be that it doesn't work to give flows "credit" 
for times when they didn't use all of the bandwidth available to them.
But even if one was to propose this, I think you still would have to
explore the performance when all of the flows on the congested link
were ON/OFF.  I don't think this is an implausible scenario -
consider, for example, the access link to a server serving some form
of ON/OFF traffic.

>The biggest concern of such modifications is probably a chance of their
>misuse. However, given that they're implemented at the transport layer in
>the OS kernel, it doesn't look like it would anyhow weaken the current
>situation. People are anyway free to tweak their TCP code to behave more
>aggressively or simply use UDP.

Yep.  But just because people can do anything they like, does not mean
that we have to standardize it in the IETF.

- Sally

I have added a validation test to NS, "./test-all-quiescent" in the
directory "tcl/test", that explores the behavior of TCP and TFRC with
ON/OFF applications, and with applications that change their
rate of generating data, so that some times the TCP/TFRC connection is
application-limited.

In the process ("http://www.isi.edu/nsnam/ns/CHANGES.html"), I added
a "partial_ack_" parameter to Sack TCP, for better performance for
Sack TCP with partial acks during Fast Recovery, as suggested in a
paper of yours and Reiner's, and fixed a bug in the "QOption_"
option with Sack TCP, for responding to a quiescent period by
lowering the congestion window.

I also (on 12/18, "http://www.isi.edu/nsnam/ns/CHANGES.html") fixed
the TFRC code so that it performs better with data-limited applications,
sending a packet immediately when TFRC has been data-limited and
suddenly a new packet becomes available from the application.   (The
old TFRC code in NS didn't do this.) This can dramatically improve
the performance of TFRC with data-limited applications.