Whither mxs? [was: Possible New Optional Field in Header?]

David M. Levine writes:
 >I'd like a field (called
 > perhaps "XferRate") which would list the speed (in bytes
 > per second) that the browser claims it is receiving
 > data at.
 > ...
 > Has this been brought up before? 

Yes. It was one of the original design issues of the web:

About document formats (Design Issues)
http://www.w3.org/hypertext/WWW/DesignIssues/Formats.html#4
Thu Jan 14 10:22:26 1993

|3. Negotiation
|
|For every format, there must be a set of other possible formats which
|the server can convert it into, and the most desirable format is
|selected by negotiation between the two parties. The negotiation must
|take into account:
|
|      the expected translation time, including current load factors 
|      the expected data degradation 
|      the expected transmission time (?!!) 
|
|The times one could assume will be roughly proportional to the length
|of the document, or at least linear in it.

(I'm sure the 1993 date is an artifact of copying the document
across disks or something. This stuff was written in 1989 or 1990).

This shows up in the current spec under "Content Negociation":

http://www.w3.org/hypertext/WWW/Protocols/HTTP1.0/HTTP1.0-ID_38.html#HEADING112

Ack! No it doesn't! What happened to the "mxb" parameter?


It was in a previous version of the spec:
http://www.w3.org/hypertext/WWW/Protocols/HTTP/Negotiation.html

=================
The three parameters given by the client to the server are 

q 
      The degradation (quality) factor between 0 and 1. If omitted,
	 1 is assumed. 
mxb 
      The size of message (in bytes) which even if immediately available from
	 the server will cause the value to the reader to become zero 
mxs 
      The delay (in seconds) which, even for a very small message with
	no length-related penalty, will cause the value to the reader
	to become zero.

These parameters are chosen in part because they are easy to visualize
as the largest tolerable delay and size. If not sent, they default to
infinity.

The server may optimize the presented value for the user when deciding
what to return. The hope is that fine decisions will not have to be
made, as in most cases the results for different formats will be very
different, and there will be a clear winner.

A suitable algorithm is that the assumed value v of a document of
initial value u delivered to the network after a delay t whose
transfer length on the net is b bytes is

v = u * q - b/mxb - t/mxs
=================


 > I am new to this group, but checked the archives
 > of the mailing list to see if this has been brought
 > up before.  Obviously, I have not yet read everything,
 > but I so far have not found a similar suggestion yet.

Sigh... we need to make it much easier to navigate and search the
archives.

Dan

Received on Tuesday, 9 May 1995 13:30:13 UTC