Re: [tcpm] WGLC for MSS document

Mark Allman <> Wed, 26 August 2009 13:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF12F3A67DA for <>; Wed, 26 Aug 2009 06:59:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.388
X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jTfdDSAbPbHj for <>; Wed, 26 Aug 2009 06:59:26 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 145683A67B5 for <>; Wed, 26 Aug 2009 06:59:26 -0700 (PDT)
Received: from ( []) by pork.ICSI.Berkeley.EDU ( with ESMTP id n7QDuvmi024562; Wed, 26 Aug 2009 06:56:57 -0700
Received: from ( []) by (Postfix) with ESMTP id AB7CA3C82EDD; Wed, 26 Aug 2009 09:56:47 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 00EF23F8684; Wed, 26 Aug 2009 09:56:50 -0400 (EDT)
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <>
From: Mark Allman <>
In-Reply-To: <>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Streets of Philadelphia
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma16160-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 26 Aug 2009 09:56:50 -0400
Message-Id: <>
Cc: "" <>
Subject: Re: [tcpm] WGLC for MSS document
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Aug 2009 13:59:26 -0000

> This note starts a 2-week Working Group Last Call on the TCPM document:
> Please send any comments to the TCPM list.  The WGLC will last until
> September 1.

I am in general in favor of this document.  But, this document is sorta
confusing to me and so I'd vote "not ready" at the moment.  

The statement that the MSS advertisement should not include the bytes
consumed by options is clear, but in the explanation of that rule.

  + I had to work through the table to figure out "length" on the y-axis
    was the overall packet length.

  + I find it strange that the table is left as the sole justification
    without even a little bit of prose that explains it.  In fact, I
    would think a little prose instead of the table would make the whole
    thing more clear.

  + The other thing you might note is that the MSS advertisement cannot
    possibly capture the right number of option bytes for every packet
    in a connection because options are variable (e.g., SACK).  So, even
    if one tries to capture option lengths in the header the length will
    still have to be hacked on the fly (or, you'll have to take a
    pessimal view of option usage as "using all of it").