backbone routers' priority settings for ICMP & UDP

Mailman List Mirror (Read Only)
1

Marc, I'd have to agree, ICMP is more for flow control than congestion
control. A source quench is to slow a fast machine from overrunning a slow
machine, not preventing all flows from going through one link.

One (weak) metaphor is that traffic lights at an intersection are for flow
control, while the traffic lights to get onto the freeway (common here in
California) are for congestion control...

Extremely weak metaphore, since a source quench indicates there weren't
enough buffers available to send your packets.

Now, if the freeway was full, and cars started dropping out of the space/time
continuum, that'd be more like a source quench. :wink: The freeway would call
your wife at home and say "sorry, but your husband didn't make it to work
because the freeways were too full." If wife runs correct a correct
TCP implementation, she would know to initiate "slow start" and would
send out her husbands at a slower rate until she gets a feel for how
bad the traffic is.

One then
wonders how well Win95 implements source quench, if at all.

Which side of the implementation do you mean? as a client, or as a gateway?
I suppose it doesn't really matter. Since source quenches are not supposed
to be used on routers anymore, the expectation of receiving a source
quench on a large network (like the Internet) is a bad one, so the TCP
implementations have to implement congestion controls through other means
anyhow.

TCP/IP Illus. Vol. I by W. Richard Stevens has a pretty good explanation
of what source quenches are.

Dave

2

Extremely weak metaphore, since a source quench indicates there weren't
enough buffers available to send your packets.

Now, if the freeway was full, and cars started dropping out of the space/time
continuum, that'd be more like a source quench. :wink: The freeway would call
your wife at home and say "sorry, but your husband didn't make it to work
because the freeways were too full." If wife runs correct a correct
TCP implementation, she would know to initiate "slow start" and would
send out her husbands at a slower rate until she gets a feel for how
bad the traffic is.

ROFL, nice extension. But this is not true because, as you say below,
gateways don't source quench anyore.

> One then
> wonders how well Win95 implements source quench, if at all.

Which side of the implementation do you mean? as a client, or as a gateway?
I suppose it doesn't really matter. Since source quenches are not supposed
to be used on routers anymore, the expectation of receiving a source
quench on a large network (like the Internet) is a bad one, so the TCP
implementations have to implement congestion controls through other means
anyhow.

As a client, of course, since end-to-end source quench is the only
alternative available. And consider the near future scenario where a user
with a cable-modem connected via Ethernet to their nice new NC (with
cheapest bus design possible to contain costs) has requested a URL from a
<insert whomping fast server here> connected via OC-3 to the Internet. It
seems likely a source quench will come in handy to provide flow control.

TCP/IP Illus. Vol. I by W. Richard Stevens has a pretty good explanation
of what source quenches are.

Don't have Mr. Stevens handy, but from RFC777 (1981!), when both types of
source quench were defined:

...A destination host may also send a source quench message if datagrams
arrive too fast to be processed. The source quench message is a request
to the host to cut back the rate at which it is sending traffic to the
internet destination.

This is what I was getting at. Flow control versus congestion control.