Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?!

Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de> Mon, 26 July 2010 18:15 UTC

Return-Path: <alexander.zimmermann@nets.rwth-aachen.de>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702783A684B for <tcpm@core3.amsl.com>; Mon, 26 Jul 2010 11:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.411
X-Spam-Level:
X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5myxaBZ6Ag4 for <tcpm@core3.amsl.com>; Mon, 26 Jul 2010 11:15:35 -0700 (PDT)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id AE5683A680E for <tcpm@ietf.org>; Mon, 26 Jul 2010 11:15:32 -0700 (PDT)
MIME-version: 1.0
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L660060SG2HUEC0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 20:15:53 +0200 (CEST)
X-IronPort-AV: E=Sophos; i="4.55,262,1278280800"; d="sig'?scan'208"; a="66653896"
Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 26 Jul 2010 20:15:52 +0200
Received: from [192.168.4.13] ([unknown] [77.109.116.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6600GRVG2EBS20@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 20:15:53 +0200 (CEST)
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Apple-Mail-4--934244779"
From: Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de>
In-reply-to: <4C4DC9B0.3030203@isi.edu>
Date: Mon, 26 Jul 2010 20:15:49 +0200
Content-transfer-encoding: 7bit
Message-id: <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de>
References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> <20100726170646.GC23686@colt> <4C4DC9B0.3030203@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Pgp-Agent: GPGMail 1.2.3
X-Mailer: Apple Mail (2.1081)
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 26 Jul 2010 18:15:40 -0000

Hi Joe,

maybe a stupid question but why do we write in both cases (SMSS/RMSS) "is the size of the
largest segment"? According RFC1122 (page 19), a TCP segment is data structure that
include the TCP header. And than later on in the definition "The size does not include the
header". These gives IMO really room for interpretation...

Why do we not write in both cases something like "is the size of the
largest TCP payload".

Alex


Am 26.07.2010 um 19:45 schrieb Joe Touch:

> Hi, all,
> 
> On 7/26/2010 10:06 AM, Ethan Blanton wrote:
>> Alexander Zimmermann spake unto us the following wisdom:
>>>> Yes, RFC5681 is correct,
>>> 
>>> Sorry, but I disagree. I cite the sentence in question again:
>>> 
>>> "The size does not include the TCP/IP headers and options."
>>> 
>>> The "and" in the sentence is IMO wrong or at least very very misleading.
>>> Either we write: "The size does include ONLY the fixed TCP/IP headers."
>>> or we write "The size does not include the TCP/IP options"
>> 
>> I believe (as one of the authors) that 5681 is correct.  Neither the
>> fixed TCP header size nor the option space are included in this
>> calculation for the purposes of 5681.
> 
> draft-ietf-tcpm-tcpmss states that the MSS option includes the fixed TCP and IP headers and NOT the options.
> 
> I think Alex did find a bug here (I had commented on his misquoted earlier post), as per below... it's not in BOTH descriptions, though.
> 
> In 5681, RMSS is in error as follows:
> 
>   RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the
>      largest segment the receiver is willing to accept.  This is the
>      value specified in the MSS option sent by the receiver during
>      connection startup.  Or, if the MSS option is not used, it is 536
>      bytes [RFC1122].  The size does not include the TCP/IP headers and
>      options.
> 
> If RMSS is ever the value in the MSS option, it would include the fixed headers but not the options.
> 
> > It is concerned only with data
>> bytes sent in-band.  If SMSS is used differently elsewhere, that is
>> unfortunate, but it does not affect the definition within 5681.
> 
> Only RMSS is in error; as you note, SMSS is correct.
> 5681 says SMSS is based on RMSS (where "based on" isn't explained):
> 
>   SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the
>      largest segment that the sender can transmit.  This value can be
>      based on the maximum transmission unit of the network, the path
>      MTU discovery [RFC1191, RFC4821] algorithm, RMSS (see next item),
>      or other factors.  The size does not include the TCP/IP headers
>      and options.
> 
> SMSS clearly must omit all TCP and IP headers, because it is the value that updates cwnd.
> 
> So, IMO, yes, there's a bug, but it's in RMSS's description. There may be a useful clarification that defines SMSS in terms of RMSS explicitly as well.
> 
> Joe
> 
>