Re: [ledbat] list of reasons for needing multiple TCP connections

Andy, Joe:

One reason I can think of using multiple TCP connections is to overcome
the non-negotiation of window-scale parameter on most boxes. With
default window scale parameters, i.e 0, the congestion window is limited
to 64KB only and thus for any pipe with bandwidth-delay-product greater
than 64KB, a single TCP connection cannot keep the pipe full. In such a
case, it would be beneficial to have multiple TCP connections. 

Also, since TCP design was mostly with single cpu in mind, I think
multiple TCP connections can harness the multi-cpu architectures better
than a single lean fast TCP.

Thanks,
-Kartik

-----Original Message-----
From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf
Of Andrew G. Malis
Sent: Thursday, November 20, 2008 2:06 PM
To: Joe Touch
Cc: ledbat@ietf.org
Subject: Re: [ledbat] list of reasons for needing multiple TCP
connections

As was mentioned in the IAB plenary yesterday, a reason to not use
multiple TCP connections is the possible exhaustion of middlebox (read
NAT) resources, such as state memory or port numbers. So if you are
going to use multiple connections in parallel, you may wish to include a
method for the user to control that behavior, and a way to detect that
you're behind a NAT and adapt appropriately.

Cheers,
Andy

On Thu, Nov 20, 2008 at 1:43 PM, Joe Touch <touch@isi.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Responding to the issue of reasons to need multiple connections, here 
> are a few of mine (extended from those listed at the mic). This is not

> intended to be a complete list, but a reasonable place to start. The 
> general point is that this is NOT always about hogging bandwidth, 
> either intentionally or not.
>
> Joe
>
> - --------------------------------------
> Reasons to use multiple concurrent TCP connections:
>
> - - get around head-of-line blocking
>        this was an original reason for web browsers needing them
>
> - - demultiplexing
>        related to HOL blocking but not requiring it,
>        this uses TCP connections to demultiplex different
>        streams, because TCP doesn't provide that labeling itself
>
>        this was a reason for using different connections for FTP
>        data and control, e.g.
>
> - - support different stream properties
>        i.e., a single app may want different streams with Nagle
>        enabled and disabled, or with different socket buffer
>        sizes (to limit delay)
>
> - - support "CLOSE means EOF" semantics
>        a reason for multiple connections in HTTP 1.0
>
> - - support larger socket buffer sizes
>        esp. without autotuning, but even with, more connections
>        means more socket buffering is available
>
> - -------
>
> One I forgot to note:
>
> - - different interaction with errors
>        a single connection would keep restarting;
>        multiple connections increases the possibility that
>        one connection doesn't get hit with a short error burst
>
> - ----------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkklve4ACgkQE5f5cImnZru0gQCfaxwMKa8BPYliwCay9hFGLcD3
> HUQAn1zIlOBJRu1u0qbtpNX8ryuur8ZF
> =YmcT
> -----END PGP SIGNATURE-----
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
>
_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat
_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat