IETF Logo Mail Archive

Re: [Ntp] Is the real MTU still 576?

Daniel Franke <dfoxfranke@gmail.com> Mon, 15 June 2020 14:42 UTC

Return-Path: <dfoxfranke@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981173A0DD3 for <ntp@ietfa.amsl.com>; Mon, 15 Jun 2020 07:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 E77G_t2Hai5w for <ntp@ietfa.amsl.com>; Mon, 15 Jun 2020 07:42:12 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 EEE723A0DCC for <ntp@ietf.org>; Mon, 15 Jun 2020 07:42:11 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id t8so15481587ilm.7 for <ntp@ietf.org>; Mon, 15 Jun 2020 07:42:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bqKmZkh5ndCgyrbrBtFvOXNz3AMUTtQ2UjWhF+vrfQE=; b=fowk0mK9nCJ5u5CLlsGSYtWm5giCsQuCbiMuUdLoNmTEx+AYsfftzNELbe51uRFx0t X53bSdJa9vl0X3F6ZxyQc82B0aMeLvrh6Z14eYI0lBdvQA7A9gWQogVHgCwvoOvWbkti Xp169GBeZKLDH3jDD3xKh8bejZGrWU/p/CU+mWl8VGo4zVMNctR9pTzR94eu+EI/FV/n Lr2ypldf1aVNFRAkEkM87X4d0KbloB9CPPw91pZmatsW4nIKlIohWAN9pHvuo/lCchQD W7m49kpweFH3uKAMgD3WskgvX9yFzdz63zox7QUoSIeRxqrm7NIBInTwmvNP3Yldfc++ Yb7w==
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; bh=bqKmZkh5ndCgyrbrBtFvOXNz3AMUTtQ2UjWhF+vrfQE=; b=Mph8IuphMZd9StSqJ5K8o4epeaJ+F6FV/cdXQJunSXD0HzZM0yCGTvLdpa6apR3xb8 33aJXIDLni7BskejnXspC+IpG2C5pdnpJDvHyZaxPlHQmU09Rum/ag1tv5O8b2qlKUKZ 2D2mWaCQzM7NRAdLyW2Zk0buZR6McN0UpvQVvgIuNeEx0McoXQHHqu4TmqqwAij7Tjtu D27JHSBY8nS6CW1P+kSD+8t6mVtXWytSsAZbEwRl9YEWFuwV+i87Em8lI03YqeDwkvZl 3Cnis4e5RtvJIuQoPhYQBjbqUJ3FLkKGJIZvSv/PtDGk02Def+GYRYQPOpq2om7HBZO/ kITA==
X-Gm-Message-State: AOAM532M9189GxbLvdjAF+/Q5biHK/n3YxnNqB35Dz5n6GCZSJ3IiloF 0hilSO62Np7XfdcUPPGdZhC2C5LhgWFSEvAWqGirvA==
X-Google-Smtp-Source: ABdhPJzakDJeAWTYRNouLwSlkhEHuJwIZVFNmZC3YNZaf6kiCkkgghUb97ZDuhVlf83SEmSpOtS9uYkcY5TZ3t4f45g=
X-Received: by 2002:a05:6e02:be8:: with SMTP id d8mr25912345ilu.32.1592232131116; Mon, 15 Jun 2020 07:42:11 -0700 (PDT)
MIME-Version: 1.0
References: <20200615005222.0D6A040605C@ip-64-139-1-69.sjc.megapath.net>
In-Reply-To: <20200615005222.0D6A040605C@ip-64-139-1-69.sjc.megapath.net>
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Mon, 15 Jun 2020 10:42:00 -0400
Message-ID: <CAJm83bApAiULep7wXpE9e5EVZr8b93sN_1orRyOXCWM_BgLVWA@mail.gmail.com>
To: Hal Murray <hmurray@megapathdsl.net>
Cc: NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000093439a05a8206e60"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/2rwH6dCqIfIsOM4zuz4vLEjSvHA>
Subject: Re: [Ntp] Is the real MTU still 576?
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2020 14:42:14 -0000

Support for 1500 bytes or more at the link layer is pretty much universal,
but that includes IP and UDP headers so for the application you have less
than that. Those headers may contain options so you can't assume they'll be
some particular size, and you may have multiple layers of them due to VPN
tunneling, leaving an MTU of less than 1500 bytes for the innermost layer.
What's ultimately left over for the application payload is the "segment
size", rather than the "transmission unit".

The only "correct" option if you want to go beyond the minimum MTU is to
use path MTU discovery, but for a stateless protocol like NTP that's not
really practical, at least not for servers. IPv6 mandates a minimum MTU of
1280 bytes. Again that's an MTU, not an MSS, but nonetheless it's very rare
that a 1280-byte segment would get fragmented, no matter whether it's going
over IPv4 or IPv6. I think "MSS is probably at least 1280" makes a good
rule of thumb whenever PMTUD isn't practical.

On Sun, Jun 14, 2020 at 8:52 PM Hal Murray <hmurray@megapathdsl.net> wrote:

>
> There was mention in the Roughtime discussion that the official minimum
> MTU is
> still 576.
>
> It's easy for a NTP packet using NTS to get over that.  If you drop a few
> packets, the request will have a few cookie placeholders and the response
> will
> have a few extra cookies.
>
> Is the real MTU still 576?  What fraction of the net will carry Ethernet
> size
> packets of roughly 1500 bytes?
>
> Or rather, what fraction of the net can't carry 1500 byte packets and/or
> how
> well do things work there?
>
> Cookies are roughly 100 bytes.  Should we limit requests to 3 cookie
> placeholders?  (maybe 4)
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>

v2.23.0 | Report a Bug | By Email