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

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: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Joe Touch
Sent: Thursday, November 20, 2008 12:57 PM
To: Kartik Chandrayana (karchand)
Cc: ledbat@ietf.org
Subject: Re: [ledbat] list of reasons for needing multiple TCP connections

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

Kartik Chandrayana (karchand) wrote:
> 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.

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

> -----Original Message-----
> From: Joe Touch [mailto:touch@ISI.EDU]
> Sent: Thursday, November 20, 2008 2:44 PM
> To: Kartik Chandrayana (karchand)
> Cc: Andrew G. Malis; ledbat@ietf.org
> 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.
>> 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.
>
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkklzy0ACgkQE5f5cImnZrtxIwCgw+uW7JxMRDZja1pTuixQUwS8
m5IAoPHHCB2ed20zXkkv15m09kF4q+mm
=30jd
-----END PGP SIGNATURE-----
_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat

_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat