Re: Some clarifications

From: Jim Gettys (jg@pa.dec.com)
Date: Tue, Dec 15 1998


Date: Tue, 15 Dec 1998 09:40:51 -0800
From: jg@pa.dec.com (Jim Gettys)
Message-Id: <9812151740.AA06021@pachyderm.pa.dec.com>
To: Kacheong Poon <Kacheong.Poon@eng.sun.com>
Cc: Jim Gettys <jg@pa.dec.com>, Henrik Frystyk Nielsen <frystyk@w3.org>, ietf-http-ng@w3.org
Subject: Re: Some clarifications



> From: Kacheong Poon <Kacheong.Poon@eng.sun.com>
> Date: Mon, 14 Dec 1998 19:29:52 -0800 (PST)
> To: Jim Gettys <jg@pa.dec.com>
> Cc: Henrik Frystyk Nielsen <frystyk@w3.org>, ietf-http-ng@w3.org
> Subject: Re: Some clarifications
> -----
> > We plan to write up a note to circulate what problems we have using
> > TCP and the problems we have with the current socket interface.
> 
> Please do so.  The worry I have is how an application is going to use
> those info.  An app can use it wisely while another app may abuse it.
> An app may choose to open another connection to speed up a transfer
> when it sees RTO going up (which implies retransmissions), not knowing
> that this may cause more congestion.  But in some cases, this allows
> the app to get a larger share of bandwidth, as in HTTP 1.0.

Hiding the information doesn't mean they won't abuse the priviledge in
any case.  This worry is specious, in my view.

It is not clear that in fact they get more bandwidth in practice; multiple 
connections did allow them to at least keep a modem line busier.
In our experience, we're able to get higher performance over a single
connection than exisiting implementations have gotten over 4 connections
(see our SIGCOMM paper, and more recent tests we need to go into further
has our Amaya browser beating IE and Netscape over a single connection).



> 
> In writing such a document, please include a somewhat detailed analysis
> of how the extra info will be used and what benefits they can bring to
> an app.
> 

Of course...
				- Jim