Curtis,
Hi. Thanks for your thoughts and comments. To continue the
dialogue a bit:
>Source quench is currently sent by some routers but universally
>ignored. I don't know that there are any exceptions.
I believe that I just verified that it is recognized and reacted
to in both FreeBSD and NetBSD. I haven't had a chance to check
anything else yet.
> This is because
>early routers sent source quench far too often and the use of source
>quench is now strongly discouraged.
The point of only sending it as a result of RED, and then only in
the probabilistic marking phase is to specifically control the rate at
which source quenches are sent, and to ensure that they are sent to
the "right" sources. Once the router crosses into the "mark every
packet" part of RED I suspect that packet discard is the more
appropriate course of action.
>
>Sending one source quench per second would have no affect at all on
>typical Internet traffic which has hundreds to hundreds of thousands
>of TCP flows. In congested multiple bottleneck situations with lots
>of flows, sending more traffic (source quench) has been proven to be a
>bad idea. Links that are congested with a very high contribution from
>small duration flows can need 5-15% loss. This would mean you'd need
>to add 5-15% more packets (small ones) to get the equivalent slow down.
>
>You can't propose something that will help the lossy wireless and
>satellite cases and break the rest of the Internet. (Actually you can
>propose anything, you just can't expect the proposal to get anywhere).
Clearly it's not our intent to "break the rest of the Internet."
The intention of TCP's congestion control and RED are to improve
fairness of access to the Internet. I recall seeing a paper describing
the results of some satellite testing in the June issue of Transactions
on Networking (T. V. Lakshaman & U. Madhow) that accurately described
TCP's response to the combined effects of loss and latency on satellite
users as "grossly unfair toward connections with higher round trip delays."
This already-existing unfairness is what we are trying to repair before
people decide that TCP is inherently unsuitable for satellite use (and
they replace it with solutions that are not congestion-control friendly).
The fact is that a (geo)satellite user can only increase its congestion
window at 2 MSS per second, and may have a large bandwidth-delay product.
As such, it will be significantly more adversely affected by loss than a
terrestrial user with a similar bandwidth-delay product. We are
looking for ways to avoid congestion without incurring loss and to
shorten the duration of a congestion event. We hope that some
near-side feedback, such as a source quench, will allow us to reduce
a large flow's rate of transmission before sending the router into
a state where it must discard packets. (Note that if the satellite
end system receives a source quench from a near-side router, it will
respond a full half-second earlier than if it has to wait for an ECN
bit to propagate and be responded to or for dup acks to be returned.)
>
>When Sally Floyd put out the TCP-ECN paper in 1994, the source quench
>idea was soundly rejected but there has been interest in the ECN part
>as a means to suppliment loss as a congestion indication, not replace
>it.
>
>The idea of an "experiencing loss" bit where loss should be ignored is
>also dangerous if you assume that some routers will be congestion bit
>aware and some still use drop as the means to indicate congestion.
>Such a scheme would face serious obstacles in being deployed.
Our point was that the experiencing loss signal should be explicit about
what type of loss is being experienced. If there's ambiguity, one assumes
congestion. (Assuming that we're not talking about a closed environment
in which there's knowledge of what the signaling and response capabilities
in the network are.)
Clearly, any kind of transition in a system as diverse as the Internet is
difficult to accomplish. However, its diversity is increasing with the
increased use of satellite and wireless resources. I believe that it
is important to improve the service that can be provided to these users,
and that it is equally important not to degrade the service the existing
users experience. We are working to accomplish that, and appreciate whatever
you can do to help us in that regard.
Thanks,
Bob Durst
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:31 EST