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

[Tom Herbert <[e-mail]>]

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. The fact that UDP is different from TCP is
immaterial to the requirements, except that it's good practice to
adopt some of the design principles of TCP to leverage lessons learned
and implementation. The UDP Extended Header in
draft-herbert-udp-space-hdr-01 demonstrates that.

>
> - 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.

> - 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.

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
> >
> >>
> >
>