netdev - Re: Very low latency TCP for clusters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 Jul 2010 14:16:10 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Mitchell Erblich <erblichs@...thlink.net>
Cc:	netdev@...r.kernel.org
Subject: Re: Very low latency TCP for clusters

On Mon, Jul 19, 2010 at 12:46 PM, Mitchell Erblich
<erblichs@...thlink.net> wrote:
> Tom, et al,
>
>                To possibly remove 3-way handshake costs for
>                small data transfers a number of years ago, their
>                was an experimental RFC that was a Transactional
>                TCP, where the SYN, data, and FIN were sent as
>                a tuple in the first segmernt.
>
In the context of this discussion, latency is about how fast packets
can be sent and received between applications over an established
connection.  The application would likely be doing some form of RPC
over long lived connections,  reducing latency here allows for more
tightly coupled computing models.  This sort of thing would be used on
a well connected, low-loss cluster within a data center.

Separately, there is interest in speeding up 3WHS primarily for
connections to the Internet.  We have already proposed to reduce
latency by raising the the initial congestion window (there's another
netdev thread on this if your interested).  T/TCP, which your
referring to, was abandoned due to unsolved security issues and
susceptibility to denial of service attacks.  I believe the current
IETF answer to this would be to use SCTP, but that represents a
deployment conundrum.  Address these issues to get data with the TCP
SYN is still compelling IMO.

Tom


>                If a company has control of the two end systems
>                and the intermediate systems, then it should be
>                possible for an app to declare in a setsockopt call
>                this experimental flow.
>
>                Mitchell Erblich
>                ============
>
> On Jul 19, 2010, at 10:05 AM, Tom Herbert wrote:
>
>> We have been looking at best case TCP latencies that might be achieved
>> within a cluster (low loss fabric).  The goal is to have latency
>> numbers roughly comparable to that which can be produced using RDMA/IB
>> in a low latency configuration  (<5 usecs round trip on netperf TCP_RR
>> test with one byte data for directly connected hosts as a starting
>> point).  This would be without changing sockets API, fabric, and
>> preferably not using TCP offload or a user space stack.
>>
>> I think there are at least two techniques that will drive down TCP
>> latency: per connection queues and polling queues.  Per connection
>> queues (supported by device) should eliminate costs of connection
>> look-up, hopefully some locking.  Polling becomes viable as core
>> counts on systems increase, and burning a few CPUs for networking
>> polling on behalf of very low-latency threads would be reasonable.
>>
>> Are there any efforts in progress to integrate per connection queues
>> in the stack or integrate polling of queues?
>>
>> Thanks,
>> Tom
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html