Re: [tcpm] Exceeding value in MSS option?

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Wed, 21 October 2020 07:31 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A70A3A11EE for <tcpm@ietfa.amsl.com>; Wed, 21 Oct 2020 00:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaIaNrr5rZso for <tcpm@ietfa.amsl.com>; Wed, 21 Oct 2020 00:31:54 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F0B3A11EF for <tcpm@ietf.org>; Wed, 21 Oct 2020 00:31:53 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id BEEDE25A1E; Wed, 21 Oct 2020 09:31:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1603265511; bh=UlOeNk8FoF6IC3wPvZaEbUbPa7jlieSBYdvQUoJlMeE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Brq3C58dkhi57qr1wvvwDYRV28xDLDrnCA533HCdSfT01McagZxxizsS6f7k6t0uW dURlnbt7VWGa6ebrlwKDNgag/PwBsmTbuhIIwiNgdYXU6UHqI4zbEhBGRHVB4Mq7u9 6HYSBsvWZn2iZVgCD+vn914ClqD2Vn5dBxC6/5m4=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZouyU7St5l8; Wed, 21 Oct 2020 09:31:50 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 21 Oct 2020 09:31:50 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 21 Oct 2020 09:31:50 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Wed, 21 Oct 2020 09:31:50 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
CC: Martin Duke <martin.h.duke@gmail.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Thread-Topic: [tcpm] Exceeding value in MSS option?
Thread-Index: AQHWpk1K5yCW3VOIm02cl+MOJ34oLamfNjuAgAGnxdD///0BAIAAyrlw
Date: Wed, 21 Oct 2020 07:31:50 +0000
Message-ID: <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de>
References: <CAM4esxQzydPBTjVQvtp3766mCH5L65LdRSkFzQkdeKgUfhKacA@mail.gmail.com> <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de>
In-Reply-To: <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.248]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/BU-B483dQIARAeorIMD6ZdfrgwY>
Subject: Re: [tcpm] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2020 07:31:56 -0000

> > On 20. Oct 2020, at 21:56, Scharf, Michael <Michael.Scharf@hs-
> esslingen.de> wrote:
> >
> > Hi all,
> >
> > Sorry for the delayed reply. More inline...
> >
> >>> On 19. Oct 2020, at 21:22, Martin Duke <martin.h.duke@gmail.com>
> wrote:
> >>>
> >>> Hello tcpm,
> >>>
> >>> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST
> >> consider all IP and TCP options when sizing payloads with respect to the
> >> advertised MSS option.
> >>>
> >>> I'm reviewing a document that advises that some endpoints may want to
> >> reduce their advertised MSS on IPv6 connections in case the peer isn't
> >> respecting that guidance. Is noncompliance with this provision a problem
> in
> >> the internet? Are there middleboxes injecting options that cause PMTU
> >> drops or fragmentation?
> >> Hi Martin,
> >>
> >> the document you are reviewing says:
> >>
> >>   An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
> >>   the TCP MSS not larger than 1220 bytes.  This assumes that the remote
> >>   sender will use no TCP options, aside from possibly the MSS option,
> >>   which is only used in the initial TCP SYN packet.
> >>
> >> The first sentence is correct. The second is not. I would suggest to simply
> >> remove it.
> >
> > The statements regarding the MSS were discussed and also rewritten many
> times. And, sorry, apparently I have not carefully read the second sentence
> (but, well, that sentence was also in the version of the draft that was last
> called in TCPM...)
> >
> > Given this discussion now, I agree that the second sentence could probably
> be removed.
> >
> >> Then the text says:
> >>
> >>   In order to accommodate unrequested TCP options that may be used by
> >>   some TCP implementations, a constrained device may advertise an MSS
> >>   smaller than 1220 bytes (e.g. not larger than 1200 bytes).  Note that
> >>   it is 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.
> >>
> >> I read this as "use a smaller MSS", but this is "likely to be
> >> overcautious and its suitability should be considered carefully."
> >>
> >> I think the careful consideration is to remove this paragraph.
> >
> > I am not sure if we should simply remove the whole paragraph, including
> e.g. the reference to RFC 6691. Readers
> The paragraph starts with:
> 
> In order to accommodate unrequested TCP options that may be used by
> some TCP implementations, a constrained device may advertise an MSS
> smaller than 1220 bytes (e.g. not larger than 1200 bytes).
> 
> I don't think the selection of the MSS should depend on TCP options.
> A TCP stack may send an MSS option with a value lower then 1220, but
> it should not do it due to any TCP options.

OK, thanks, now I actually get the point. Sorry, it was late yesterday. I agree. This is all what RFC 6691 is about.

But I still wonder whether we should keep a reference to RFC 6691, given that this topic has repeatedly caused confusion.

>  That is the reason, why
> I suggested to remove the paragraph.

What about the following shorter paragraph with three sentences:

   An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
   the TCP MSS not larger than 1220 bytes. Note that
   it is 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, it is not required to
   advertise an MSS smaller than 1220 bytes in order to accommodate
   TCP options. 

Would that be reasonable?

Michael

> 
> Best regards
> Michael
> 
> >  of this document may not be aware of RFC 6691, so a pointer may be
> useful, no? Also, during the IETF last call there was a discussion on MSS
> values significantly smaller than 1220 byte. People apparently *do* think
> about smaller MSS values on constrained devices and this document is a
> place to provide guidance to that community (as far as possible). This specific
> wording came up in earlier reviews of the draft, too. Thus, the final proposal
> "likely to be overcautious and its suitability should be considered carefully" is
> a result of several past discussions. IMHO we should carefully consider
> changes to this statement...
> >
> > BTW, personally, I really wonder if using an MSS of 1220 byte (for IPv6)
> indeed causes real-world problems on constrained devices, i.e., if in year
> 2020 there is any real-world benefit of an MSS smaller than 1220 byte. But,
> unfortunately, I don't have measurement data that would back a different
> statement in the draft.
> >
> > Michael
> >
> >> Best regards
> >> Michael
> >>
> >>
> >>
> >>
> >>>
> >>> I have not heard of such problems, but thought I'd check with the
> >> community to see if this precaution makes any sense at all.
> >>>
> >>> Thanks,
> >>> Martin
> >>>
> >>>
> >>> _______________________________________________
> >>> tcpm mailing list
> >>> tcpm@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tcpm
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> tcpm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tcpm