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

[Stanislav Shalunov <[e-mail]>]

We do need to cover the impact on middleboxes in the document -- it's  
in the charter.

Popular applications are made to work with existing middleboxes.   
Middleboxes are made to work with existing popular apps which do open  
couple hundred of (mostly idle) TCP connections.  Home NATs  
("routers") don't generally crash when you run BitTorrent.  The  
"mostly idle" part doesn't matter for state consumption, naturally.

Thousands and tens of thousands of connections (UDP state counts) is  
another matter.  Making one DNS request per every swarm member you  
learn about will overwhelm a few common devices for large enough  
swarms.  (There are client behavior extensions that use DNS requests  
to learn about locations of peers.)  In general, scanning-type  
behavior is problematic.

-- Stas


On Nov 20, 2008, at 12:06 PM, 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ledbat
>>
> _______________________________________________
> ledbat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ledbat

--
Stanislav Shalunov



_______________________________________________
ledbat mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ledbat