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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Understood - it would be useful to collect additional items as to why
NOT to use multiple TCP connections. The list below is just the reasons
that apps DO use them.

Joe

Andrew G. Malis wrote:
> 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:
> 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
> 
> ----------------------------------------------
_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkklw40ACgkQE5f5cImnZrs/AQCeMMMGWJNU1IPMRyztmyFWLnLg
TqcAoM1uZvnW3ckgM64l79Ei3gF65BI6
=xFon
-----END PGP SIGNATURE-----
_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat