Re: [tsvwg] UDP Options: on forcing the use of UDP CS=0 in connection with FRAG+LITE

Joe Touch <touch@strayalpha.com> Mon, 01 July 2019 19:27 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 B41C4120170 for <tsvwg@ietfa.amsl.com>; Mon, 1 Jul 2019 12:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level:
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 eO81uX7y5-hM for <tsvwg@ietfa.amsl.com>; Mon, 1 Jul 2019 12:27:00 -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 1AC28120169 for <tsvwg@ietf.org>; Mon, 1 Jul 2019 12:27:00 -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: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=KkNbJJc5Q4gYtPLmvOW2/p/n2MNdAgCIgl7XgEH6iLY=; b=DG7iy/N4r4x7Lzx3s5cXRTiJe DC4L5feq7/1+Z+2+615twHSonbiCLg1kDsZC/Br8XoAbjSlazMqBhn+gSKo0QTZOVFqVeVUlBxK5Y IqVn79gjzQ642pcC982TXbzWDcyafxSsoXXc7OIEO3vW1J4kz+3YC9O8j4FDW/VeBiSrV5qeU92cj aItvWuEW4YJ30HzOHOFDa6AnEA6LORqHfddEKNFaREcSMjXIlGXvkC2q4ym47tBuUTBZYSeW6W9zZ 0EsL3qH34oqe3ce3dYNAxF2GRTeC3U0dYjNGtCutFAtQnyQ8FcAHOWQUEzBoinWJV7I7OTYc8CBgX nTmYbDsyw==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60431 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1hi1wk-003UDp-Vr; Mon, 01 Jul 2019 15:26:52 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
X-Mailer: iPad Mail (16F203)
In-Reply-To: <CACL_3VExhAdFCu-kFLLO5DeRYUOFyJztUgJg-vQmnPoecvzeJg@mail.gmail.com>
Date: Mon, 01 Jul 2019 12:26:38 -0700
Cc: Tom Herbert <tom@herbertland.com>, TSVWG <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6DB954BC-8D40-4347-A172-C00FED1AE4AF@strayalpha.com>
References: <CACL_3VHGtMz3htgfFLRGhjXm=qC7kOXQs+cchtamhh-giBnpLA@mail.gmail.com> <CALx6S35T9ApzMaoSVgHSJPpcpfXsbHHogoBbEjMPj6vH-kxYeA@mail.gmail.com> <CACL_3VE6kr33Vk5si5AxSZNmhqysZZGoy6HK37COUgwbvcRkdA@mail.gmail.com> <24692A9B-4AF1-4E32-A760-7D4908A61262@strayalpha.com> <CACL_3VExhAdFCu-kFLLO5DeRYUOFyJztUgJg-vQmnPoecvzeJg@mail.gmail.com>
To: "C. M. Heard" <heard@pobox.com>
X-OutGoing-Spam-Status: No, score=-1.0
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/7CicyidZwUfK-UH85iRLlih2a00>
Subject: Re: [tsvwg] UDP Options: on forcing the use of UDP CS=0 in connection with FRAG+LITE
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, 01 Jul 2019 19:27:02 -0000


On Jul 1, 2019, at 12:16 PM, C. M. Heard <heard@pobox.com> wrote:

>> But that also means middleboxes should allow relaying these since 6936
>> was passed.
> 
> Yes. middleboxes are ***supposed*** to do that. But the empirical data
> that we have says that in a significant number of cases (affecting 26%-36%
> of the paths) they do not.

And a similar number of net people aren’t likely aware this is incorrect behavior,IMO.

But...

> It's possible that the situation will improve in the future, but given
> that it has not improved enough to make UDP CS=0 useable in other than
> controlled environments, I don't think it's a good idea to propose its
> use when we have an alternative that avoid UDP CS=0 that is no more
> complex to implement.

You haven’t addressed the data copying issue. If the proposed alternative can be achieved with fixed, small amounts of data movement, it might be viable.  But if we need to move the whole fragment, it’s not. Data coping overheads cannot be mitigated; bugs in other people’s implementations can.

Joe