Subject: [tcpm] WGLC for MSS document

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Tue, 18 Aug 2009 12:38:20 -0500

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.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

---

From: Alexander Zimmermann <[email-masked]>
Date: Thu, 20 Aug 2009 16:50:28 +0200

Hi David,

some minor comments on the draft.

1. Needs boilerplate update (Copyright section)

2. IMHO in line 50: %s/to do about TCP options/to do about IP and TCP  
options/

3. Just one sentence later: "RFC-1122 [Braden89] attempted to clarify  
this in section 4.2.2.6, but
there still seems to be confusion." What is the problem here with RFC  
1122? Why does RFC 1122
does not manage to clarify the situation. I think one or two sentence  
more explanation would be
great.

Alex

Am 18.08.2009 um 19:38 schrieb Eddy, Wesley M. (GRC-MS00)[Verizon]:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Aug 2009 11:28:04 -0700

Hi, all,

> Please send any comments to the TCPM list.  The WGLC will last until

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

---

From: <[email-masked]>
Date: Thu, 20 Aug 2009 20:59:14 +0100

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/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of Joe Touch
Sent: Thu 2009-08-20 19:28
To: Eddy, Wesley M. (GRC-MS00)[Verizon]
Cc: [email-masked]
Subject: Re: [tcpm] WGLC for MSS document

Hi, all,

- ---

- ---

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Aug 2009 13:35:36 -0700

Hi, Lloyd,

[email-masked] wrote:
> Can't TCP MSS also vary across multipath environments? 

Yes, but that's discovered by PMTUD. I think this doc is focusing more
on what the interface says is available - which ROHC might have an
effect on.

> Strikes me

I'm not sure what's more common, but they're separate effects AFAICT.

Joe

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, all,
>

---

From: Mark Allman <[email-masked]>
Date: Wed, 26 Aug 2009 09:56:50 -0400

> Please send any comments to the TCPM list.  The WGLC will last until

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").

FWIW.

allman