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

Joe Touch <touch@isi.edu> Tue, 27 July 2010 08:14 UTC

Return-Path: <touch@isi.edu>
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 DB67A3A6AB1 for <tcpm@core3.amsl.com>; Tue, 27 Jul 2010 01:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.557
X-Spam-Level:
X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, PLING_QUERY=1.39]
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 fm7PTipSwEyx for <tcpm@core3.amsl.com>; Tue, 27 Jul 2010 01:14:38 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id EDAF33A6A6E for <tcpm@ietf.org>; Tue, 27 Jul 2010 01:14:37 -0700 (PDT)
Received: from [130.129.133.227] (dhcp-85e3.meeting.ietf.org [130.129.133.227]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o6R8DVmn002860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jul 2010 01:13:43 -0700 (PDT)
Message-ID: <4C4E952B.5000803@isi.edu>
Date: Tue, 27 Jul 2010 01:13:31 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Alexander Zimmermann <alexander.zimmermann@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> <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de>
In-Reply-To: <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: o6R8DVmn002860
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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: Tue, 27 Jul 2010 08:14:40 -0000

Hi, Alex,

On 7/26/2010 11:15 AM, Alexander Zimmermann wrote:
> 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...

That's the purpose of Dave Borman's I-D, FWIW - to remove that room ;-)

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

TCP terminology has been around for a long time. Changing any one name 
causes a ripple effect that requires updating a large number of 
documents. It ought to cause less confusion at this point to just 
explain what each of these sizes means and how they are related to each 
other.

Joe

> 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
>>
>>
>