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

From: Joe Touch <[email-masked]>
Date: Thu, 20 Nov 2008 11:43:42 -0800

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ledbat

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 20 Nov 2008 14:06:03 -0600

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 <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkklve4ACgkQE5f5cImnZru0gQCfaxwMKa8BPYliwCay9hFGLcD3
> HUQAn1zIlOBJRu1u0qbtpNX8ryuur8ZF
> =YmcT
> -----END PGP SIGNATURE-----

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Nov 2008 12:07:41 -0800

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:
> --------------------------------------
> - get around head-of-line blocking
> - demultiplexing
> - support different stream properties
> - support "CLOSE means EOF" semantics
> - support larger socket buffer sizes
> -------
> - different interaction with errors
> ----------------------------------------------

---

From: "Kartik Chandrayana (karchand)" <[email-masked]>
Date: Thu, 20 Nov 2008 12:37:25 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Andrew G. Malis
Sent: Thursday, November 20, 2008 2:06 PM
To: Joe Touch
Cc: [email-masked]
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

> general point is that this is NOT always about hogging bandwidth, 
> either intentionally or not.
>
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Nov 2008 12:44:26 -0800

> than a single lean fast TCP.

That presumes that the OS implements parallelization in the network
code; I don't know if that's recently offered, but it has been the
sticking point in the past.

Joe

---

From: "Kartik Chandrayana (karchand)" <[email-masked]>
Date: Thu, 20 Nov 2008 12:53:29 -0800

Joe,

  I am also not aware if parallelization of network code is implemented
in OSes. However, I think it would be reasonable to expect that tcpcb
lookups are done in a centralized fashion and once that is done,
multiple tcp's can be processed in different cpus. Even the lookups can
be distributed as they are only a read operation.

Thanks,
-Kartik

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, November 20, 2008 2:44 PM
To: Kartik Chandrayana (karchand)
Cc: Andrew G. Malis; [email-masked]
Subject: Re: [ledbat] list of reasons for needing multiple TCP
connections

Kartik Chandrayana (karchand) wrote:
> 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.
> multiple TCP connections can harness the multi-cpu architectures 
> better than a single lean fast TCP.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Nov 2008 12:57:17 -0800

> be distributed as they are only a read operation.

Parallelizing TCP includes dealing with not only the TCP code, but also
the IP input queue access, timers, etc. I am not as sure that there's a
one TCP per core mapping in current OS's - though I'd be glad to hear
someone *confirm* it.

Joe

---

From: <[email-masked]>
Date: Thu, 20 Nov 2008 20:58:44 +0000

On 08-11-20 14:53, "ext Kartik Chandrayana (karchand)" <[email-masked]>
wrote:
> in OSes.

I believe Andre Opperman's recent work on the FreeBSD-7 stack was mostly
about parallelization.

Lars

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 20 Nov 2008 13:50:43 -0800

> that you're behind a NAT and adapt appropriately.

The gotcha here is that every item in the list Joe supplied is
already solved by SCTP, and about the only legitimate reason
for not using SCTP is the presence of middleboxes that do
not support it.

So the only time you have an excuse for using multiple TCP
connections is exactly when there are resources that might
be exhausted by the practice.

Using multiple connections to solve a single problem inherently
degrades the ability of the network to manage traffic effectively.
I recognize that it isn't going to go away anytime soon, but there
is no reason why we should *encourage* this anti-social behavior.

-- 
Caitlin Bestler
[email-masked] - http://www.asomi.com/CaitlinBestlerResume.html
_______________________________________________
ledbat mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ledbat

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Nov 2008 13:54:39 -0800

> for not using SCTP is the presence of middleboxes that do

SCTP doesn't address the need for different applications to have
different connections (one variant of the demultiplexing issue). I.e., a
single socket used by more than one application.

SCTP also doesn't address the need to support endpoints that don't speak
SCTP yet, or services that aren't defined over SCTP yet.

FWIW, many of these issues were similarly addressed by HTTP 1.1, and in
other applications as well.

Joe

---

From: "Robb Topolski" <[email-masked]>
Date: Thu, 20 Nov 2008 14:24:12 -0800

