Re: Naive question on multiple TCP/IP channels

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Feb 5, 2015 at 10:09 AM, Martin Rex <[e-mail]> wrote:

> Phillip Hallam-Baker 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.
>
>
> Your picture is completely missing a _very_ common usage scenario.
> Bandwidth is often irrelevant.  It is often the "time-to-use" that counts.
> And with Web Browsers, it is extremely common that users navigate to a
> different page before the current page has completed loading.
>

No, actually I am fully aware of that requirement, it is what prompted my
question. There is no question that we need a multiplexing capability. The
question is whether this should be at the Transport level by opening
multiple TCP streams or at a higher level.

I suspect that what is actually holding us back here is the lack of a good
API for any sort of multiplexed setup. Virtually all of our APIs are still
following the BSD sockets approach which in turn was developed before
threads existed.


Working at the transport level means being limited to a fairly small
number of multiplex streams. If we kicked the interaction up to the
application
level then we could make it easier for a browser to regulate the
information
flow and prioritize the information it needed.