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

[Murari Sridharan <[e-mail]>]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Reinaldo Penno
Sent: Monday, November 24, 2008 3:55 PM
To: Stanislav Shalunov; Andrew G. Malis
Cc: [e-mail]
Subject: Re: [ledbat] list of reasons for needing multiple TCP connections

Hello Stas,


On 11/24/08 3:28 PM, "Stanislav Shalunov" <[e-mail]> wrote:

> 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.

Why not? A middlebox that offers NAT/FW has to keep track of all connections
irrespective if they are mostly idle.

[MS] I think most NATs aggressively reuse stale mappings and if your protocol relies on this mapping for connectivity, it would fail, we routinely see this with Teredo where the address/ external port would change unless you keep a periodic bubble to keep the mapping up.

>
> 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

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

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