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

[Stanislav Shalunov <[e-mail]>]

On Nov 24, 2008, at 3:55 PM, Reinaldo Penno wrote:
>> 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.
>
> Why not? A middlebox that offers NAT/FW has to keep track of all  
> connections
> irrespective if they are mostly idle.

Exactly.  The fact that BitTorrent connections are mostly idle doesn't  
matter for how much state is consumed on a NAT.

>> 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.
>
> Interesting, but usually middleboxes age UDP entries very quickly  
> (specially
> quickly if they have ALGs). So, TCP and UDP have the dealt  
> differently.
>
>>
>> -- 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
>

--
Stanislav Shalunov



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