W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995


From: Paul Leach <paulle@microsoft.com>
Date: Thu, 10 Aug 95 14:36:27 PDT
Message-Id: <9508110350.AA18908@netmail2.microsoft.com>
To: http-wg-request%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

] From: Jeffrey Mogul  <mogul@pa.dec.com>
] To: Paul Leach
] Cc:  <netmail!http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
] Subject: UDP or TCP?
] Date: Thursday, August 10, 1995 9:59AM
]     Also, you can more than halve the size of the spec you need to
]     implement by just doing the the UDP version -- which, given that one of
]     the problems with HTTP that everyone talks about is the overhead
]     incurred from opening TCP connections for one-off transactions, seems
]     like a good direction to go.  (If the normal interaction between client
]     and server is idempotent, it will only take one round trip...)
] I think there's a misconception here.  Yes, there is some packet
] overhead for creating and destroying TCP connections, and the current
] one-request-per-connection model is expensive in that respect.
] 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.

] Since we're discussing what is already the dominant source of packets
] in the wide-area Internet, and will surely keep growing, we need to
] be very sensitive about how HTTP's design affects WAN congestion.
] Otherwise, nobody is going to be very happy.

Absolutely agree.
] One major benefit of a persistent-TCP-connection model is that it
] allows the packet sources to learn, over sufficiently long periods,
] what the congestion state of the network is, and therefore adapt
] to it.
] I should also point out that the average size of an HTTP retrieval
] is well over one packet's worth of data (I don't have the stats handy,
] but the number "8 K bytes" sticks in my head from someplace).  This
] means that even for a single request per connection, the congestion
] control mechanisms of TCP have some chance of being helpful.
] 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.  I assume that people know about the first 
three techniques. The last was suggested by Sidebottom's Rx protocol he 
did at CMU for AFS.  Serial numbers allow detection of exactly what is 
being acked -- an original packet or a retransmission thereof, and can 
avoid duplicate retransmissions on slow links.

The control of the sliding window is designed to allow the use of round 
trip time and effective link speed estimates. It is also designed to 
allow really simple implementations, like stop-and-wait. I don't know 
how much of the protocol capacity is exploited in any given 
implementation -- MS, OSF, and OSF members' "enhanced" versions.


Received on Thursday, 10 August 1995 20:08:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC