The protocol seems to have a couple of big new twists:
o ALF - application-level framing of web data (ex: you can use whatever
data you have received, even if it's out of order, or packetize data
smarter)
o it's totally receiver-driven, which means the servers have little state,
all of it soft, which should make failure-recovery and failover easier,
and perhaps make servers a little faster
o it has a hybrid window-based and rate-based congestion control scheme
with explicit rate messages, which should smooth out the needless
burstiness of TCP
The protocol and/or paper seemed to have some shortcomings:
- there is no mention of how data is transferred reliable and in a
congestion-controlled manner from client to server (for form data, for
instance)
- eliminating the three-way handshake seems to leave WebTP open to easy
denial-of-service attacks: you could easily make up requests for huge
amounts of data to be sent to imaginary IP addresses at the highest
possible rate, and the server would never know the difference, since it
doesn't ever wait for ACKs or any other sort of confirmation that the
data is being received by a willing client.
- because of this, the server will need to keep state to police the rate
at which it queues and sends data, and may want to ensure somehow that
it is sending to real clients who really want the data.
- their congestion control scheme is similar to, but mostly way more
aggressive than, TCP's:
- the WebTP slow-start scheme is exponential growth with a factor of 2,
which is more aggressive than today's factor of 1.5 (due to delayed ACKs)
- their slow-start sends in bursts, without rate-based smoothing, just
like TCP today
- their slow-start uses timeouts just like TCP's
- only *after* the first loss do the smarter WebTP rate-based sending
and retransmission scheme kick in; and given the size of web transfers
today, that means that the fancy WebTP stuff will often not kick in at
all.
- the real shocker: (I'm sure this will send Van ballastic, and shocked
that McCanne OKed this, if i'm understanding it correctly) - when WebTP
detects a loss from 3 out-of-order packets, instead of cutting the
congestion window in half as TCP does, they leave the congestion window &
rate as-is!!!
- loss indications are the only congestion signals - no packet-pair or
Vegas or anything
- their congestion-avoidance phase ramps up at a single universal rate,
regardless of RTT, which will lead to flows with big RTTs having lots of
data in flight (data proportional to RTT, i think) before they get any
sort of congestion signal
- their paper has simulations, but the flows are all a few 60-second
elephants, which is an important part of the space, but by no means
representative of the zillion-mice workloads it would be used for; i don't
recall a mention of the expected length of flows or simulations of shorter
flows.
- in general, there is no quantified win for WebTP yet; so far they just
have some simulations that demonstrate that it isn't harmful, for long
flows.
Some questions (some old) i think this paper raises:
o What *are* the performance problems in the web today, anyway? How could
they be helped with a new protocol? Are they such that moving the burden
of transport-layer processing to the client and using ALF and rate-based
sending will fix them?
o They have a sentence in there about reusing congestion control info
across requests, but have no algorithm. How is this best done?
o To what extent can GIF/JPEG/PNG exploit ALF?
Anyone else get a chance to check out the WebTP stuff?
neal
PS: I'm finally back in Seattle, & my Dad's OK.
On Fri, 9 Oct 1998, Neal Cardwell wrote:
>
> McCanne & folks have a paper out on a new transport protocol designed from
> scratch for the web:
> http://www.path.berkeley.edu/~guptar/webtp/
>
> their Infocom 99 Submission:
> http://www.path.berkeley.edu/~guptar/webtp/reports/infocom.ps
>
> ---------- Forwarded message ----------
> Date: Fri, 09 Oct 1998 13:59:48 -0700
> From: Matthew Siler <siler@CS.Berkeley.EDU>
> To: net-seminar@EECS.Berkeley.EDU,
> dspseminar@EECS.Berkeley.EDU
> Subject: Seminar: WebTP
>
> ********
> Please Note: This seminar will be held on Thursday instead of Tuesday at
> the regular time.
> ********
>
> WebTP: A Receiver-Driven User-Centric Transport Protocol for the Web
>
> Networking, Communications, and DSP Seminar
> http://www-networking.eecs.berkeley.edu/Networking/Seminar
>
> Rajarshi Gupta
> University of California, Berkeley
>
> Thursday, October 15, 1998
> Hughes Room
> 3:30-4:30 p.m.
>
> Abstract:
>
> The use of TCP for the Web has caused a variety of performance problems
> because the interactive request/response nature of Web traffic is
> incongruent with the sequenced, bi-directional, continuous, byte-stream
> model of TCP. We believe that these problems can be overcome by
> abandoning
> the constraints imposed by TCP and designing a new receiver-oriented
> transport protocol for the Web that leverages the concept of Application
> Level Framing (ALF). In this report, we present a receiver-oriented,
> request/response protocol for the Web that is amenable to ALF and
> compatible with the dynamics of TCP's congestion control algorithm.
>
> The resulting protocol - WebTP - is designed to be completely
> receiver-based in terms of transport initiation, flow-control and
> congestion-control. In support of our receiver-driven design, we
> developed
> a novel retransmission scheme that is robust to delay variations and can
> operate without an explicit ``ack clock''. The resulting flows achieve
> efficient network utilization and are qualitatively fair in their
> interaction amongst themselves and even with competing TCP flows. The
> report also provides detailed simulation results to support the protocol
> design.
>
> We optimize the transport of a document from the sender to the receiver
> by
> taking into account a number of different factors like the contents of
> the
> page, the state of the network, the available hardware at the client and
> even the preferences of the user. We set up schemes to represent all of
> the above information, and design a system to implement the optimization
> structure. The computationally feasible methodology adopted at the
> receiver allows it to determine an optimal order of transport for the
> objects contained in the document. The resulting transfer is optimized
> with respect to suitable utility functions and yield maximum
> satisfaction
> to the user.
>
>