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

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

> -----Message d'origine-----
> De : Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> Envoyé : lundi 28 février 2022 13:33
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
> tsvwg@ietf.org
> Objet : Re: I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-03.txt
> 
> On 28/02/2022 10:52, mohamed.boucadair@orange.com wrote:
> > 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.
> 
> 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
> 
> > Thanks.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : I-D-Announce <i-d-announce-bounces@ietf.org> De la part de
> >> internet-drafts@ietf.org Envoyé : vendredi 25 février 2022 12:31 À :
> >> i-d-announce@ietf.org Cc : tsvwg@ietf.org Objet : I-D Action:
> >> draft-ietf-tsvwg-udp-options-dplpmtud-03.txt
> >>
> >>
> >> 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
> >>
> >>
> >> _______________________________________________
> >> I-D-Announce mailing list
> >> I-D-Announce@ietf.org
> >> 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.
> 

_________________________________________________________________________________________________________________________

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.