Re: [tcpm] WGLC for MSS document

<L.Wood@surrey.ac.uk> Thu, 20 August 2009 20:00 UTC

Return-Path: <L.Wood@surrey.ac.uk>
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 8F12328C1B8 for <tcpm@core3.amsl.com>; Thu, 20 Aug 2009 13:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.523
X-Spam-Level:
X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DEwrEJH9uvyq for <tcpm@core3.amsl.com>; Thu, 20 Aug 2009 13:00:58 -0700 (PDT)
Received: from mail80.messagelabs.com (mail80.messagelabs.com [195.245.230.163]) by core3.amsl.com (Postfix) with SMTP id DE2D03A6A3B for <tcpm@ietf.org>; Thu, 20 Aug 2009 13:00:57 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-6.tower-80.messagelabs.com!1250798462!71056855!1
X-StarScan-Version: 6.1.3; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 3755 invoked from network); 20 Aug 2009 20:01:02 -0000
Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-6.tower-80.messagelabs.com with SMTP; 20 Aug 2009 20:01:02 -0000
Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.139]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 21:01:01 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA21D0.F0E2EC8B"
Date: Thu, 20 Aug 2009 20:59:14 +0100
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE01368955@EVS-EC1-NODE4.surrey.ac.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] WGLC for MSS document
Thread-Index: AcohxA/eBV9XnLxLRKyYuqK76i42XgADKGPK
References: <C304DB494AC0C04C87C6A6E2FF5603DB47919CC610@NDJSSCC01.ndc.nasa.gov> <4A8D95B4.3040209@isi.edu>
From: <L.Wood@surrey.ac.uk>
To: <touch@ISI.EDU>, <wesley.m.eddy@nasa.gov>
X-OriginalArrivalTime: 20 Aug 2009 20:01:01.0830 (UTC) FILETIME=[F1462260:01CA21D0]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] WGLC for MSS document
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: Thu, 20 Aug 2009 20:00:59 -0000

Can't TCP MSS also vary across multipath environments? Strikes me
that these are more common than header compression - which should
be advertising conservative minimum MTUs for their link interfaces.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: tcpm-bounces@ietf.org on behalf of Joe Touch
Sent: Thu 2009-08-20 19:28
To: Eddy, Wesley M. (GRC-MS00)[Verizon]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] WGLC for MSS document
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> This note starts a 2-week Working Group Last Call on the TCPM document:
> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02
> Please send any comments to the TCPM list.  The WGLC will last until
> September 1.

I'd like to suggest the following for this doc:

MSSs can sometimes vary, as when used with variable compression, e.g.,
ROHC. The ROHC doc missed an opportunity to address the interaction of
variable MSS with TCP, and this might be a good place to include a
sentence or two on it, e.g. (IMO):

- ---

MSSs can sometimes vary, as when used with variable compression, e.g.,
ROHC [RFC5255]. It is tempting for TCP to want to advertise the largest
possible MSS, to support the most efficient use of compressed payloads.
Unfortunately, some compression schemes occasionally need to transmit
full headers (and thus smaller payloads) to resynchronize state at their
endpoint compressor/decompressors. If the largest MSS is advertised, TCP
retransmission may interfere with compressor resynchonization.

As a result, when effective MSS varies, TCP SHOULD compute its
advertised MSS based on the smallest effective MSS.

- ---

Joe