Re: [tcpm] Re: WGLC: comments on 2581bis

Gorry Fairhurst <gf@erg.abdn.ac.uk> Wed, 05 December 2007 05:18 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzmeL-0000X1-Hy; Wed, 05 Dec 2007 00:18:21 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IzmeK-0000Ue-MT for tcpm-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 00:18:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzmeK-0000TX-BX for tcpm@ietf.org; Wed, 05 Dec 2007 00:18:20 -0500
Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzmeJ-0007Ir-Q0 for tcpm@ietf.org; Wed, 05 Dec 2007 00:18:20 -0500
Received: from dhcp-4669.ietf70.org (dhcp-4669.ietf70.org [130.129.70.105]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id lB55HkLm017866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Dec 2007 05:17:48 GMT
Message-ID: <47563473.8000909@erg.abdn.ac.uk>
Date: Tue, 04 Dec 2007 21:17:39 -0800
From: Gorry Fairhurst <gf@erg.abdn.ac.uk>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: mallman@icir.org
Subject: Re: [tcpm] Re: WGLC: comments on 2581bis
References: <20071204192941.5FDB4307D60@lawyers.icir.org>
In-Reply-To: <20071204192941.5FDB4307D60@lawyers.icir.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gf@erg.abdn.ac.uk
X-Spam-Status: No
X-Spam-Score: -1.4 (-)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: gorry@erg.abdn.ac.uk, tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

Mark Allman wrote:
 > Gorry-
 >
<snip>
 >> ---
 >> 2) RMSS
 >> - The wording in the draft is not clear  whether this is an upper
 >> bound to the SMSS, or just one of many ways to discover a sensible
 >> SMSS.
 >
 > The latter.  I guess I am not quite sure what to do with this comment.
 >
 >> - Is the default RMSS still 536 bytes also for IPv6, since [RFC1122]
 >> does not apply in this context to IPv6.
 >
 > I think so.  Are you suggesting here that we specify a different value
 > when we're going over IPv6?
 >
I queried if this should have been different for v6, because I'd have 
expected it was safe to use 1220.

 > I am not sure if that is a 2581bis thing or a 1122bis thing.
RFC 2460, only says:
  " For example, in
    IPv4, TCP's MSS option is computed as the maximum packet size (a
    default value or a value learned through Path MTU Discovery) minus 40
    octets (20 octets for the minimum-length IPv4 header and 20 octets
    for the minimum-length TCP header).  When using TCP over IPv6, the
    MSS must be computed as the maximum packet size minus 60 octets,
    extension headers) is 20 octets longer than a minimum-length IPv4
    header."
- All of which is true, but does not explicitly update TCP's default 
MSS. Looking at code, it seems 1024 is not uncommon.... Well that was 
fun, if you know better, do improve the text, otherwise I expect the 
current text is fine.

 >> 3) ECN
 >> - The document speaks only of loss, but I'm assuming that this applies
 >> equally to ECN. If that is so, perhaps we should explicitly say so 
up-front.
 >
 > In the intro to section 3 I have put these words:
 >
 >     Also note that the algorithms specified in this document work in
 >     terms of using loss as the signal of congestion.  Explicit
 >     Congestion Notification (ECN) could also be used as discussed in
 >     [RFC3168].
 >
 > Does this work?
 >
Yes, that would be fine - I'd prefer /defined in [3168]/specified in 
[3168]/ or something of the like.

 > allman
 >
 >
 > ------------------------------------------------------------------------
 >
 > _______________________________________________
 > tcpm mailing list
 > tcpm@ietf.org
 > https://www1.ietf.org/mailman/listinfo/tcpm

best wishes,

Gorry



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm