Re: [tsvwg] UDP options and header-data split (zero copy)

Tom Herbert <tom@herbertland.com> Sun, 01 August 2021 22:39 UTC

Return-Path: <tom@herbertland.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 0A5893A1615 for <tsvwg@ietfa.amsl.com>; Sun, 1 Aug 2021 15:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 i40dFi99oLbW for <tsvwg@ietfa.amsl.com>; Sun, 1 Aug 2021 15:39:28 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D003A15DC for <tsvwg@ietf.org>; Sun, 1 Aug 2021 15:39:27 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id go31so27712485ejc.6 for <tsvwg@ietf.org>; Sun, 01 Aug 2021 15:39:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=17QEGOAWZ30V9VT60p9E7RLKZFmqAbdbDH/LWdVslG4=; b=EDMolfD+EJVSKyRbh0gXlD2qNMZqEwxJ4HnSZxO491y+B8miTBIT+1ZW3WPBFjr6w8 tuOln9uH3E3AaCV4kYN4VKz598g2vL5PDev6a7lSTh2fa9LzF8LHy/C4CU/spW+235q6 VFGSRizi2AefuDmNqiyuTpVP9no/thnE9rvQhkw6Es65DU21F7cfTDKfi2s0SfpvuMxL BoHxiDh8L8lOhtlSbzx11+9yw1PaelX0fsuHM5MeirDUn0bV1RUb+bi9SZhTH0nGUuvt dj3UE3TVfI5fZkk44UappNHriCAkS4u4dtLAoStcCeI+OE/9ad4Jx4ULET4U/9F1nwSy UsXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=17QEGOAWZ30V9VT60p9E7RLKZFmqAbdbDH/LWdVslG4=; b=Quf1d6wDP6GOiIc9E2SzIuTg6O9LRoLzw6kW8emQ3Rele2e6XPRdzbkzPTJ9C8KFuk Yj6u0DnNkTCB9eaYAPEolgTVrrwqQ5Zic+4npiMsbaq6gVBn7mA+30CajVO1GfewVAbT 4FJY40IwZQL2vzUczJn4uXFZeewIXDac0cpL7OZA+jNBWe6wS0wGh4kVBLl00oVm8F8g gFTzFgHB7136DZeXFd2hiB4vtFru0oSD9d9xJcUT155/tudaguVksUcIXSEu8PZU+hpt 2Ey5OVpslqFw600t+3nly9zM+v/DQjkvX91paw/fhXjzUuac0V2k76AptMi6ZfnlhnvM G6bw==
X-Gm-Message-State: AOAM531FrSq8ozsiy2UZ9HJt2PWb7dBWamNXJyi/qB1ftp373hQFrBKE u5QXUK7/YFMtp58aN7EqgnXIol1zlHLFk9sLebfwBw==
X-Google-Smtp-Source: ABdhPJzpniQkZ9Xy/4QMWg6dMOM/jnVn6s8JdtnHOPjLZ0/qfoKmpd1lZBlfxB8JHIz5u+CQMJ2E6ahMjfe6Sa+Se9c=
X-Received: by 2002:a17:907:2719:: with SMTP id w25mr12888835ejk.239.1627857565536; Sun, 01 Aug 2021 15:39:25 -0700 (PDT)
MIME-Version: 1.0
References: <058C1360-D1BF-4C15-A0E3-D1C98DC8C45F@lurchi.franken.de> <04C250F8-7C10-4300-862B-7FFD739CA8B3@strayalpha.com> <C65F0BB6-BA2D-49F3-A473-32EEDF6C9467@lurchi.franken.de>
In-Reply-To: <C65F0BB6-BA2D-49F3-A473-32EEDF6C9467@lurchi.franken.de>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 01 Aug 2021 15:39:14 -0700
Message-ID: <CALx6S36a66Ty6EUa9nRdvSQjaxepA7g1Np5T16iXuoTC3ZCd+g@mail.gmail.com>
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>
Cc: Joe Touch <touch@strayalpha.com>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1TTAiOqA8ij9qbNTbFsymkwBD0A>
Subject: Re: [tsvwg] UDP options and header-data split (zero copy)
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: Sun, 01 Aug 2021 22:39:33 -0000

There is also RFC9000:

"QUIC assumes a minimum IP packet size of at least 1280 bytes.  This
is the IPv6 minimum size [IPv6] and is also supported by most modern
IPv4 networks.  Assuming the minimum IP header size of 40 bytes for
IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this
results in a maximum datagram size of 1232 bytes for IPv6 and 1252
bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths are
expected to be able to support QUIC."

and

"This requirement to support a UDP payload of 1200 bytes limits the
space available for IPv6 extension headers to 32  bytes or IPv4
options to 52 bytes if the path only supports the IPv6 minimum MTU of
1280 bytes.  This affects Initial packets and path validation."

If UDP options were used with QUIC, these limits would be applicable
to UDP options as well, i.e. 32 bytes of UDP options for IPv6, 52
bytes for IPv4 at least for initial packets and path validation.


On Sun, Aug 1, 2021 at 3:22 PM Michael Tuexen
<michael.tuexen@lurchi.franken.de> wrote:
>
> > On 2. Aug 2021, at 00:14, Joe Touch <touch@strayalpha.com> wrote:
> >
> > Right, but for UDP the receive MTU is the one we care about.
> Ahh, OK.
>
> Best regards
> Michael
> >
> > Joe
> >
> >> On Aug 1, 2021, at 3:05 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> >>
> >> 
> >>>
> >>> On 1. Aug 2021, at 23:43, Tom Herbert <tom@herbertland.com> wrote:
> >>>
> >>>> On Sun, Aug 1, 2021 at 2:24 PM Joseph Touch <touch@strayalpha.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Aug 1, 2021, at 2:19 PM, Tom Herbert <tom@herbertland.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Sun, Aug 1, 2021, 12:42 PM Joseph Touch <touch@strayalpha.com> wrote:
> >>>>>
> >>>>>
> >>>>> ...
> >>>>> Had we limited the option length as a few suggested when this work started, we would not have FRAG.
> >>>>>
> >>>>> We don’t know what others are, but we also don’t know that the first frag will have hundreds of bytes of available space either.
> >>>>
> >>>>
> >>>> Actually, we do know that. The minimum MTU in IPv6 is 1280 and the minimum MTU for IPv4 is 576.
> >>>>
> >>>>
> >>>> The min MTU for IPv4 is 68..
> >>>
> >>> Per RFC791 it's 576 bytes.
> >> RFC 791 makes a requirement on the receiver, not on the links.
> >>
> >> Page 25 of RFC 791 reads:
> >>
> >>   Every internet module must be able to forward a datagram of 68
> >>   octets without further fragmentation.  This is because an internet
> >>   header may be up to 60 octets, and the minimum fragment is 8 octets.
> >>
> >> Therefore, the min MTU for IPv4 is 68.
> >>
> >> Best regards
> >> Michael
> >>>
> >>>>
> >>>> If someone we're so inclined they could fill up the first fragment packet with nothing but options and start the payload in the second. That means you'll have at least 520 bytes for options.
> >>>>
> >>>>
> >>>> That includes BOTH per-fragment and per-reassembled datagram options.
> >>>>
> >>>> But all this is academic since there's no use case other than DoS attack that would need anything close to that much space.
> >>>>
> >>>>
> >>>> That was true until FRAG too.
> >>>>
> >>>> Again, this is a new decision - to limit the option space.
> >>>
> >>> I don't know what that means.
> >>>
> >>>>
> >>>> Joe
> >>>
> >>
> >
>