- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 10 Aug 95 15:13:20 MDT
- To: Simon Spero <ses@tipper.oit.unc.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
The key point to note is that the vast bulk of data currently
transferred over HTTP has transport needs that don't correspond to the
features offered by TCP, and using strategies can greatly improve
performance and congestion characteristics.
One must be careful to distinguish between the desires of an
individual user and the needs of a network of 100 million users.
I would be quite cautious about doing anything that improves
perceived performance for a single user if that also destabilizes
the Internet (since all users ultimately suffer if the network
collapses).
For example, while it is true that inline images might be partially
rendered faster if the transport protocol doesn't try to preserve
ordering, except on very slow clients I can't imagine that latency
for full rendering of an image would be significantly improved by
out-of-order delivery.
And while it is possible to code images so that loss of a packet
does not make the image unreadable, this may conflict with the
goal of compressing images as much as possible. (I don't know,
I'm not an image-coding expert.)
Anyway, most of the inlined images I see are small enough that even
a single-packet loss is likely to make them pretty useless.
But mostly I'm concerned that we could micro-optimize the protocol
for rapid partial rendering of images in a lossy environment, and
in doing so fail to attack the principal reason for packet loss
in the (wired) Internet, which is congestion. I'd much rather
keep HTTP simple, and figure out how to make the best possible
use of our existing transport protocol.
As for real-time delivery of continuous media: I agree with Brian
Behlendorf, if when he writes "I do wonder if HTTP should be expected
to handle streaming, lossy media instead of some other protocol," he
means that HTTP should not be all things to all applications.
That is, we should think of HTTP as a way to move non-realtime objects
from place to place, and develop other mechanisms (such as the
work being done in the context of the MBone) for providing real-time
connectivity. The Web is great, but that doesn't mean it should be
coerced to do everything.
-Jeff
Received on Thursday, 10 August 1995 15:20:37 UTC