W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

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

From: Dan Connolly <connolly@w3.org>
Date: Tue, 9 May 1995 16:18:48 +0500
Message-Id: <9505092018.AA03562@www16>
To: "Levine, David M." <DLEVINE@ssf4.jsc.nasa.gov>
Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
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)
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":


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

It was in a previous version of the spec:

The three parameters given by the client to the server are 

      The degradation (quality) factor between 0 and 1. If omitted,
	 1 is assumed. 
      The size of message (in bytes) which even if immediately available from
	 the server will cause the value to the reader to become zero 
      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

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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC