SCTP Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@xxxxxxxxx On Wed, Feb 4, 2015 at 2:22 PM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: > Today most Web browsers attempt to optimize download of images etc. by > opening multiple TCP/IP streams at the same time. This is actually done for > two reasons, first to reduce load times and second to allow the browser to > optimize page layout by getting image sizes etc up front. > > This approach first appeared round about 1994. I am not sure whether anyone > actually did a study to see if multiple TCP/IP streams are faster than one > but the approach has certainly stuck. > > But looking at the problem from the perspective of the network it is really > hard to see why setting up five TCP/IP streams between the same endpoints > should provide any more bandwidth than one. If the narrow waist is observed, > then the only parts of the Internet that are taking note of the TCP part of > the packet are the end points. So having five streams should not provide any > more bandwidth than one unless the bandwidth bottleneck was at one or other > endpoint. > > Now there are some parts of the deployed Internet that do actually perform > statefull inspection. But I would expect increasing the number of channels > to degrade performance at a firewall or any other middle boxen. > > So we have a set of behavior that seems at odd with the theory. Has anyone > done any experiments recently that would show which is right? > > > The reason it makes a difference is that it is becoming clear that modern > applications are not best served by an application API that is limited to > one bi-directional stream. There are two possible ways to fix this > situation. The first is to build something on top of TCP/IP the second is to > replace single stream TCP with multi-stream. > > My preference and gut instinct is that the first is the proper architectural > way to go regardless of the performance benefits. When Thompson and co were > arguing that all files are flat sequences of bits, they were saying that was > the right O/S abstraction because you could build anything you like on top. > > But then I started to ask what the performance benefits to a multi-stream > TCP might be and I am pretty sure there should not be any. But the actual > Internet does not always behave like it appears it should. > > I suspect that the preference for multiple streams probably comes from the > threading strategies it permits. But that is an argument about where the > boundary between the kernel and application is placed in the network stack > rather than where multiplex should live in the stack. Microsoft already > provides a network stack for .NET where the boundary is in the HTTP layer > after all. > > > So anyone got hard data they could share?