> On Oct 31, 2018, at 6:53 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
>
>
>
> On 10/31/2018 04:26 PM, Christoph Paasch wrote:
>> Implementations of Quic might want to create a separate socket for each
>> Quic-connection by creating a connected UDP-socket.
>>
>
> Nice proposal, but I doubt a QUIC server can afford having one UDP socket per
> connection ?
First thing: This is an idea we’ve been floating, and it’s not completed yet,
so we don’t have any performance numbers etc. to share. The ideas for the
implementation came up after a discussion with Ian and Jana re: their
implementation of a QUIC server.
That much said, the general rationale for this is that having a socket for each
QUIC connection could simplify integrating QUIC into existing software that
already does epoll() over TCP sockets. This is how e.g. Apache Traffic Server
works, which is our target implementation for QUIC.
>
> It would add a huge overhead in term of memory usage in the kernel,
> and lots of epoll events to manage (say a QUIC server with one million flows,
> receiving
> very few packets per second per flow)
Our use case is not millions of sockets, rather, 10’s of thousands. There would
be one socket for each QUIC Connection, not per stream (obviously). At ~80Gbps
on a box, we definitely see much less than 100k TCP connections.
Question: is there additional memory overhead here for the UDP sockets vs a
normal TCP socket for e.g. HTTP or HTTP/2 ?
>
> Maybe you could elaborate on the need of having one UDP socket per connection.
We had a couple reasons:
1) Easier to integrate with existing epoll() based event processing
2) Possibly less CPU usage / faster handling, since scheduling is simplified
with the epoll integration (untested)
Ian and Jana also had a couple of reasons why this delayed bind could be useful
for their implementations, but I’ll leave it to them to go into details.
Cheers,
— leif
