Subject: [Last-Call] Tsvart last call review of draft-ietf-dots-rfc8782-bis-05

From: Michael Tüxen via Datatracker <[email-masked]>
Date: Sun, 21 Mar 2021 16:32:57 -0700

Reviewer: Michael Tüxen
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

>From a transport perspective, there is one minor issue:
Section 7.3 provides a motivation for using a path MTU for IPv4 of 576 bytes.
The motivation refers to the requirement that a receiver is capable of
receiving IPv4 packets of that size, however they can be received fragmented.
While it is acceptable to use 576 bytes as the minimum PMTU, the motivation
does not hold.

---

From: <[email-masked]>
Date: Mon, 22 Mar 2021 06:42:58 +0000

Hi Michael, 

Thank you for the review.

The motivation was used as it was the key element in the discussion in Section 3.3.3 of RFC1122, but you made a fair comment.

==
         DISCUSSION:
              Picking the correct datagram size to use when sending data
              is a complex topic [IP:9].

              (a)  In general, no host is required to accept an IP
                   datagram larger than 576 bytes (including header and
                   data), so a host must not send a larger datagram
                   without explicit knowledge or prior arrangement with
                   the destination host.
==

We can update the text as follows: 

OLD: 
   assume a PMTU of 576 bytes for IPv4 datagrams, as every IPv4 host
   must be capable of receiving a packet whose length is equal to 576
   bytes as discussed in [RFC0791] and [RFC1122].

NEW:
   assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3 of [RFC1122]).

Cheers,
Med

> -----Message d'origine-----
> De : Michael Tüxen via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 22 mars 2021 00:33
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; last-
> [email-masked]
> Objet : Tsvart last call review of draft-ietf-dots-rfc8782-bis-05
> 
> Reviewer: Michael Tüxen
> This document has been reviewed as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments
> were written primarily for the transport area directors, but are copied
> to the document's authors and WG to allow them to address any
> issues raised and also to the IETF discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider
> this review as part of the last-call comments they receive. Please
> always CC [email-masked] if you reply to or forward this review.
> 
> While it is acceptable to use 576 bytes as the minimum PMTU, the
> motivation does not hold.
> 

_________________________________________________________________________________________________________________________

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: [email-masked]
Date: Mon, 22 Mar 2021 10:04:17 +0100

> On 22. Mar 2021, at 07:42, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Michael, 
> 
Hi Med,

let me try to get my point clear:

You can use Section 3.3.3 of [RFC1122] to motivate that the sender should
not send datagram larger than 576, since there is no guarantee that the
receiver has resources to reassemble and process it. But RFC 1122 makes
no statement about the path. As far as I know there is no safe value for
a PMTU you can derive from a specification.

So maybe:
NEW:
  assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3 of [RFC1122]
  for support at the receiver).

Best regards
Michael

---

From: <[email-masked]>
Date: Mon, 22 Mar 2021 09:31:31 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : lundi 22 mars 2021 10:04
> À : BOUCADAIR Mohamed TGI/OLN
> <[email-masked]>
> Cc : [email-masked]; [email-masked]; draft-ietf-dots-rfc8782-
> [email-masked]; [email-masked]
> Objet : Re: Tsvart last call review of draft-ietf-dots-rfc8782-bis-05
> 
> > The motivation was used as it was the key element in the discussion
> in Section 3.3.3 of RFC1122, but you made a fair comment.
> >
> > ==
> >         DISCUSSION:
> no statement about the path. 

[Med] There is this text in RFC1122: 

              Since nearly all networks in the Internet currently
              support an MTU of 576 or greater, we strongly recommend
              the use of 576 for datagrams sent to non-local networks.

As far as I know there is no safe value
> for

[Med] I agree with you. Things are more clear for IPv6.

> >> Section 7.3 provides a motivation for using a path MTU for IPv4 of
> 576
> >> bytes.
> ______________________________________________________
> ______________________________________________________
> _____________
> >
> > 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;

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 22 Mar 2021 10:52:45 +0100

> On 22. Mar 2021, at 10:31, <[email-masked]> <[email-masked]> wrote:
> 
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
OK. Then I' fine with your proposed text.
Please note that this is a statement from 1989. It is fine if you can live with that number, I would
guess that such a number is larger today (at least in the context of WebRTC a number in the order of
1200 bytes was used).

Best regards
Michael

---

From: <[email-masked]>
Date: Mon, 22 Mar 2021 11:58:18 +0000

Re-

Thanks, Michael. 

The proposed change is now implemented in our local copy. It can be tracked at https://tinyurl.com/8782bis-latest.

Cheers,
Med

> De : Michael Tuexen [mailto:[email-masked]]
> Envoyé : lundi 22 mars 2021 10:53
> >>  assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3
> of
> >> [RFC1122]
> >>>> The motivation refers to the requirement that a receiver is
> capable
> >> of

---

From: Joseph Touch <[email-masked]>
Date: Mon, 22 Mar 2021 08:05:46 -0700

Hi, all,

> On Mar 22, 2021, at 2:04 AM, [email-masked] wrote:
> 
> You can use Section 3.3.3 of [RFC1122] to motivate that the sender shou

I agree with the assumption, but Sec 3.3.3 is not entirely clear about it being a *path* MTU, rather than EMTU_R.

Joe

Joe