Subject: [Masque] Fwd: New Version Notification for draft-schwartz-masque-h3-datagram-ping-01.txt

From: Ben Schwartz <[email-masked]>
Date: Mon, 4 Oct 2021 15:37:38 -0400

Hi MASQUE,

I've updated the PING draft to work slightly differently: an even number in
the header means "ping", and an odd number (one greater) means "pong".
This avoids the need for an asymmetric datagram context as in draft-00.

I would appreciate review, especially from anyone who has been thinking
about MTU in CONNECT-IP, as that is the principal motivation for this draft.

Thanks,
Ben Schwartz

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Oct 4, 2021 at 3:34 PM
Subject: New Version Notification for
draft-schwartz-masque-h3-datagram-ping-01.txt
To: Benjamin Schwartz <[email-masked]>

A new version of I-D, draft-schwartz-masque-h3-datagram-ping-01.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:           draft-schwartz-masque-h3-datagram-ping
Revision:       01
Title:          HTTP Datagram PING
Document date:  2021-10-04
Group:          Individual Submission
Pages:          4
URL:
https://www.ietf.org/archive/id/draft-schwartz-masque-h3-datagram-ping-01.txt
Status:
https://datatracker.ietf.org/doc/draft-schwartz-masque-h3-datagram-ping/
Html:
https://www.ietf.org/archive/id/draft-schwartz-masque-h3-datagram-ping-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-schwartz-masque-h3-datagram-ping
Diff:
https://www.ietf.org/rfcdiff?url2=draft-schwartz-masque-h3-datagram-ping-01

Abstract:
   This draft defines an HTTP Datagram Format Type for measuring the
   functionality of a Datagram path.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the mailing list
   ([email-masked]), which is archived at
   https://mailarchive.ietf.org/arch/browse/masque/.

   Source for this draft and an issue tracker can be found at
   https://github.com/bemasc/h3-datagram-ping.

The IETF Secretariat

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Oct 2021 10:40:46 +1100

If an intermediary receives one of these, but cannot forward it due to MTU constraints, then that becomes indistinguishable from loss.  This is a feature because you get to do DLOHDPLPMTUD.

This assumes that forwarding is permitted.  The draft says "MUST forward" and doesn't allow for the possibility that the path is known to be too small.  Or is the expectation that the intermediary generate a QUIC packet that is too large?  I don't think that our implementation would find violating a known PMTU to be easy.

If an intermediary were instead to truncate the data and forward it on, then we might get more information about the MTU.  Do you think that it would be useful to do that instead?  That would require the response to include some information about what was received.

On Tue, Oct 5, 2021, at 06:37, Ben Schwartz wrote:
> Hi MASQUE,
>
> I've updated the PING draft to work slightly differently: an even 
> number in the header means "ping", and an odd number (one greater) 
> means "pong".  This avoids the need for an asymmetric datagram context 
> as in draft-00.
>
> -- 
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>
> Attachments:
> * smime.p7s

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 4 Oct 2021 20:36:03 -0400

On Mon, Oct 4, 2021 at 7:41 PM Martin Thomson <[email-masked]> wrote:

> If an intermediary receives one of these, but cannot forward it due to MTU
> constraints, then that becomes indistinguishable from loss.  This is a
> feature because you get to do DLOHDPLPMTUD.
>

Right.

This assumes that forwarding is permitted.  The draft says "MUST forward"
> and doesn't allow for the possibility that the path is known to be too
> small.  Or is the expectation that the intermediary generate a QUIC packet
> that is too large?  I don't think that our implementation would find
> violating a known PMTU to be easy.
>

I think this question indicates that the verbiage in the spec needs
improvement.  Instead of:

> Intermediaries MUST forward PING Datagrams without modification, just
like any other HTTP Datagram.

How about:

> Intermediaries MUST treat PING Datagrams just like any other HTTP
Datagram, forwarding the Datagram without modification or dropping it if it
cannot be forwarded.

Dropping Datagrams that would exceed the current outbound QUIC PMTU
estimate would be a perfectly valid intermediary or endpoint behavior.
(Sending "oversize" packets and letting the network drop them seems fine
too.)  The important thing is that PING Datagrams don't get special
treatment, and the intermediary's behavior is reasonably stable.

If an intermediary were instead to truncate the data and forward it on,
> then we might get more information about the MTU.  Do you think that it
> would be useful to do that instead?  That would require the response to
> include some information about what was received.
>

In the present design, Datagram Contexts are opaque and end-to-end.
Truncation is not always a safe behavior, so we would need to expose at
least one additional bit to the intermediaries, to distinguish truncatable
vs. non-truncatable Datagrams.  This moves complexity from the endpoints
(less complicated PMTUD) to the intermediaries (more complicated forwarding
behavior) and to the protocol (extra flag).

My current feeling is that we're best off keeping intermediaries as simple
as possible, as the endpoints are likely to be more motivated and agile.
Also, if any special-case logic is required, I think there's a real risk
that 5% of intermediaries don't get it right, forcing endpoints to
implement DLOHPLPMTUD anyway.  (That's what happened to IP.)

---

From: David Schinazi <[email-masked]>
Date: Mon, 4 Oct 2021 18:08:23 -0700

Thanks for writing this, Ben! I think this nicely showcases the
extensibility of HTTP Datagrams to solve a real world problem.

Magnus, since you've had thoughts about MTU for HTTP Datagrams in the past,
could you let us know what you think of Ben's proposal please?

Thanks,
David

On Mon, Oct 4, 2021 at 5:36 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

>> If an intermediary receives one of these, but cannot forward it due to
>> MTU constraints, then that becomes indistinguishable from loss.  This is a

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Oct 2021 12:16:38 +1100

On Tue, Oct 5, 2021, at 11:36, Ben Schwartz wrote:
> How about:
>
>> Intermediaries MUST treat PING Datagrams just like any other HTTP Datagram, forwarding the Datagram without modification or dropping it if it cannot be forwarded.
>
> (Sending "oversize" packets and letting the network drop them seems 
> fine too.)  The important thing is that PING Datagrams don't get 
> special treatment, and the intermediary's behavior is reasonably stable.

Sounds good to me.  Allowing oversize packets would imply special treatment, which runs counter to your goal, so let's avoid that.

(Point about truncation requiring that intermediaries be aware of contents is well taken; let's not go there just yet.)