- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 11 Aug 95 11:44:34 MDT
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, mogul@pa.dec.com
] But simply going to UDP is not the answer, because UDP (without
] some extra effort) does not offer any congestion-control mechanisms.
] Sure, you can layer them on top of UDP, but I suspect that you would
] quickly get back to something very similar to TCP.
All RPCs I know of do the extra flow control thing. For RPC, it is
very simple in the basic request/response case, as request/response
is naturally flow controlled -- this is why you don't quickly get
back to TCP for simple cases. When the in or out arguments are
large, then you do indeed have essentially the same problem as
TCP.
Flow control is not congestion control.
] Paul, what does DCE RPC do for congestion avoidance and control
] in WANs, when it uses UDP?
The protocol is designed to use slow start, sliding window, ack
maps, and serial numbered packets.
Slow start (depending on exactly how it is done) will help with
congestion. It may not be a full solution.
I don't know how much of the protocol capacity is
exploited in any given implementation -- MS, OSF, and OSF members'
"enhanced" versions.
If congestion control is not a mandatory part of the implementation,
present in all cases, it would be unwise to deploy this as the basis
for the Web.
-Jeff
Received on Friday, 11 August 1995 12:28:58 UTC