Re: [Lwip] Publication has been requested fordraft-ietf-lwig-tcp-constrained-node-networks-09

Markku Kojo <> Tue, 26 May 2020 10:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CBEA3A0DC8; Tue, 26 May 2020 03:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fBF0M9qBRC3a; Tue, 26 May 2020 03:33:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4D993A0DDC; Tue, 26 May 2020 03:33:54 -0700 (PDT)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 Tue, 26 May 2020 13:33:46 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=YE2VtdeMYl8ZejTZq EREtNbU+RQggcYIE/ZnOMVcgcc=; b=YXmiYFOj0zbKJ5TvsxJ44pW5+ljW1z0J2 u1IDeGXhXGwSNW5kkTrSVLyimXvg1e+BP2VUmp5S1fRsVA4F1dRMyVSCnCZlVhGP 9ckOFJOqzdE0rzcSUief1/TU1nRZvG+nkDsZ1n2ooT3GEjNj7h2E8tCpo9D+sUtR P6yKBISvvY=
Received: from hp8x-60 ( []) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by with ESMTPSA; Tue, 26 May 2020 13:33:46 +0300 id 00000000005A01BC.000000005ECCF08A.00003FC0
Date: Tue, 26 May 2020 13:33:44 +0300
From: Markku Kojo <>
To: Carles Gomez Montenegro <>,,
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <>
Subject: Re: [Lwip] Publication has been requested fordraft-ietf-lwig-tcp-constrained-node-networks-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 May 2020 10:33:58 -0000

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 

It's related to my earlier comment on Sec 4.1.1 (see below):

>>>> In addition, to my understanding TCP implementations typically 
>>>> the presence of TCP options such that they eat the necessary space 
>>>> 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) 
>>>> 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 
>>> 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,


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
> _______________________________________________
> Lwip mailing list