IETF Logo Mail Archive

Re: [tsvwg] Alternative version of the UDP FRAG option

Derek Fawcus <dfawcus+lists-tsvwg@employees.org> Tue, 19 March 2019 23:13 UTC

Return-Path: <dfawcus@employees.org>
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 B31A9124B91 for <tsvwg@ietfa.amsl.com>; Tue, 19 Mar 2019 16:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Pr2TQln_xunN for <tsvwg@ietfa.amsl.com>; Tue, 19 Mar 2019 16:13:10 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590F512008F for <tsvwg@ietf.org>; Tue, 19 Mar 2019 16:13:10 -0700 (PDT)
Received: by bugle.employees.org (Postfix, from userid 1736) id 5319CFECC08F; Tue, 19 Mar 2019 23:13:09 +0000 (UTC)
Date: Wed, 20 Mar 2019 00:13:09 +0100
From: Derek Fawcus <dfawcus+lists-tsvwg@employees.org>
To: tsvwg <tsvwg@ietf.org>
Message-ID: <20190319231309.GA38527@bugle.employees.org>
References: <CALx6S37MsCmOOsn0bnHoTwJkN7Khfm03z__W4hhy7c29XuvQHw@mail.gmail.com> <5C8FDEED.8010701@erg.abdn.ac.uk> <CALx6S36fQcRdgvCG3XS78EecFjdb36D22iBzovXcODH_W+BHbg@mail.gmail.com> <5be88c76-d65a-c491-86be-74a52fef7687@strayalpha.com> <CALx6S35h+ANRpqrEyC97JocXUrDw_+b85a8bP7QgjSchMPXF-g@mail.gmail.com> <62f9f885-5dd6-78d4-2d8a-8fab83871529@strayalpha.com> <CALx6S35bb5YpjR16OfQN+JJw3O3LG=NqkdFEnKdTEd3UoZWo5A@mail.gmail.com> <190BFA86-2DE3-4BB1-A833-E67D49B641FB@strayalpha.com> <CALx6S35vym9jfN5E6HVLU5RJj0k2p0i=dc1a+pb=ETx1WQUoxg@mail.gmail.com> <57E0E8CF-EA9A-4BC8-89D2-296D3CBBF7BA@strayalpha.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <57E0E8CF-EA9A-4BC8-89D2-296D3CBBF7BA@strayalpha.com>
User-Agent: Mutt/1.11.1 (2018-12-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/SA9gsQGm-pivH_kveWMLbS58-Fs>
Subject: Re: [tsvwg] Alternative version of the UDP FRAG option
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: Tue, 19 Mar 2019 23:13:12 -0000

On Mon, Mar 18, 2019 at 08:52:54PM -0700, Joe Touch wrote:

[snip - Various statements about the behaviour of legacy receivers]

I have to agree with all of that.

Also the statement which another (I forget who) made about this not
being an encap layer for other arbitrary protocols, so not a layer
over which to lay UDPv2.

We have the DNS request use case, we want to be able to send a packet
containing options expressing that we can receive Segmented UDP data.

A legacy stack, or legacy server on a new stack will not see those
options, but will reply to the basic UDP packet - possibly generating
an IP fragmented response.  A new server on a new stack will be able
to send a UDP segmented response.

There could well be other examples falling in to that scenario.

DF

v2.23.0 | Report a Bug | By Email