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

Joe Touch <touch@strayalpha.com> Mon, 15 July 2019 20:19 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 0068112016C for <tsvwg@ietfa.amsl.com>; Mon, 15 Jul 2019 13:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 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] 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 Kz13jjGszZnw for <tsvwg@ietfa.amsl.com>; Mon, 15 Jul 2019 13:19:04 -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 9117F12027B for <tsvwg@ietf.org>; Mon, 15 Jul 2019 13:19:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=1Dwocx2MNTiLbJ0+5UfK0yhLnu0KZv7qALFMNA7FmVE=; b=1nP0Xjy0kEj2UkZmluCSMMvax gcAzRH96T0MoY5N5Mam/LU8CHq4HL6xClnp/0rqima9argnBeD1TWemlMSXXXFovwUt2Pcrzel4no 7vYMRcqTyQ5fdGuUSe667hWG/8TiEhmF67dEcJdeMyzNfFF9mr4/QpitsmFsEih/pErdBUxQOuMhf qlEWXBPpx0E44Z3qk50Il52YvlnnPPmfDSSP8VoJWWfzdQDbji/rrP2tgdcrq0O4eksoXzD3cd0gv HK50ZkLFCFIcmBSkMUELWeYWrMpgv6+Po79C9M+Z129I2pAnYogcrYTW7/cIDSDZb/fdt4BsVVO/p yH48Nkhcw==;
Received: from [::1] (port=36278 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1hn7R4-004JKs-09; Mon, 15 Jul 2019 16:19:03 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_7f2862d636041f0d3bee51a99284f7f4"
Date: Mon, 15 Jul 2019 13:18:57 -0700
From: Joe Touch <touch@strayalpha.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Derek Fawcus <dfawcus+lists-tsvwg@employees.org>, tsvwg <tsvwg@ietf.org>
In-Reply-To: <CALx6S35XLdNTOTyZp=YDgqiBZEWq-dEUkOTAMD=dAJEQ_XuJhA@mail.gmail.com>
References: <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> <20190713182554.GB39770@clarinet.employees.org> <CALx6S36mH2M6SYnRSecWXa7k_d1u8O43+CXE-=KqeO0x2e5+qw@mail.gmail.com> <82FF6486-FABF-4D2C-B5E2-178779C720A4@strayalpha.com> <CALx6S34YhtgNNJtHazqJdsGRhiMa4PQXiSOuDz0JhqqyHWfNyA@mail.gmail.com> <757FDD92-EC4A-4AC2-B491-74B75119A951@strayalpha.com> <CALx6S36XCUs-oQVBSBX_KTg5qN4fgTBrrgqZqmwBwo75J3UqUA@mail.gmail.com> <3b6db46d21ac1bb7e6c6761df7501c92@strayalpha.com> <CALx6S37L0gxaUmE5FT=ByvETY6FnzqXDPMU++RpCQaqpwPXEyA@mail.gmail.com> <4bfbcce574679f741e47cacd87919de1@strayalpha.com> <CALx6S35XLdNTOTyZp=YDgqiBZEWq-dEUkOTAMD=dAJEQ_XuJhA@mail.gmail.com>
Message-ID: <629efa25da2967f7e67cde3d34f5c240@strayalpha.com>
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
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/U_TejqUbhXDVnUXWI-AcFBlJMAU>
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: Mon, 15 Jul 2019 20:19:06 -0000

On 2019-07-15 12:46, Tom Herbert wrote:

> On Mon, Jul 15, 2019 at 10:40 AM Joe Touch <touch@strayalpha.com> wrote: 
> 
>> ...
>> 
>> Sorry, but you're not following where were are with the UDP options.
>> 
>> 1) we already agreed (in the past week) to make the OCS field mandatory
>> 
>> 2) OCS always covered the entire option space
>> 
>> 3) we already agreed that there would NOT be any surplus space beyond the options, i.e., that options would take up the whole surplus space
>> (anyone who wants to use surplus space should coordinate with the UDP options using that mechanism, as I noted when evaluating your proposal as not necessary)
> 
> Please explain how LITE mode works robustly if the UDP checksum is set.

LITE isn't robust, by design, but... 

- we have another thread about that issue, but we're NOT DISCUSSING THAT
RIGHT NOW 

- IF WE WERE DISCUSSING THAT NOW, I'd note that OCS could do the
following: 
    1- SHOULD be used, but MAY be set to zero (at the user's own
discretion and potential peril) 
    2- LITE ***might*** use OCS set on transmission but ignored on
receipt (to *allow* errors, because LITE ISN'T ROBUST **by design**) 
    3- LITE+FRAG can do as LITE does (#2), with a reassembly checksum
instead (ESP. given the individual checksums null-out with the data,
that may be more appropriate) 

However, we're still not talking about that yet. 

Joe