[Spud] Segment offload for UDP-based protocols Re: [QUIC] Requirements

[Brian Trammell <[e-mail]>]

hi Randall,

> On 09 Jun 2016, at 12:30, Randall Stewart <[e-mail]> wrote:
> 
> 
>> On Jun 9, 2016, at 5:06 AM, Michael Tuexen <[e-mail]> wrote:
>> 
>> 
>>> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) <[e-mail]> wrote:
>>> 
>>> My concern is that the current charter suggestion markets the protocol by “minimizing (…) overall transport latency for applications”. IMHO this can have rebound effects.
>>> 
>>> Here is what I mean by wrong expectations: Whether a protocol is indeed fast or not depends on many parameters including aspects such as hardware acceleration/offload (which matters at 10G/40G line speed, to the best of my knowledge). Some of these effects of
>> I think this refers to high throughput. For TCP, offloading TCP processing to a NIC improves performance
>> of the TCP processing. I'm not sure if this still helps if encryption/decryption comes into the game.
> 
> I too was thinking Michael meant offloading such as TSO and LRO. I know on most of the caches
> I develop on if I turn off TSO and LRO performance of the box drops by roughly 50%… and I think
> this will be a consequence of encrypting everything since I don’t think you can do TSO/LRO unless
> the hardware/lower-layers has access to things equivalent to TCP sequence numbers and ACK values,
> which is what I believe the encryption is meant to hide (from middle boxes).
> 
> That will be an extreme price to pay the question is, is it worth it /and or/ is there some other way
> to get the benefits of the TSO/LRO even with encryption… :-)

(adding [e-mail], as this is a relevant question for PLUS, too):

The question is what is the minimum information xSO/LRO needs to work. If I understand how generic segment offload works, if QUIC(/PLUS) exposes:

(1) a header field that can be used to order packets and find gaps that the kernel can find and interpret,

(2) a defined and easily-found boundary between header and payload, such that the payload retains any framing/message boundaries needed to meet API contracts, and

(3) rules about which header to choose for the "big" segment on receive

then adding QUIC(/PLUS) aware SO/LRO to the kernel should be reasonably simple.  I don't see why you need ACK-equivalents to be exposed to make this work, but I might be missing something.

Hardware offload takes longer to deploy, obviously, but runs on equivalent information.

Cheers,

Brian