Hi Markku,
Thanks for your message below!
Your message is timely, as we are at an earlier stage of the document
process. (I understand that the shepherd writeup still needs to be
prepared, and the document has not yet been evaluated by the IESG.)
In the next update of the draft, we will add the reference and will edit
the text as per your suggestion.
Once again, thanks a lot for your contributions to this document!
Cheers,
Carles
> Hi Carles, All
>
> thanks again for your work on this!
>
> This seems still about to be advanced to publication in the process, so
> there is one reference that I just noted and that I (and others) missed
> earlier, and that you might want to add to this doc once it appears to
> auth48.
>
> It's related to my earlier comment on Sec 4.1.1 (see below):
>
> In addition, to my understanding TCP implementations typically
> address
> the presence of TCP options such that they eat the necessary space
> for
> TCP options from the payload, not by increasing the IP datagram size
> if TCP options are present. For example, if SMSS is set to, let's say
> 1460 octets, and a TCP sender adds a TCP timestamp option (12 bytes)
> it
> will send only 1448 bytes of payload in a TCP segment?
>
> What the draft now says in this respect is on the safe side, but it
> might be overcautious. I don't remember any RFC saying how SMSS and
> adding options to a TCP segment are related. Maybe someone of the TCP
> implementors may shed more light to this how?
We have tried to address your two comments above. On this matter, we
> had
received feedback that this measure (advertising an MSS smaller than
1220
bytes) would be safe, but we have tried to reflect that this might not
be
necessary, and even overcautious.
>>>
>>> Seems fine, thanks.
>
> I didn't remember at the time, but there actually is an RFC that gives
> the guidelines of handling this, RFC 6691, and it would be worth citing
> here. And possibly slightly editing the text that says "Note that, in
> many implementations, ..." to emphasize something along the lines:
> "However, note that it is recommended/reguired/advised (?) for TCP
> implementations to consume payload space instead of increasing datagram
> size when including IP or TCP options in an IP packet to be sent
> [RFC6691]. Therefore, the suggestion of advertising an MSS smaller than
> 1220 bytes is likely to be overcautious and its suitability should be
> considered carefully.
>
> The requirement in RFC 6691 is lower case must in an informational RFC, so
> not quite sure how to best reflect that here when citing (maybe using
> "advised" above)? My suggested text also slightly modifies the original
> text, but I believe it's all ok to edit it like this even during auth48?
> If you feel it is better not to change the text anymore at this point, I
> think it's also fine just adding the reference (though I personally find
> it better/more correct to change the text a bit along the lines above).
>
> Best regards,
>
> /Markku
>
>
> On Fri, 6 Mar 2020, Zhen Cao via Datatracker wrote:
>
>> Zhen Cao has requested publication of
>> draft-ietf-lwig-tcp-constrained-node-networks-09 as Informational on
>> behalf of the LWIG working group.
>>
>> Please verify the document's state at
>> https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/
>>
>>
>> ___
>> Lwip mailing list
>> Lwip@ietf.org
>> https://www.ietf.org/mailman/listinfo/lwip
>>
>
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip
