Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07
"C. M. Heard" <heard@pobox.com> Mon, 11 March 2019 16:26 UTC
Return-Path: <heard@pobox.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 B7B40131113 for <tsvwg@ietfa.amsl.com>; Mon, 11 Mar 2019 09:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 tqQhhwW5KCTe for <tsvwg@ietfa.amsl.com>; Mon, 11 Mar 2019 09:26:23 -0700 (PDT)
Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92900127963 for <tsvwg@ietf.org>; Mon, 11 Mar 2019 09:26:22 -0700 (PDT)
Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 701085EBD1 for <tsvwg@ietf.org>; Mon, 11 Mar 2019 12:26:20 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=bwjCOsIdxV1a0dFckuuKE1U0Bog=; b=hHwwB3 hd9WMkOv0/1HcWVWvqHWIsiM2u2upqVoWgUcDHVyoNe3pDAPTsKlzrxE9t1jK7Ei 0WNDv7faWG6ABZ29tKUguEMByG6iVQ9kX62jxOljDTHSk1Ip5bQp2d4RDK2oqnKT lt0krpVD+TMQR+oOGPZ+njEcXEFMPptlT+fm0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=gaL26FmaBWzm2VGMxYZXpEbnZyHKndHp SFbgAvw7KlCcC/e+OBNxGxsD8wYDty4oXt7yXEcQR3Yvmd/OMzkMaYGJEXKebjOG Do71JI55MbP7stAgBWxnG+dJ4U0fpuKZct7cv6103FSys/36sIpS/tgHSA3mPfbS 1lCtmEjAKHA=
Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 6869C5EBD0 for <tsvwg@ietf.org>; Mon, 11 Mar 2019 12:26:20 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-it1-f178.google.com (unknown [209.85.166.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 08F275EBCF for <tsvwg@ietf.org>; Mon, 11 Mar 2019 12:26:18 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-it1-f178.google.com with SMTP id w18so8235031itj.4 for <tsvwg@ietf.org>; Mon, 11 Mar 2019 09:26:18 -0700 (PDT)
X-Gm-Message-State: APjAAAXV4bArFbNeK4cAjkgsgmPO3in7+z0uIhdxzaslLuYgXZ9EwUXI df6m8UU+VHAmihwDYhabqo/WwuRs24eLQ94A09o=
X-Google-Smtp-Source: APXvYqzVaoNT2FO2Uv6rgy7CafSdEa9U+0nV048Z/UAMaoUblwPsIACyqWGeOgmPCq2oIGQ0tPUqwcoeK3hIeTedR+k=
X-Received: by 2002:a24:5647:: with SMTP id o68mr317544itb.151.1552321576728; Mon, 11 Mar 2019 09:26:16 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VFg-EWCYHZ4+kYV30vjNzPs90ysAu5SCdLNb+9OPxE+3g@mail.gmail.com> <B1D19ABC-428B-42D8-AE97-BF3B967B1140@strayalpha.com> <f95fb11b44f5d628ba85ede7d9feccf7@erg.abdn.ac.uk> <136FF703-4DFE-4B32-A722-67122F28C894@strayalpha.com>
In-Reply-To: <136FF703-4DFE-4B32-A722-67122F28C894@strayalpha.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Mon, 11 Mar 2019 09:26:04 -0700
X-Gmail-Original-Message-ID: <CACL_3VGp48nu_CRPTKTRnVkEpc=PAK05jQ8zKBoqpWSMxHnihg@mail.gmail.com>
Message-ID: <CACL_3VGp48nu_CRPTKTRnVkEpc=PAK05jQ8zKBoqpWSMxHnihg@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>, tsvwg <tsvwg@ietf.org>
Cc: Raffaele Zullo <raffaele@erg.abdn.ac.uk>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Tom Jones <tom@erg.abdn.ac.uk>
Content-Type: multipart/alternative; boundary="0000000000002883570583d40829"
X-Pobox-Relay-ID: 65DFA8F0-441A-11E9-8AFC-D01F9763A999-06080547!pb-smtp20.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/JZ8ohgwMs9eRPRQ6KJDqUZTJxSk>
Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07
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, 11 Mar 2019 16:26:33 -0000
On Sat, 9 Mar 2019 11:28:57 -0800 Joe Touch wrote: > > This one’s a bit long - we need to converge quickly if the draft is going > to be updated in time for the cutoff. > > Please comment asap… > > Joe > > PS = yes, we talk about TLV but need to explain that some options are > exceptions (OCS, NOP, EOL). I also need to update the OCS to be 3 bytes > long (in the table and figure). Those are in addition to the issues below. > > ------- > > Raffaelo and Mike both pointed out: > > > On Mar 9, 2019, at 5:23 AM, C. M. Heard <heard@pobox.com> wrote: > > ... > > the errant middleboxes that CCO is designed to work around do not use the > > correct length value in their (re)computation of the UDP checksum. ... > > Well, there are several implications here: > > 1. we can add in the option length, BUT that also means: > (a) we need to declare that the option area consumes the whole of > the surplus area (no chance for other uses) > OR > (b) that the surplus area is always zero > OR > (c) that OCS covers even the surplus area (it doesn’t need to be > zero; it does need to be included) > > we need a choice here. AFAICT, the safest (a) I agree with that. > 2. we don’t need OCS alignment; what we do need is to “coordinate” the alignment of a 16-bit of the length to the OCS checksum field > i.e.: > - calculate the length needed (IPlen - UDP len) > - if OCS checksum field is not 16-bit aligned to the start of the > option area, then swap bytes > - add the result to the OCS checksum (‘pseudo header’ seems a bit > heavy here, but same point) I believe that is correct. Padding could still be convenient, though, and I see no reason to disallow it (the current draft does permit padding for alignment). > As Derek noted: > > As I recall the LITE+FRAG use case has no data in the UDP payload > > (i.e UDP header length is zero)? > > > > For this case, there is another way to work around a broken path (be it > > boxes, NICs, or whatever), that is simply to send with UDP header checksum > > of zero, and contain any necessary checksums in the UDP slack space. > > > 3. we have to deal with LITE/LITE+FRAG > we *can* use UDP CS=0, but that also may involve overriding the > user’s desires here (i.e., the user API says “use UDP CS” and we’re > not doing that) which means we have a choice: > (d) override so that things work, i.e., force UDP CS=0 and then > (d.1) do OCS as a check on our stuff only > OR > (d.2) disallow the use of OCS (if CS=0, what’s the point?) > OR > (d.3) use OCS=0 (this seems like a waste) > OR > (e) ignore the user setting of CS, then: > (e.1) always do OCS as a check > OR > (e.2) if UDP CS=0, omit OCS (save space), basically like d.2 > OR > (e.3) if UDP CS=0, use OCS=0 (basically like e.2 > > If we do any of the (e) variants, we could either: > (f.1) require users to disable UDP CS to use OCS > OR > (f.2) ignore the user UDP CS setting > > So which is it? > > I don’t like assuming user correct configuration (f.1). > > So to me it’s (f.2) and (d.1). > > Thoughts? I'm skeptical about this proposal, because it requires making a for how OCS is calculated for the specific case of LITE+FRAG, and there are all manner of corner cases that will make that difficult to draft. In addition, the UDP header itself would not be covered by a checksum, irrespective of the user UDP CS setting. I'd like to float a different idea, namely, putting the UDP user data inside the FRAG option itself. Terminal and non-terminal FRAG options would need to be distinguished in some manner other than the Length field; one way is to allocate different Kind code points, as shown below. +--------+--------+--------+--------+ | Kind=X |Len=8+k | Frag. Offset | +--------+--------+--------+--------+ | Identification | +--------+--------+--------+--------+ ... ... | User Data | ... ... +--------+--------+--------+--------+ UDP non-terminal FRAG option format +--------+--------+--------+--------+ | Kind=Y |Len=10+k| Frag. Offset | +--------+--------+--------+--------+ | Identification | +--------+--------+--------+--------+ ... ... | User Data | ... ... +--------+--------+--------+--------+ | Checksum | +--------+--------+ UDP terminal FRAG option format The following requirements would apply: >> A host that wishes to signal that it is able to accept and process the FRAG option MAY do so by transmitting an unfragmented datagram with an empty terminal FRAG option with Offset zero and length 12. >> Non-empty FRAG options MUST NOT be present in packets with ordinary UDP user data. Any such options MUST be silently dropped. >> UDP options other than OCS and padding MUST NOT accompany the FRAG option in non-terminal fragments. Any such options MUST be silently dropped. All other options that apply to a reassembled packet must accompany the FRAG header in the terminal fragment. My thinking is that if user UDP CS setting specifies that the UDP checksum should be zero, then OCS would not accompany the FRAG option. Otherwise it would, irrespective of the user OCS setting. It is true there is the potential for excess work when the user UDP CS setting is non-zero, because there are checksums that cover both the individual fragments and the reassembled UDP datagram. However, most of that work can be avoided by a well-designed implementation that caches partial checksums during the reassembly process and sums those to calculate the overall checksum. Alternatively, one could omit the overall checksum in terminal FRAG options. Since there is a looming submission deadline, it may be better to develop this proposal further on the mailing list before putting it into a draft. > also Derek noted: > > > The OCS/CCO case can cover that, except for the LITE (w/o FRAG) case. > > > > For the latter I guess we could also use UDP checksum of zero, and have > > an option to restore a proper checksum for the UDP data at the receiver, > > however that will still leave legacy receivers experiencing such packets > > as unchecksumed. > > > 5. the LITE only case ... > > IMO, we leave this one alone. [... T]here are three points to LITE: > > 1. less work for the transmitter (which your proposal defeats) > 2. less work for the receiver (which your proposal maintains) > 3. deliver potentially corrupted data (one of the original points of > UDP-lite - it wasn’t just about performance) > > These errant middle boxes are also thus defeating #3. > > So, IMO, in the presence of those sorts of things, basically LITE with our > proposal doesn’t do most of what it was intended. I agree with this. My take is that if LITE is to remain in the spec, then it should not be covered by OCS. The workaround would defeat its purpose. Mike Heard
- [tsvwg] OCS option in draft-ietf-tsvwg-udp-option… C. M. Heard
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Joe Touch
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Raffaele Zullo
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Joe Touch
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… C. M. Heard
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Raffaele Zullo
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… C. M. Heard
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Derek Fawcus
- [tsvwg] LITE+FRAG UDP CS=0 (was Re: OCS option in… Derek Fawcus
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Joe Touch
- Re: [tsvwg] LITE+FRAG UDP CS=0 (was Re: OCS optio… Joe Touch
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Joe Touch
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Raffaele Zullo
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Raffaele Zullo
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Joe Touch
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Joe Touch
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Raffaele Zullo
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Joe Touch
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… C. M. Heard
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Joe Touch
- Re: [tsvwg] Alternative version of the UDP FRAG o… C. M. Heard
- Re: [tsvwg] Alternative version of the UDP FRAG o… Joe Touch
- Re: [tsvwg] Alternative version of the UDP FRAG o… C. M. Heard
- Re: [tsvwg] Alternative version of the UDP FRAG o… Joe Touch
- Re: [tsvwg] Alternative version of the UDP FRAG o… C. M. Heard
- Re: [tsvwg] Alternative version of the UDP FRAG o… Tom Herbert
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Raffaele Zullo
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Tom Herbert
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Raffaele Zullo
- Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-op… Tom Herbert