Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

Yuchung Cheng <ycheng@google.com> Mon, 20 May 2013 19:13 UTC

Return-Path: <ycheng@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9749A21F96B6 for <tcpm@ietfa.amsl.com>; Mon, 20 May 2013 12:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-COdzJipO0R for <tcpm@ietfa.amsl.com>; Mon, 20 May 2013 12:13:53 -0700 (PDT)
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2288021F96B0 for <tcpm@ietf.org>; Mon, 20 May 2013 12:13:52 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id w20so6554441lbh.12 for <tcpm@ietf.org>; Mon, 20 May 2013 12:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=M5dCViyNu0qaB983Um4qqyR7bEMqHt4ZRHNwo+p5AEg=; b=H6QG4/kxH39aMuS+x01rJ7zxkfo4fw8HiP+Xots11cOus7O/WThlE0YjRKqQhgLRMj zpaAXOg4D0++1ttwzWKZEPPU3crjr8VPh2DEli6HjiDvWZUvBOkwpSYbJ/y2Gkbzxiya vk4NJ/eAANEHal+PyWbGSKHsrLKzsDBTNzVsTzu0kHya3pK024bkTIt84fh7FXnW3ayZ IWMokbjd3eK3DAePRC2u90ZJ7OiR07Yj1BSLyt7dhkr50+x5TP8ca03ZMVUg7dqkmpdx 52hDPlYuSZRS9ZB280Yk0EizDOMUAb8vNGde9dhzVypX2mZxIdtA/6UxFX7SqUlhqclk 0pXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=M5dCViyNu0qaB983Um4qqyR7bEMqHt4ZRHNwo+p5AEg=; b=DK0ydw0FqwTjeOh/Z54R8aDw7WRDhA+sbh/eCTG33mAWRn6M0WSIa2u9rVhHk4M3E8 KLgUfGT+mZjCENWdzy1Ytrg/PBni6hRWqGB2EbsIhL/LXwrHa6ttg4kVeRpRbau7wTHa sKcHOEWgoZccAA6DVXnNJvbHgeetDbkmEyf0oF53yxLZpiLUiZG7KDmHVNWDk37XVU7Z s59Uxp2fU+RR1trjf+EzK+YO5QN1hiIAD60FSJO9nogKg21QYG8jEYxm1RDxWTZ4B+qR d/E1iPgAzEFAe1gzKf0GuAyiLl/dzuahkbn6Ttec9fZPtQ1oQwqgdXVA/O8CgGqoIukK Zl8g==
X-Received: by 10.112.160.103 with SMTP id xj7mr28302332lbb.97.1369077231890; Mon, 20 May 2013 12:13:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.159.106 with HTTP; Mon, 20 May 2013 12:13:31 -0700 (PDT)
In-Reply-To: <20130518155753.17946.96581.idtracker@ietfa.amsl.com>
References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 20 May 2013 12:13:31 -0700
Message-ID: <CAK6E8=d_LTZgnGAncdWDAi+7ebd3Lo5aevPeGG0=KSbBMeBhcg@mail.gmail.com>
To: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQkB4ATKftNYBm97H1o4kM3DBBCym5Lrm0TdacensmfiVCRDgXFncyBiwmKPrKufMwLhvpP01Vy/OLNcH04pJHkBnzdGXoS3lfDCeNRzhGanyvaFOf/trVghUijS/0CPjE/BilKAUCAE0c6bwi83lOb2KKwiox/qcfYyz0/6pxABN3pkJk/Y73P0yXhPZZLWAujFrGO7
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 May 2013 19:13:57 -0000

I suggest removing all these texts;

"""If a non-<RST> segment is received without a TSopt, a TCP MAY drop
the segment and send an <ACK> for the last in-sequence segment.  ""
What's the point to ignore a perfectly fine data packet w/o TS-opt and
respond a (DUP)ACK? the sender is probably may trigger fast recovery
falsely. Responding ACKs is not going to make any forward progress  on
buggy implementations or middle-boxes.

""" A TCP MUST NOT abort a TCP connection if a non-<RST> segment is
received without a TSopt. """
TCP should abort only if it's truly in trouble. so let's not
re-emphasize the general rule of trying to keep things going until the
last minute.

"""If a TSopt is received on a connection where TSopt was not
negotiated in the initial three-way handshake, the TSopt MUST be
ignored and the packet processed normally.""" there was an RFC that
states this general rule already?

"""   In the case of crossing <SYN> segments where one <SYN> contains
a TSopt and the other doesn't, both sides MAY send a TSopt in the
<SYN,ACK> segment. """ The prior text on SYN already covers this.

In general I found section 3 has redundant MUST/SHOULD/MAY terms. An
RFC should be parsimonious on these terms so implementer can focus on
key rules.



On Sat, May 18, 2013 at 8:57 AM,  <internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.
>
>         Title           : TCP Extensions for High Performance
>         Author(s)       : David Borman
>                           Bob Braden
>                           Van Jacobson
>                           Richard Scheffenegger
>         Filename        : draft-ietf-tcpm-1323bis-13.txt
>         Pages           : 46
>         Date            : 2013-05-18
>
> Abstract:
>    This document specifies a set of TCP extensions to improve
>    performance over paths with a large bandwidth * delay product and to
>    provide reliable operation over very high-speed paths.  It defines
>    TCP options for scaled windows and timestamps.  The timestamps are
>    used for two distinct mechanisms, RTTM (Round Trip Time Measurement)
>    and PAWS (Protection Against Wrapped Sequences).
>
>    This document updates and obsoletes RFC 1323.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-13
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-13
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm