- From: Kacheong Poon <Kacheong.Poon@Eng.Sun.COM>
- Date: Tue, 15 Dec 1998 18:54:26 -0800 (PST)
- To: Jim Gettys <jg@pa.dec.com>
- Cc: Henrik Frystyk Nielsen <frystyk@w3.org>, ietf-http-ng@w3.org
> 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
Received on Tuesday, 15 December 1998 21:57:55 UTC