I want to eliminate the "bandwidth hogging" motive in using multiple P2P
connections to get more traffic across a congested network.  Neither the
facts nor the personalities of the developers involved support that charge.
It's a huge and false distraction from what may be good work at hand.

P2P apps, users, protocols, developers do not use multiple connections to
get an unfair "leg up" across any point of congestion...

THAT TRICK WON'T WORK ON SPEED-CAPPED CONNECTIONS: While it's true that
larger number of standard TCP connections can allow a greater share of
bandwidth across any particular point in the network, getting that bandwidth
depends on a lack of any other limiting factor.  In our residential
networks, however, the subscriber's broadband modem imposes relatively low
ceilings.  A single connection can get maximum speed either in or out.
Therefore, any "bandwidth-hogging" benefit of running multiple connections
on these broadband access networks is very temporary at worst (about the
time it takes for the multiple streams to all get knocked down and find new
equilibrium) and may actually work out to be nil (giving that all the
streams will respond eventually in relatively proportionate ways).

P2P DOESN'T USE THAT TRICK: The slot-and-choke (used by BitTorrent) or
queue-list techniques (used by Gnutella or ED2K) and similar used by others
tends to limit the number of connections actually in use vs. disconnected or
occasionally sending tiny bits of mesh data.  Just like any other sender of
information, P2P uploads are overall faster and more efficient when they
respond to congestion signals than they are when they ignore them.

P2P AVOIDS CONGESTED ROUTES: Sources for data that are on congested routes
are used less often and for shorter times than sources on routes that are
free of congestion. BitTorrent does this by reserving all but one of its
slots for the fastest reciprocating peers and by reserving one slot to hunt
for even faster peers (the presumption being that slow peers indicate
congested routes).  In Gnutella and ED2K, peers are usually both time and
data limited -- so if the clock expires before a chunk is fully transferred,
the transfer is ended.  This has the net effect of getting the most data
from peers without such a constraint.

USING MULTIPLE CONNECTIONS HAS NOTHING TO DO WITH BANDWIDTH CONSUMED: In one
of the presentations, the speaker seemed to tie the use of multiple
connections to bandwidth consumption.  The consumption of bandwidth,
however, has everything to do with the size of the object being transferred
and nothing to do with the number of connections.  Take the task of
downloading and sharing the Knoppix DVD.  If the multiple connections were
replaced by single connections, the bandwidth consumed would be essentially
the same (about 10 GB). The additional overhead is hardly worth mentioning.

There is a related -- almost rhyming -- motive, but it's not an evil motive
as far as the network is concerned.  Some users observe that being connected
to more peers results in faster downloads.  This is -not- because anyone is
ignoring congestion signals, it's simply because more connections gives a
downloader access to a larger number of altruistic "seeders" (sources who
will upload without an immediate expectation of reciprocation).  These
seeders are still operating under the same network rules as other nodes,
uploading only on a very limited number of their connections and responding
to signs of congestion control.  (And most users don't realize that seeders
have little motivation to transfer exclusively to them, so while that trick
works, it doesn't work as well as many expect. Many users are disappointed
in the download rates experienced within heavily seeded swarms.)

There is room for improvement -- like any other network use, P2P
file-sharers have shown that they are very interested in efficiency and are
adaptive to technology or techniques that gets them there.  P2P file sharing
is not perfect, either socially or technologically.  There are network
cheaters and generally dumb ideas out there.  While I'm speaking generally
of typical P2P users, developers, and protocols -- there will always be the
few exceptions.  While nobody has targeted these exceptions as the biggest
part of "the problem," I didn't want the above info to be interpreted as
ignoring the fact that they exist here and there.
_______________________________________________
ledbat mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ledbat

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Nov 2008 14:43:17 -0800

Hi, Robb,

Appreciating the following, this isn't intended as an application
protocol, so we can't assume it would apply only to P2P. I.e., we need a
solution that can be used for any application, and there are several
applications that DO use multiple connections to increase bandwidth in
the typical case.

Joe

