Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-03.txt

From: [email-masked]
Date: Fri, 25 Feb 2022 03:30:31 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Datagram PLPMTUD for UDP Options
        Authors         : Godred Fairhurst
                          Tom Jones
	Filename        : draft-ietf-tsvwg-udp-options-dplpmtud-03.txt
	Pages           : 12
	Date            : 2022-02-25

Abstract:
   This document specifies how a UDP Options sender implements Datagram
   Packetization Layer Path Maximum Transmission Unit Discovery
   (DPLPMTUD) as a robust method for Path Maximum Transmission Unit
   discovery.  This method uses the UDP Options packetization layer.  It
   allows a datagram application to discover the largest size of
   datagram that can be sent across a specific network path.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-dplpmtud-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-dplpmtud-03

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: <[email-masked]>
Date: Mon, 28 Feb 2022 10:52:24 +0000

Hi Gorry,

Thank you for taking care of the comments. I like in particular how you recorded the outcome of the nonce discussion in the security section. I consider that all my previous comments are adequately addressed. 

One last comment in reference to this part from the udp-options spec (which covers RES/REQ): 

==
   >> All other options (without a "*") MAY be implemented, and their
   use SHOULD be determined either out-of-band or negotiated.
==

I wonder whether it is useful to be explicit how retransmission is managed by the sender when no response is received from a peer. 

Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce <[email-masked]> De la part de
> [email-masked]
> Envoyé : vendredi 25 février 2022 12:31
> À : [email-masked]
> Cc : [email-masked]
> Objet : I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-03.txt
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 28 Feb 2022 12:33:15 +0000

> I wonder whether it is useful to be explicit how retransmission is managed by the sender when no response is received from a peer.

Med, I'm not sure what you suggest this time, so this not be the answer 
you are asking ...

While a UDP application could itself retransmit (some) datagrams that it 
somehow determined to be lost, I don't think there is any single 
approach, and so I'd prefer to suggest that the easy approach to 
DPLPMTUD is not to send a probe with any application data, or at least 
not with any data that needs to be reliably sent.

The DPLPMTUD probes themselves are not really retransmitted, rather, if 
a probe times-out or is discovered lost, then a new probe is then 
scheduled. This could have the same size, or the next size chosen.  It 
will have new token.

What text might be helpful to add?

Gorry

---

From: <[email-masked]>
Date: Tue, 1 Mar 2022 07:46:05 +0000

Hi Gorry, 

(1) Sorry for not being explicit, the question was whether we need some more details about how the SHOULD part is followed in the spec (especially when no RES is received from the peer). For example, if we leave it to an application/sender to decide when to stop sending probes for which it does not receive RES, the text should be explicit about this.  

The case when the options are supported is already covered: 

   "This also confirms that the remote receiver
   supports use of the RES and REQ Options."

(2) The application data approach you mentioned is already covered in 4.2.2, but I think should also be mentioned in 4.2.1.   

Thank you. 

Cheers,
Med

> De : Gorry Fairhurst <[email-masked]>
> Envoyé : lundi 28 février 2022 13:33
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
> [email-masked]
> Objet : Re: I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-03.txt
> 
> > Thank you for taking care of the comments. I like in particular how
> you recorded the outcome of the nonce discussion in the security
> section. I consider that all my previous comments are adequately
> addressed.
> >
> > I wonder whether it is useful to be explicit how retransmission is
> managed by the sender when no response is received from a peer.
> 
> >> [email-masked] Envoyé : vendredi 25 février 2022 12:31 À :
> >> [email-masked] Cc : [email-masked] Objet : I-D Action:
> >> draft-ietf-tsvwg-udp-options-dplpmtud-03.txt
> >>
> >>
> >> This draft is a work item of the Transport Area Working Group WG of
> the
> >> IETF.
> >>
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-
> dplpmtud-
> >> 03
> >>
> >>
> >> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-
> >> drafts
> >>
> >>
> ________________________________________________________________________
> _________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or
> privileged information that may be protected by law;