WebTP is a project envisioned ... to take on the problems of the current
world wide web and formulate a comprehensive protocol for the next
generation of the internet. The primary purpose of this protocl is to bring
the User into the transaction loop, and to optimize any web transfer to
ensure maximum satisfaction for the user.
The project embodies four primary design goals:
User-Centric Optimization
Application Level Framing
Session-oriented Congestion Management
Receiver-Driven
Hmm, "a comprehensive protocol for the next generation of the internet."
Pretty ambitious I'd say. But what, exactly, do they mean by all of this?
Looking at their meetings page,
<http://webtp.eecs.berkeley.edu/meetings/index.html>, I see meetings on "TCP
and its relations to WebTP", "Packet Classifiers", "Recent progress on WebTP
transport framework design", "Some characteristics of the WebTP transport
protocol", "Congestion Manager", "Pipe Management at edge router", and "TCP
Bandwidth Measurement". This indicates that the group is focused well below
L7, and does not appear to be on the path of a *TP (you can rest easy, Rohit
:-)
There is a list of publications, two graduate project reports and a Master's
thesis, at: <http://webtp.eecs.berkeley.edu/publications/index.html>. The
project report, "WebTP: A User-centric Network Infrastructure Optimized for
Web Browsing" by Hoi-Sheung Wilson So gives some overview on WebTP goals:
"Web browsers are usually very responsive, but sometimes, after clicking on
the link, you wait and wait, the logo animation keep juggling, but nothing
happens. You finally give up, and hit the stop button. And suddenly, you
see a partially loaded HTML page with some broken pictures in them.
Obviously, the browser was getting stuck loading some huge picture over a
slow link. Why should the browser start loading pictures before finishing
the HTML file? Have you ever hoped that the browser would ask you your
preferences in choosing what to download first?
Given a limited amount of imperfect bandwidth, how can we make web browsing
as responsive to user needs as possible? Ideally, we want to find out the
user’s expected utility of each object. Depending on the utilities of
different objects, the browser can allocate available bandwidth among them
to achieve maximum user satisfaction."
He goes on to note problems with HTTP and TCP:
3.1 HTTP/TCP Incompatibilities with Utility-based Model
"First, neither HTTP [F+96] nor TCP provides a way to specify bandwidth
allocation between multiple connections. Second, TCP [Jac88] hides all the
flow control mechanisms from upper layers. Without network state information
such as round-trip time and available bandwidth, upper-layer applications or
protocols cannot easily implement their own bandwidth allocation algorithm.
Third, sender-driven systems such as TCP is less responsive to user needs
because the user is on the receiver side. Any changes in user needs must
first propagate to the sender-side over the network before it can have any
effects on the network protocol operations."
In its Design Overview section, the paper states:
"The goal of the project is to build a framework which allows applications
to allocate network resources to achieve maximum utility for the user.
Building such a framework requires designing and implementing at least four
components:
1. An ADU naming scheme which has enough expressive power to name the ADUs
of various data formats used in web pages, such as JPEG, GIFs, HTML, WAV
etc, so that each ADU can be processed independently of each other.
2. An object request protocol that understands this ADU naming scheme, and
provides a mechanism to allocate bandwidth based on the utility of the ADU.
3. A transport protocol that allows the object request protocol to have
control over the bandwidth allocated to each object transfer.
4. A browser that understands user preferences and can translate preferences
into the transport priorities of ADUs. (Strictly speaking, the browser is
not part of the infrastructure, but there is no way to verify the usefulness
of the infrastructure other than building a browser.)"
My initial quick take is that the problem addressed by the project is real
enough, web pages do sometimes take too long to download, especially over
slow connections. But, there are many approaches for addressing this
problem, and it strikes me that diving deep into the protocol stack is among
the more complex of them. If images are the real problem, as this paper
seems to imply, then techniques for selecting types of images to not load
(i.e., banner ads) ever again might be more simple than this scheme. Plus,
as the amount of available bandwidth increases, latency, and origin server
architecture, more than bandwidth, will be the real culprit for slow-loading
pages. Anymore, most sites that load slowly for me, even over a modem, have
some kind of dynamic content, and it is the generation of that content which
is slow. For non-dynamic content, replication and caching to bring the data
closer to the requester seems more simple, and more likely to show results
sooner. ("How 'bout them Akami's" :-)
- Jim