Robb Topolski wrote:
> facts nor the personalities of the developers involved support that
> charge.  It's a huge and false distraction from what may be good work at
> hand.
> 
> P2P apps, users, protocols, developers do not use multiple connections
> to get an unfair "leg up" across any point of congestion...
> 
> bandwidth across any particular point in the network, getting that
> bandwidth depends on a lack of any other limiting factor.  In our
> residential networks, however, the subscriber's broadband modem imposes
> relatively low ceilings.  A single connection can get maximum speed
> either in or out.  Therefore, any "bandwidth-hogging" benefit of running
> multiple connections on these broadband access networks is very
> temporary at worst (about the time it takes for the multiple streams to
> all get knocked down and find new equilibrium) and may actually work out
> to be nil (giving that all the streams will respond eventually in
> relatively proportionate ways). 
> 
> queue-list techniques (used by Gnutella or ED2K) and similar used by
> others tends to limit the number of connections actually in use vs.
> disconnected or occasionally sending tiny bits of mesh data.  Just like
> any other sender of information, P2P uploads are overall faster and more
> efficient when they respond to congestion signals than they are when
> they ignore them.
> 
> P2P AVOIDS CONGESTED ROUTES: Sources for data that are on congested
> routes are used less often and for shorter times than sources on routes
> that are free of congestion. BitTorrent does this by reserving all but
> one of its slots for the fastest reciprocating peers and by reserving
> one slot to hunt for even faster peers (the presumption being that slow
> peers indicate congested routes).  In Gnutella and ED2K, peers are
> usually both time and data limited -- so if the clock expires before a
> chunk is fully transferred, the transfer is ended.  This has the net
> effect of getting the most data from peers without such a constraint.
> 
> USING MULTIPLE CONNECTIONS HAS NOTHING TO DO WITH BANDWIDTH CONSUMED: In
> one of the presentations, the speaker seemed to tie the use of multiple
> however, has everything to do with the size of the object being
> transferred and nothing to do with the number of connections.  Take the
> task of downloading and sharing the Knoppix DVD.  If the multiple
> connections were replaced by single connections, the bandwidth consumed
> would be essentially the same (about 10 GB). The additional overhead is
> hardly worth mentioning. 
> 
> There is a related -- almost rhyming -- motive, but it's not an evil
> motive as far as the network is concerned.  Some users observe that
> being connected to more peers results in faster downloads.  This is
> -not- because anyone is ignoring congestion signals, it's simply because
> more connections gives a downloader access to a larger number of
> altruistic "seeders" (sources who will upload without an immediate
> expectation of reciprocation).  These seeders are still operating under
> the same network rules as other nodes, uploading only on a very limited
> number of their connections and responding to signs of congestion
> control.  (And most users don't realize that seeders have little
> motivation to transfer exclusively to them, so while that trick works,
> it doesn't work as well as many expect. Many users are disappointed in
> the download rates experienced within heavily seeded swarms.)
> 
> file-sharers have shown that they are very interested in efficiency and
> are adaptive to technology or techniques that gets them there.  P2P file
> sharing is not perfect, either socially or technologically.  There are
> network cheaters and generally dumb ideas out there.  While I'm speaking
> generally of typical P2P users, developers, and protocols -- there will
> always be the few exceptions.  While nobody has targeted these
> exceptions as the biggest part of "the problem," I didn't want the above
> info to be interpreted as ignoring the fact that they exist here and there.
> 
> 
> ------------------------------------------------------------------------
>

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 20 Nov 2008 14:54:29 -0800

> applications that DO use multiple connections to increase bandwidth in

As a point of reference, part of the justification for doing iSCSI
over multiple TCP connections within a session was because "It
might be impossible to achieve the full bandwidth capability
of the underlying physical transport by using a single TCP
connection."

[http://storageconference.org/2003/papers/19-Meth-Design.pdf
section 2.2]

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 20 Nov 2008 15:10:44 -0800

Robb,

10GB is not a measure of bandwidth. It is a measure of file size or volume
if you will.  Bw is a measure of how many bis you can transfer per second.
There is a time scale involved.

Thanks,

Reinaldo

On 11/20/08 2:24 PM, "Robb Topolski" <[email-masked]> wrote:

> the bandwidth consumed would be essentially the same (about 10 GB).

---

