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
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
