Re: Some clarifications

From: Kacheong Poon (Kacheong.Poon@Eng.Sun.COM)
Date: Tue, Dec 15 1998


Date: Tue, 15 Dec 1998 18:54:26 -0800 (PST)
From: Kacheong Poon <Kacheong.Poon@Eng.Sun.COM>
To: Jim Gettys <jg@pa.dec.com>
Cc: Henrik Frystyk Nielsen <frystyk@w3.org>, ietf-http-ng@w3.org
Message-ID: <Roam.SIMCSD.2.0.4.913776866.31488.kcpoon@jurassic>
Subject: Re: Some clarifications

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

No, I am not against letting applications know more about the connection
state.  But I want to point out that this can also give "bad" apps more
info to abuse the network in ways that are more detrimental than they
are doing today.

> 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).

The results in your paper may not apply here.  Firstly, I think we are
talking about a general mux over TCP, not HTTP specific.  So the pipelining
and compression techniques may not be applied because the mux does not know
about the application's transfer behavior so it cannot tune its behavior. 
Suppose the app knows about the mux, it also may not be able to tune its
transfer behavior to fit the model.  Not all apps are like HTTP.

Secondly, probably the only test case in your paper which may show the
unfairness of multiple TCP streams is the high bandwidth/high latency test.
The reason is that this is the case where those connections pass through
links which are shared by other network traffic.  In this case, to show
that using more connections do not let an app get more bandwidth, you need
to compare HTTP 1.0 results using, say 2 and 4, connections.  Showing
HTTP 1.1 is better just tells us that HTTP 1.1 is better than 1.0.  It
does not really tell us about performance implication of multiple TCP
connections.

As I mentioned in my previous mail, a long train (I also imply larger window
here) of packets helps in recovering packet loss.  If HTTP 1.0's transfer
size is small in your tests, a packet loss may cause a timeout.  This can have
a big effect on the results.  So for a general mux, we need to know the
transfer size of an app before we can do any comparison.  Your results may
apply if the app we are talking about has similar transfer size as HTTP 1.0. 

OTOH, a few studies have shown that an app using multiple connections
gets an unfair advantage over an app using single connection.  This has to
do with how the congestion window is increased and how TCP reacts to packet
loss.  Using multiple connections is more aggressive in both cases.  Note
that this does not imply that the app will get better throughput.  It may
or may not, depending on the network condition.  That is why I mentioned
above that if a "bad" app knows more about the network condition, it may be
able to abuse the network in a smarter way.

							K. Poon.
							kcpoon@eng.sun.com