Re: [tsvwg] UDP TIME Option - per segment or per datagram

"C. M. Heard" <> Fri, 30 July 2021 23:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2C523A153A for <>; Fri, 30 Jul 2021 16:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Status: No, score=-2.798 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qn-pv21Oq1oB for <>; Fri, 30 Jul 2021 16:06:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A3793A1539 for <>; Fri, 30 Jul 2021 16:06:50 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 666EFEAA0A for <>; Fri, 30 Jul 2021 19:06:46 -0400 (EDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed;; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=kGBrVhSZZxe4FAKxTfSS9lA7egNhX2Y+ ua0jQHk2qEM=; b=LDI/6/ml64MLn5NVYCvMIxITH5k9d5BXMyZ8SI1xGNJmJoLS W1KO/7AAPnTejz/ZJO44Sn+18+B/t3N5Xsrz4BXpp0VD/tSQUNper6Vysa1qMNVk 6HqoSat49HAsFMe/ArzE8jpq1JDLbG5B+rGwQqBBs2CjjVUDHLVCu7dpx04=
Received: from (unknown []) by (Postfix) with ESMTP id 5E289EAA09 for <>; Fri, 30 Jul 2021 19:06:46 -0400 (EDT) (envelope-from
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 944C4EAA08 for <>; Fri, 30 Jul 2021 19:06:45 -0400 (EDT) (envelope-from
Received: by with SMTP id t21so12804528plr.13 for <>; Fri, 30 Jul 2021 16:06:45 -0700 (PDT)
X-Gm-Message-State: AOAM533MEmNjl3dTghilL4l5RTABwdZ2aiTzgoFQKS/0eb1/JWbD3VFC 2wfDf/IV7RCXMkBvcEiWe3okfpYZsa+tsi5dlMk=
X-Google-Smtp-Source: ABdhPJzlFDcLOQG9NtKEUb7UTATHH2o/UYjZciqqxZD2y0bhpdGDnM1UDDSC111pI165bUGEyjRUTiulasZ8zeySG/w=
X-Received: by 2002:a17:902:a702:b029:12b:aa0f:d553 with SMTP id w2-20020a170902a702b029012baa0fd553mr4518427plq.3.1627686404706; Fri, 30 Jul 2021 16:06:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: "C. M. Heard" <>
Date: Fri, 30 Jul 2021 16:06:33 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Joseph Touch <>
Cc: TSVWG <>
Content-Type: multipart/alternative; boundary="000000000000f556a105c85f45e4"
X-Pobox-Relay-ID: CFA221EE-F18A-11EB-B6CC-FD8818BA3BAF-06080547!
Archived-At: <>
Subject: Re: [tsvwg] UDP TIME Option - per segment or per datagram
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Jul 2021 23:07:01 -0000

On Wed, Jul 7, 2021 at 9:44 PM Joseph Touch wrote:

> Hi, Mike,
> I’ll try to take this in one shot, but it might be useful to followup in
> separate threads.

I am following up in separate threads as suggested. This one is for the
TIME option.

On Jun 26, 2021, at 4:53 PM, C. M. Heard wrote:
> If TIME can be requested by the upper layer, what is the meaning if the
> option is requested for a datagram that gets split into multiple fragments,
> and the option is replicated in every fragment? I can see the per-fragment
> argument but only when the option is produced and consumed at the UDP layer
> -- as is the case for the corresponding TCP option (which appears on every
> segment if it is negotiated). If it's intended to be produced and consumed
> by the higher layer, it should be per-datagram.
> Time for fragmented packets can be a sequence of values or (depending on
> whether the API might support this) a range (high/low). That information
> can be useful to the higher layer in setting parameters of UDP, e.g., how
> long to keep fragments before discard. Or it could be used within the UDP
> layer for that sort of tuning automatically.

In order to get a better understanding of how this would be used I read RFC
1323, which describes the TCP Timestamps Option (TSopt), on which this is
modelled. A couple of things jumped out at me:

1. TSecr is not valid in TCP unless the ACK bit is set in the segment that
carries it:

         The Timestamp Echo Reply field (TSecr) is only valid if the ACK
         bit is set in the TCP header; if it is valid, it echos a times-
         tamp value that was sent by the remote TCP in the TSval field
         of a Timestamps option.  When TSecr is not valid, its value
         must be zero.  The TSecr value will generally be from the most
         recent Timestamp option that was received; however, there are
         exceptions that are explained below.

2. RFC 1232 Section 3.4 provides specific and detailed rules on which
timestamp to echo if more than one is outstanding. The rules are highly
dependent on TCP state.

UDP, of course, has no defined state, and no defined ACK bit, though
stateful protocols with acknowledgments can be defined on top of UCP.  That
suggests to me that the use of TIME -- including which segments carry valid
TSecr values -- would necessarily be dependent on the protocol running on
top of UDP. In other words, all use of this option must be in the hands of
the protocol running on top of UDP, and would depend on the characteristics
of that protocol, including on which messages TSecr is valid.

In my view, if the UDP options spec provides a fragmentation and reassembly
capability, it would be a grievous error to provide visibility to what
happens to individual UDP fragments to the protocol running on top of UDP
-- just as IP does not provide visibility to what happens to individual IP
fragments to the protocol running on top of IP.

That would imply that TIME is a per-datagram option.

Additionally, while it is fair to require that TSecr is zero on datagrams
where it is invalid by the rules of the protocol running on top of UDP, it
seems IMO an unnecessary complication in the usage of the option to reserve
the value zero to indicate an invalid TSecr. That isn't done in RFC 1323
("when TSecr is not valid, its value must be zero" does not imply "when the
TSecr value is zero, it is not valid").

Mike Heard