From: "Robb Topolski" <[email-masked]>
Date: Thu, 20 Nov 2008 15:23:30 -0800

> [http://storageconference.org/2003/papers/19-Meth-Design.pdf
Good stuff there, the relevant reasoning that might be sucked into a LEDBAT
paper include:

              It might be impossible to achieve the full bandwidth capa-
              bility of the underlying physical transport by using a sin-
              gle TCP connection (possibly due to the TCP window
              size and the round-trip-time of TCP acknowledgements
              over long distances). Some protocols, like SCTP, auto-
              matically and transparently distribute their traffic over a
              number of connections in order to achieve the full band-
              width. There may also be several physical interconnects
              (i.e. separate cables) connecting the initiator and target,
              and it would be most desirable to aggregate and simulta-
              neously utilize all such existing physical connections.

-- 
Robb Topolski ([email-masked])
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
ledbat mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ledbat

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Nov 2008 16:28:14 -0800

Hi, all,

It's useful to differentiate between TCP not getting full BW because it
uses only a single path, vs. TCP not getting full BW because its window
doesn't open fast enough.

SCTP addresses the former, not the latter; the two have the same problem
in the latter case. There are a variety of extensions to TCP's windowing
mechanism to address high BW*delay product environments which apply
equally well to SCTP in those cases.

Joe

Robb Topolski wrote:
> 
> 
> On Thu, Nov 20, 2008 at 2:54 PM, Caitlin Bestler <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Good stuff there, the relevant reasoning that might be sucked into a
> LEDBAT paper include:
> 
> Robb Topolski ([email-masked] <mailto:[email-masked]>)
> Hillsboro, Oregon USA

---

From: Bryan Ford <[email-masked]>
Date: Fri, 21 Nov 2008 07:33:19 -0600

> SCTP yet, or services that aren't defined over SCTP yet.

Just to fill this out, a third issue is that the multiple logical  
streams sharing an SCTP connection have no independent flow control:  
SCTP provides flow control only for the connection as a whole.  Thus,  
the receive side of any connection has to accept data on all the  
streams at whatever (relative) rates the sending side is sending data  
on those streams, and can't "push back" on one stream while allowing  
another to flow, unless the application implements some additional  
higher-level windowing and flow control mechanism.

If a web browser is downloading two HTTP objects at once using two  
SCTP streams sharing one connection, for example, and one is a file  
downloading to a fast disk but the other is an mp3 or avi file that  
the browser is streaming to a constant-rate audio/video frame, then  
the browser has no direct way to limit the download rate of the a/v  
stream to the output rate without also holding back the file  
download.  (Granted, this particular example doesn't typically happen  
with current browsers, since browser plug-ins typically handle media  
streams, using completely separate connections to the server.)

Bryan

---

From: Michael Welzl <[email-masked]>
Date: Mon, 24 Nov 2008 09:25:54 +0100

Hi,

> [http://storageconference.org/2003/papers/19-Meth-Design.pdf

I'd like to add GridFTP to this, as another example. cf.:
http://www.globus.org/toolkit/docs/3.2/gridftp/

which points to:
http://www.globus.org/alliance/publications/papers/dataMgmt.pdf
where it says, on page 7:

"Parallel data transfer: On wide-area links, using multiple TCP streams
in parallel (even between the same source and destination) can improve
aggregate bandwidth over using a single TCP stream [10]. GridFTP
supports parallel data transfer through FTP command extensions and data
channel extensions."

Cheers,
Michael

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 24 Nov 2008 15:28:17 -0800

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

--
Stanislav Shalunov

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 24 Nov 2008 15:46:00 -0800

> is no reason why we should *encourage* this anti-social behavior.

The list of applications that open multiple TCP connections to the  
same destinations includes:

* Email (MTAs)
* FTP (data+control)
* Web (all common browsers since Mosaic)

In addition, P2P apps open multiple connections to multiple  
destinations.

This is pretty much the list of Internet killer apps minus IM.  It  
would be counterproductive for us to label this practice anti-social.

The multiple connections document needs to provide a lot of facts and  
a little guidance grounded in facts, not the other way.

Can you expand on how multiple connections impede the provider's  
ability to manage traffic?

--
Stanislav Shalunov

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 24 Nov 2008 15:52:09 -0800

Right.  Also, of course, GridFTP and probably before it bbcp, popular  
in high-energy physics community, use multiple connections to go  
faster -- mainly to get around default buffer size, but also likely to  
benefit from the reduced deviation in throughput with multiple  
connections.

--
Stanislav Shalunov

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 24 Nov 2008 15:55:17 -0800

Hello Stas,

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

> to learn about locations of peers.)  In general, scanning-type

Interesting, but usually middleboxes age UDP entries very quickly (specially
quickly if they have ALGs). So, TCP and UDP have the dealt differently.

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 24 Nov 2008 16:40:26 -0800

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

--
Stanislav Shalunov

---

From: Murari Sridharan <[email-masked]>
Date: Tue, 25 Nov 2008 13:04:01 -0800

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

Hello Stas,

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

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 25 Nov 2008 13:20:13 -0800

I will be updating the draft on recommendations based on all the great
references sent and surely a new section on multiple TCP connections and
performance will be added.

Thanks,

Reinaldo

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 25 Nov 2008 15:43:43 -0800

On Nov 25, 2008, at 1:04 PM, Murari Sridharan wrote:
> [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.

To clarify the context --

"Mostly idle" BitTorrent connections periodically exchange small  
messages (haves and, failing that, keepalives).  They will consume the  
NAT slots, even though they mostly don't matter for other purposes.

This is generally not a problem for the number of connections  
BitTorrent maintains.

--
Stanislav Shalunov

---

From: Murari Sridharan <[email-masked]>
Date: Tue, 25 Nov 2008 16:55:21 -0800

I am not sure I get the entire context of Kartik's comment but Windows Server supports a feature called Receive-side scaling which essentially distributes receive processing and tries to spread TCP connections across multiple cores and tries to keep all processing for a connection aligned on one specific CPU (to the extent that apps cooperate) starting with packet indication all the way to deliver to the app. Connections can get moved around depending on load but in steady state they should remain pinned with the some caveats.

Some links
http://download.microsoft.com/download/a/d/f/adf1347d-08dc-41a4-9084-623b1194d4b2/RSS_Server2008.docx

http://msdn.microsoft.com/en-us/library/ms795616.aspx

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Thursday, November 20, 2008 12:57 PM
To: Kartik Chandrayana (karchand)
Cc: [email-masked]
Subject: Re: [ledbat] list of reasons for needing multiple TCP connections

Joe

---

From: "Robb Topolski" <[email-masked]>
Date: Tue, 25 Nov 2008 17:12:02 -0800

If Skype hasn't made the list, it's a multiple connection user and I think
some nodes are given additional mesh responsibilties depending upon their
connectivity.  Consider data of the "well I heard" quality.  Although I have
noticed the multiple connections, I haven't done any great work to profile
it.

On Tue, Nov 25, 2008 at 3:43 PM, Stanislav Shalunov <[email-masked]>wrote:

> "Mostly idle" BitTorrent connections periodically exchange small messages
> (haves and, failing that, keepalives).  They will consume the NAT slots,
> even though they mostly don't matter for other purposes.
>
> This is generally not a problem for the number of connections BitTorrent
> maintains.
>
>
A common issue with P2P file-sharing users of NATs isn't limited to the TCP
connections created for the mainstream functions of the network but the UDP
table entries created by their various DHT networks.

>From a middlebox perspective, they probably take as many bytes in a table as
TCP connections do.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 27 Nov 2008 17:02:47 +0200

On 2008-11-25, at 1:28, Stanislav Shalunov wrote:
> Home NATs
> another matter.

Yes. As a datapoint, my home NAT reboots when I nmap through it, but  
has no issue with BitTorrent.

Lars

---

From: Richard Bennett <[email-masked]>
Date: Thu, 27 Nov 2008 15:06:27 -0800

Most home "routers" have all been modified by now not to crash when
BitTorrent has opened thousands of TCP connections. These connections
consume mapping table resources and were a problem until it they were
garbage-collected.

RB

Lars Eggert wrote:

Home NATs

another matter.

Lars