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

Joe Touch <touch@strayalpha.com> Fri, 12 July 2019 03:48 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDD5120089 for <tsvwg@ietfa.amsl.com>; Thu, 11 Jul 2019 20:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Level:
X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bvEFjhNO1BP for <tsvwg@ietfa.amsl.com>; Thu, 11 Jul 2019 20:48:47 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1C2120019 for <tsvwg@ietf.org>; Thu, 11 Jul 2019 20:48:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eXvh1Xryfcv3s6XAfiPdYA/b0jJ/ZujWRZ2w6iLBNlk=; b=GaNVPJviJaft5tVrfR/b5eYsX E1wHPnd7C+nDeFRHLnD8yXDkFr4OFRk5ptr+hqGKcuzGMW6lPI8EaDF2PQTtWiwIXYdcpXLKwKGRN KotN//S4DMC/aZnYmUqggsf+UnyyKUXORJctdubO8JZnIPXMxJyJL5z8PBq7u9ZKGdjwahGX+vBQJ mN5AMIDoPvjPEieZCMlfOBeboaqRVg0CLBRyhFuVrXihMbAmiYI9WhZhSsogToEKmK6+tr29G70kJ Wni3igixNCW/FS5XAxfObKATM6ri0JHXtofeUNw/OIxC1Qcq3oqvD6OhHTw9K2q5/g4fey6itOLPM ln3W6nB5w==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60874 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1hlmY5-000cM2-F9; Thu, 11 Jul 2019 23:48:45 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9D21FA9-BB43-474B-A429-5D1F18CD0117"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <CAPDqMeqHHUnMCDc6FFoZ=+5EeLPiJJZ2Msqo6OS9wGFUeNH=HQ@mail.gmail.com>
Date: Thu, 11 Jul 2019 20:48:40 -0700
Cc: "Black, David" <David.Black@dell.com>, tsvwg@ietf.org
Message-Id: <23DDA223-8A4F-49B3-A564-389CE5C68B75@strayalpha.com>
References: <156262970360.865.13042807682366763561.idtracker@ietfa.amsl.com> <CAPDqMeoMqsB8=tH5TBaq5Tw-sLW3HNc8tpfUU3htV=sWo7pJcA@mail.gmail.com> <D7E52D2B-3912-4897-80C6-0150CDE10218@strayalpha.com> <CAPDqMep9MYqjFvvJSVbqYwo-xJ1pUocYszNukveaZODhf9+75A@mail.gmail.com> <e73919f08202937bf45418cbf8bcc38c@strayalpha.com> <CAPDqMeoh3n5fL1k6Fw9D8rCpy4a9eWyUZvgStyzYfFuJbuWudw@mail.gmail.com> <3f6f54e0b828e2628af964d6ee7f33e1@strayalpha.com> <CALx6S37rt7OJtH5a2ZH23R21ATETuwTeFS-mZQECtgxPQ3nSZA@mail.gmail.com> <ccc386aa429bfe301998f39eb7fccfbf@strayalpha.com> <140f11c854e0ad96c51639f830cbb688@strayalpha.com> <CALx6S35MC_fj+fL6Ax9a-9=-QX0-mHLmMQ7cUs2Rir+AvYE=zA@mail.gmail.com> <5b35e91dd510119672a0836f868ade24@strayalpha.com> <CALx6S36AVbKfvb-6dj07rcGjsVsCz0daFM9qZOBSSstZOM-Ukg@mail.gmail.com> <8A584FFF-6C86-4154-8D9D-CF407CA77145@strayalpha.com> <CAPDqMeq9GjEQKukH1pZOTdE50e_rc3U6gpdxT-5qrS5phD0RGw@mail.gmail.com> <646D45AD-D79B-4BD2-A084-7DA97CE2C415@strayalpha.com> <7EC37B50-45D5-4CF1-B113-205E55BF244E@strayalpha.com> <CALx6S34s7L7xo+26bt5Cdaqi4Es5Aci42GHk1WNKzugr5st-Gw@mail.gmail.com> <B525BF50-EFCC-44A5-A604-6CDDA914A1CB@strayalpha.com> <CAPDqMep3R6z9PRKkHyOvrh6sV9n5Sc0B++-zVz0FYJCwE6swrQ@mail.gmail.com> <E42A2AE2-F499-465E-BDE6-5EFC0AB20042@strayalpha.com> <CE03DB3D7B45C245BCA0D24327794936306138E9@MX307CL04.corp.emc.com> <CAPDqMeoyNb7vQTdqxLpZpnKb9S7QKeDJNLyQJBmq95yXhB+xfQ@mail.gmail.com> <7D365770-64FE-40BC-901D-B4D7DF6B484B@strayalpha.com> <CAPDqMeqHHUnMCDc6FFoZ=+5EeLPiJJZ2Msqo6OS9wGFUeNH=HQ@mail.gmail.com>
To: Tom Herbert <tom@quantonium.net>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/InVgNvriHpA_7hUtwusttOfDgoM>
Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 03:48:49 -0000


> On Jul 11, 2019, at 7:14 PM, Tom Herbert <tom@quantonium.net> 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.
> 
> #2 gives greatest probability of working with existing implementation of checksum offload.

A few questions on that:
- Can we deal with a small amount of “cleanup” operations after the offload?
- if so can that allow arbitrary byte start? 
- or at least16-bit instead of 32-bit alignment? 

Keep in mind that regardless of where we start, we shouldn’t need aligned ends, so there’s always some “cleanup” with such support anyway.

I.e., why can’t we start at the 32-bit alignment and just add the rest and adjust later, rather than pad?

Joe