IETF Logo Mail Archive

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

Joe Touch <touch@strayalpha.com> Fri, 19 July 2019 01:29 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 1B3521200E7 for <tsvwg@ietfa.amsl.com>; Thu, 18 Jul 2019 18:29:34 -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 5NLsPL7e-vCx for <tsvwg@ietfa.amsl.com>; Thu, 18 Jul 2019 18:29:32 -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 CDB6512004C for <tsvwg@ietf.org>; Thu, 18 Jul 2019 18:29:32 -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=okpD53QOVHEQGVesVaBf9plfDpNtIeK6Urj4DCwvNmE=; b=dJC1DTBCqDnEKuWtlRUr1q8UN bOME5Lt6d6sC0F1hIHTeY2CI8dSoIYXLn1vqp1Bv+x3ORbHJutZVraS6p5YiqTwPC4qRN5aGfFp6F 04KlCV9m0aMu7X9afXqGogG41EUGBr+n9y4vHlflqhpWCVsYWJPLUSAhUuSVKY1J7i8cAkofFTrrc PluK9tk+g1i/crfWHedhqHt7uPFHcjkZFAdweGb7sTBLhVJM3ZJEuZhM5E68pMJBM8HDiAP+khmsf 0aXz2M5PPJwTqp5n+IutatwkiKDKHvzG+GoGy2FGRv5RmJy4hQ6k1iQR8GO4Zfi/RXKxjORrwTMwt od+/CjxNQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61554 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 1hoHiB-002zZx-B1; Thu, 18 Jul 2019 21:29:32 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_C64B3C6E-CC72-4A8D-82B1-D045A19328D7"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <CALx6S36G3DbTB4+jdbCW3kK830kbErSG14g9SdcujREssBLaTw@mail.gmail.com>
Date: Thu, 18 Jul 2019 18:29:25 -0700
Cc: tsvwg <tsvwg@ietf.org>
Message-Id: <EEE18370-0BE2-48E1-B4EB-CDC495CFD46E@strayalpha.com>
References: <30c17e9c174f6b0da3ecc6b503a8cb17@strayalpha.com> <CACL_3VGs7j+y5vFNT3OL9OKX8ue4rv-Cxi467KR-vbhnMdx86g@mail.gmail.com> <2f71a292f924a9b8de4227c4bbc2f809@strayalpha.com> <CACL_3VGrF5UnbVsSzZZoy1i57WKiQKBX2T3a16UyEVHY=Kr3XA@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949363061EF7A@MX307CL04.corp.emc.com> <CACL_3VE7+3WD3Uzubf8X9uQX9ZYPnZVhXjheUOuL9EfjT1JkGQ@mail.gmail.com> <CALx6S35V-d3Rn_wjrhbHUHgS=_+dVjR4hbMJ0-JBsG-1BuFuZg@mail.gmail.com> <B5CCEF58-38CE-4973-9CFD-002B404E4EF3@strayalpha.com> <CACL_3VEnJoV9N9i59fJXG1Nyt=mMWT7SuB8B=C-Y9a9QLtqP7Q@mail.gmail.com> <BB3FD9A5-8D30-4600-A7A7-DA3030BD34A3@strayalpha.com> <20190718100109.GA86292@clarinet.employees.org> <718EBD34-5B4A-4458-B9B4-0A94C33E019E@strayalpha.com> <CACL_3VGL2irCkZeEcP+9HLBHqtqaMPZM66youUsatzosUu=Aew@mail.gmail.com> <A07EA390-1A3A-4AE9-AFD7-2F22CD4B0E31@strayalpha.com> <CALx6S34oOza3Z4Ymjsp+HLXnSTOKwh+SAQO8mt=a-1AbTTB0GQ@mail.gmail.com> <177233bb33272ce3b64298a005254724@strayalpha.com> <CALx6S36ZBa4Bioj=0KYn7wcFi08VeAg8sHUHLRNGURsrUN673w@mail.gmail.com> <07A2D215-6B97-4DD6-86EB-44960C1844A5@strayalpha.com> <CALx6S355=vvk1GNe959UfOnERJS6qVE19Xhes78=GHug-KpZFg@mail.gmail.com> <FB5CB7F4-C6E4-4E7A-BA3C-48F3B190D58E@strayalpha.com> <CALx6S36G3DbTB4+jdbCW3kK830kbErSG14g9SdcujREssBLaTw@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
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/35qPPWAZTUPqXmSMeeDwbIR4kLI>
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, 19 Jul 2019 01:29:34 -0000


> On Jul 18, 2019, at 2:00 PM, Tom Herbert <tom@herbertland.com> wrote:
> 
>>> I don't see what in section 7 helps, can you point the specific mechanisms.
>>> 
>>> Tom
>> 
>> Sec 7 says this - and other things- should not be done by options and why.
>> 
> So we can never add a compression option? Or for that matter an
> alternate method of fragmentation, or some sort of forward error
> correction that might touch the data?

Nothing that modifies the UDP user data, ever. No. Not unless you negotiate that, at which point it’s just like any other UDP exchange.

Options do not redefine the user data space.

> That the reason we don't have
> to worry about unknown options that can't be ignored is that we aren't
> allowed to create any new options that can't be ignored once the
> initial set is published?

Basically; the limitation is that a receiver is always legacy until you find out some other way, at some other layer. UDP doesn’t have state and we’re not adding it. At most, there’s only soft state and soft state has its limits.

> If I'm interpreting this correctly, it
> sounds awfully limiting.

We have other transports which  to play with hard state, e.g., TCP.

Joe

v2.23.0 | Report a Bug | By Email