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

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

The question arose on the DCCP mailing list
("http://www.ietf.org/mail-archive/working-groups/dccp/current/maillist.html")
of TFRC's response to a quiescent period, and whether it would be
OK to modify TFRC to allow a flow to resume its old sending rate after
an idle period.  This was judged to be a question that was not
appropriate for the dccp mailing list, so I am forwarding this
email to the tsvwg mailing list.  I am including the first
few paragraphs just for context - the part that is relevant for
the tsvwg mailing list is the digression that is below the 
dotted line...

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

------- Forwarded Message

Date:    Wed, 18 Dec 2002 14:56:25 -0800
From:    Sally Floyd <[email-masked]>
To:      Aaron Falk <[email-masked]>
cc:      [email-masked]
Subject: Re: [dccp] TFRC for app. limited flows 

>The only way I see this
>discussion to be in scope for dccp is if you could boil it into an API
.consideration, or such.

>Otherwise, I'd suggest discussions of TFRC to be taken to tsvwg or, if
>you're thinking of a not-yet-existing congestion control scheme, i.e.,
>"TFRC-like", try e2e-interest.  
...
>This
>working group will not be making changes to TFRC or developing any new
>congestion control schemes, for that matter.

All of that makes sense to me.

It probably *is* appropriate in the CCID documents to say more about
the applicability of each congestion control mechanism.  E.g., we
should probably add something to the CCID 3 document about the ways
that TFRC's response to quiescent periods might limit the applicability
of CCID 3 for some applications.

And it probably is also appropriate to discuss in some DCCP document
(I don't know which one) the needs/desires of applications that are
not met by any of the existing sanctioned congestion control
mechanisms.

At the same time, just because an application has a need/desire for a
certain behavior does not mean that that behavior should be
standardized for use in the Internet with best-effort traffic.

The research digression that properly belongs on another mailing list 
is below...

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

-------------------------------------------------------------------

And now for the research digression that belongs on another mailing list:

What are the pros and cons of allowing a flow to resume its
old sending rate after an idle period?  

We are not making any assumptions about the environment;  the
environment might be some overprovisioned North American or other
Northern hemisphere backbone, with the voice traffic being a miniscule
fraction of the overall bandwidth, or the environment might be a
congested 128kpbs link shared by many users.

The pros:

* Congestion can't be *too* bad, because the flow was able to
legitimately ramp up to the high sending rate it had achieved
*before* it went quiescent.

* If the flow is long-lived, and encounters congestion when it
resumes its old sending rate after an idle period, then it
will back off again like a well-behaved flow.  So the only
cost will be the short period of loss before it backs off.

* If the level of statistical multiplexing at the congested link(s)
is high, then a single flow is going to do limited damage when
resuming sending after an idle period.

* If the level of statistical multiplexing is low, then it takes
longer for the small number of other flows to ramp up to use the
bandwidth freed-up during the flow's idle period, so an individual
flow is going to do limited damage when resuming sending at its old
rate after a *short* idle period.

The cons:

There are two possible spaces here, one where the new traffic (i.e.,
the ON/OFF traffic with the new congestion control mechanism that
allows more aggressive behavior after idle periods) is in a partition
competing only with other new traffic, and one where the new traffic
might be competing with TCP or other traffic.  We need to consider
both cases.

* There is no reason to assume that bandwidth went unused during
the flow's idle period.  Probably other TCP, TCP-like, or TFRC flows
ramped up to use the available bandwidth, or other new flows came 
along and slow-started up to fill the space.  

* What is the effect on competing TCP traffic of the resumption of the
old sending rate after an idle period?  

When a flow starts up at its old rate after an idle period, and
causes several round-trip-times of congestion, this causes some of
the competing TCP traffic to seriously back off (more seriously
than the TFRC flows back off, that being the nature of TCP), leaving
the new flow free to use the bandwidth.  So the new ON/OFF flows end up
pushing out the TCP flows.

* What is the effect on competing new traffic? 
Imagine that all of the traffic is ON/OFF traffic with the new
congestion control mechanism.  Is the congested link fully utilized,
or do the losses from the sending at the beginning of the ON intervals
prevent the other ON/OFF flows from using the available bandwidth?
Aside from the utilization of the congested link, is the packet
drop rate acceptable, or is it unnecessarily high?  Would all of
the new traffic be receiving higher throughput, with lower loss
rates, if they reduced their sending rate at the beginning of each
new ON period, and slow-started up to their old sending rate?

Observations:

* One benefit of packets over circuits is that you get the
advantages of statistical multiplexing, and the higher
link utilization that can come with it.  But there are no
easy answers for the statistical multiplexing of ON/OFF traffic,
even with end-to-end congestion control.

* One cost of equation-based congestion control, with its more
moderate response to congestion (compared to TCP), has always 
been its more limited ability to quickly make use of 
newly-available bandwidth (again, compared to TCP).  Maybe
another cost of equation-based congestion control is a
responsibility to avoid unnecessary bursts of losses, such as
can be caused by simply resuming one's old rate after an idle
period.

* Even if it seems necessary for TFRC to continue to use a reduced
sending rate when starting up after an idle period (for best-effort
traffic), TFRC is still be able to quickly slow-start back up to
the old sending rate after an idle period.  This is similar to TCP's
Congestion Window Validation (RFC 2861), where TCP uses ssthresh
to save information about the previous value of the congestion, and
can slow-start back up to that value when coming back after an idle
period.  TFRC has a similar ability to slow-start after an idle
period, doubling its sending rate each RTT, up to the rate allowed
by the reported packet loss rate.

_______________________________________________
dccp IETF mailing list: [email-masked]
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html

------- End of Forwarded Message

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

---

From: "Andrei Gurtov" <[email-masked]>
Date: Tue, 31 Dec 2002 13:09:43 +0200

Sally-

Thanks for an extensive answer.

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.

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?

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.

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.

Thanks,
Andrei