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

[Joseph Touch <[e-mail]>]

Hi, all,


> On Mar 22, 2021, at 2:04 AM, [e-mail] wrote:
> 
>> On 22. Mar 2021, at 07:42, <[e-mail]> <[e-mail]> wrote:
>> 
>> 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]).
> Hi Med,
> 
> let me try to get my point clear:
> 
> You can use Section 3.3.3 of [RFC1122] to motivate that the sender shou
> 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).

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