Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

> On Jul 15, 2019, at 8:50 AM, Tom Herbert <[e-mail]> wrote:
> 
>> On Sun, Jul 14, 2019 at 8:52 AM Joe Touch <[e-mail]> wrote:
>> 
>> So, *given* that we *are* different from UDP and TCP, i.e., we do NOT have the luxury of a fixed-offset location for this checksum
> 
> Joe,
> 
> There's no requirement that precludes defining a fixed header that
> precedes the surplus space.

It clearly can’t be a fixed location. Thats all I was asserting. 

Or do you disagree?

>> - why does the offset distance matter, i.e., front vs. end?
> 
> Because some implementations assume that checksums are in protocol
> headers towards the beginning of the packet. For instance, for
> checksum offload the e1000e NIC stores offsets of checksum start and
> checksum field in a byte. If either offset is greater than 255 then
> the checksum can't be offloaded to the hardware.

That’s a nonstarter. We cannot make that limit. Any other reason?
> 
>> - how *MUCH* does the offset alignment matter, keeping in mind:
>>        - no offset might require 1 byte-swap at some point, but consumes the least space
>>        - half-word alignment wastes 4 bits on avg.
>>        - full-word alignment wastes 12 bits (1.5 bytes) on avg
>> 
>> In comms, the typical figure of merit is 1 opcode per bit. So, IMO:
>> 
>> - if we can save 4 bits with 4 or fewer opcodes, it’s a win
>> - if we can save 12 bits with 12 or fewer opcodes, it’s a win
>> 
> The tradeoff between maintaining alignment and efficiency in overhead
> is well known. For instance RFC8200 states:
> 
> "Individual options may have specific alignment requirements, to
> ensure that multi-octet values within Option Data fields fall on
> natural boundaries"
> 
> Note RFC8200 does not require option alignment; per robustness
> principle receivers should be prepared to deal with unaligned options.
> However, also by the robustness principle senders should send aligned
> options especially if they want to minimize the chances that a
> receiver drops packets or relegates them to slow path processing.
> Personally, in my implemenation and protocols, I will always align
> protocol fields to their natural boundaries if possible-- I have never
> seen any complain about too much space being wasted for alignment, but
> I have seen issues when protocol fields were unaligned.

That would be good reasons for a SHOULD, but clearly not a MUST - regarding starting aligned. 

Joe

> 
> Tom
> 
> 
>> My assumption is that offload engines or the core processor need to do “non-halfword length” cleanup regardless.
>> 
>> That cleanup should be at most 5 opcodes:
>>        load
>>        mask the addend
>>        add w/carry
>>        mask the sum (for the 1’s compl wrap)
>>        add w/carry (for the 1’s compl wrap)
>>        swap (if not half-word aligned)
>> 
>> That suggests we’re either very close to no real penalty for “no offset” or that we win by using at least half-word offset.
>> 
>> Note: the alignment overhead will also NEED to be zero - and checked that it’s zero, which are additional opcodes needed that are not too far from the cleanup ones above.
>> 
>> i.e., given the similarity of the zero-check and the cleanup, why is it useful to waste these bytes?
>> 
>> Joe
>> 
>>> On Jul 13, 2019, at 11:49 AM, Tom Herbert <[e-mail]> wrote:
>>> 
>>> On Sat, Jul 13, 2019 at 11:26 AM Derek Fawcus
>>> <[e-mail]> wrote:
>>>> 
>>>>> On Thu, Jul 11, 2019 at 07:07:39PM -0700, Joe Touch wrote:
>>>>> 
>>>>> Not sure I follow here - so there are only a few variants that seem viable:
>>>>> 
>>>>> 1.- at the front of the surplus space
>>>>> 2.- at the front of the surplus space after alignment NOPs
>>>>> 3.- at the end of the surplus space
>>>>> 4.- at the end of the surplus space with alignment
>>>>> 
>>>>> AFAICT, there’s no real help in requiring OCS be aligned (it can be designed to tolerate any alignment), which means we don’t need #2 or #4.
>>>> 
>>>> Agree.  I see no need for alignment.
>>>> 
>>>>> So what’s preferable here? #1 or #3?
>>>> 
>>>> Not sure.
>>>> 
>>>> I'd be inclined to pick 1, but could be convinced that 3 is better.
>>>> 
>>>> If we're talking of h/w offload engines [*], I imagine that they could
>>>> handle 'write to 2 bytes before end of packet' more easily than
>>>> 'write to start of surplus'.
>>> 
>>> Derek,
>>> 
>>> It's the other way around because offload engines are primarily built
>>> to deal TCP and UDP checksums which have always been in headers
>>> towards beginning of the packet. Similarly, HW can optimize for
>>> checksum being aligned since UDP and TCP checksums have always been
>>> aligned.
>>> 
>>>> 
>>>> DF
>>>> 
>>>> [*] How many do this with random logic?  My current impression is that
>>>>   most such devices are programmable cores, e.g. ARM or MIPS cores.
>>> 
>>> Actually no, checksum offload is in ASICs and maybe some FPGA. NICs
>>> are getting cores now in so called Smart-NICs, but those are more
>>> likely to be applied towards more complex protocol parsing and
>>> processing. CPUs in the NIC won't fundamentally improve how checksum
>>> offload, the solutions for that are well established and understood.
>>> 
>>> If you're interested, we will be presenting a technlogy deep dive
>>> @IETF105 that will cover a lot of topics around NIC technology:
>>> https://datatracker.ietf.org/meeting/105/materials/agenda-105-tdd-01
>>> 
>>> Tom
>>> 
>>>> 
>>> 
>>