nanog mailing list archives

Re: MTU of the Internet?


From: Marc Slemko <marcs () znep com>
Date: Mon, 9 Feb 1998 08:19:31 -0700 (MST)

On Mon, 9 Feb 1998, Phil Howard wrote:

Patrick McManus writes:

At the risk of introducing meaningful background literature:
     ftp://ds.internic.net/rfc/rfc2068.txt

I direct folks to 14.36.1 "Byte Ranges" which when interleaved with
pipelined requests comes very close to achieving client-driven
multiplexing that I'd suggest from a UI pov will behave much better
than the multiple connections method (eliminating the cost of tcp
congestion control but at the cost of some application protocol
overhead). 

As a server implementor, let me simply say this makes no sense and is a
perversion of what byte ranges are intended for.  You will end
up repeating the request headers (which can be sizable) far too often,
will put far too much load on the server, will break whenever you
get dynamic content, etc.


More than application overhead, I suspect the biggest problem with this
otherwise good idea is that it won't be implemented corrently by the
browsers or the servers.

For example on the server end, it would see multiple requests for the
same object, at different byte ranges.  If that object is being created
on the fly by a program process (e.g. CGI) the browser won't have a
clue of the size.

What is the correct behaviour of the server if the request is made for
bytes 0-2047 of an object which invokes a CGI program to create that
object?  Obviously it can send the first 2048 bytes, but then what?

For dynamic content, it normally has to send the whole document.  That
is a legal response to a byte range request.



Current thread: