MRC@SIMTEL20.ARPA (Mark Crispin) (11/02/86)
John, this is all well and good, but under the present system there is a slight reward given to anti-social sites which blat out retransmissions too quickly. The sites which do not have excessively short RTT's find themselves jammed out from access to the gateways. Perhaps what we need to do is make the gateways be a little smarter than just packet forwarders (yes, my gateway-building friends, I know that I am being excessively simplistic, but hear me out). Perhaps a gateway should know enough about TCP to be able to detect retransmissions of packets already in their queues and toss them out. -------
steve@BRL.ARPA (Stephen Wolff) (11/03/86)
Umm. There are even now other things than TCP lurking within those innocent IP wrappers, and their number will increase as various children of the ISO family are adopted. Should the gateway know them all? -s
jcp@BRL.ARPA (Joe Pistritto, JHU|mike) (11/03/86)
No, it is clearly inappropriate for Gateways to assume that TCP is being transmitted, or to have knowledge of everything in them. However, (and I agree that this greatly complicates building gateways), I think the gateways SHOULD have some knowledge of what the 'real' bandwidth available into another gateway (and hopefully beyond that gateway to the final destination) is, and try actively not to exceed it. It seems that ICMP source quenches when appropriate would greatly alleviate the problem. (assuming of course that all implementations reacted intelligently to a source quench....) -jcp-
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (11/04/86)
Date: Sun, 2 Nov 86 16:20:09 EST
From: Stephen Wolff <steve@BRL.ARPA>
Umm. There are even now other things than TCP lurking within those
innocent IP wrappers, and their number will increase as various children
of the ISO family are adopted. Should the gateway know them all? -s
As much as possible: Yes. This strategy helped tremendously with
another network protocol (Chaos) which has a .5 second retransmit
timeout when used over slow (9600 baud) land lines. It actually did
more than that: it understood enouch of Chaos to limit the number of
packets per connection. This problem was slightly alleviated by
changing out Chaos implementation to retransmit only the first packet on
the queue, which I think is common lore for all protocol implementations
now-a-days.steve@BRL.ARPA (Stephen Wolff) (11/04/86)
>> Should the gateway know them all? > As much as possible: Yes. I think you're saying the layering's done wrong.
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (11/07/86)
Date: Tue, 4 Nov 86 13:38:58 EST
From: Stephen Wolff <steve@BRL.ARPA>
>> Should the gateway know them all?
> As much as possible: Yes.
I think you're saying the layering's done wrong.
I can't answer that without a counter-proposal for a different layering.jbn@GLACIER.STANFORD.EDU (John B. Nagle) (11/08/86)
> Should the gateway know them (transport protocols) all?
I gave some serious thought to this approach back in 1984, and went
so far as to start writing a TCP segment consolidator for a gateway.
But the complexity of such a thing is comparable to the receive side
of a TCP implementation, and the possibility exists of introducing a class of
bug for which the assignment of blame would be very difficult.
It was after discarding this line of attack that I came up with
"fair queuing", as described in RFC970. The key idea there is that
gateways should have queuing strategies that favor well-behaved hosts
over badly-behaved ones, rather than the reverse, so that it is in the
self-interest of hosts to be well-behaved. This was a radical idea when
I first proposed it, but gradually the community seems to be coming around
to the point of view that non-FIFO queuing strategies in gateways are
desirable.
Now that we know how to throttle TCP connections effectively over
a speed range of three or four orders of magnitude, and now that 4.3BSD
and some other implementations have the machinery to do this correctly,
we should be able to make the whole Internet run smoothly over a wide
range of loading conditions. With smarter algorithms in the gateway
to control the throttling and to prevent ill-behaved hosts from
using up most of the resources, it should be possible to stop the
present abysmal behavior of the Internet under heavy load.
I hate to say "I told you so", but I did predict the congestion
collapse of the Internet in my article in ACM Computer Communications
Review in October 1983. From the reports I read here, it has happened.
I've proposed ways to deal with the problem, and those that have been
tried have worked. There's been some "not invented here" grousing,
but no one has shown that my approaches are invalid. There may indeed
be more elegant solutions to some of these problems. (Lixia Zhang
at MIT is working on some). But unless someone has a better idea that
will stand scrutiny by the community, I suggest that somebody put
fair queuing in a few key gateways and see if things get better.
The description of the algorithm in RFC970 is a bit sketchy, so if
you want to implement it and are a bit confused, please feel free to get
in touch with me and I will try to be of assistance.
John Nagle