[tcpm] draft-ietf-tcpm-rack-05 review

Martin Duke <martin.h.duke@gmail.com> Tue, 03 September 2019 22:31 UTC

Return-Path: <martin.h.duke@gmail.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 00948120271 for <tcpm@ietfa.amsl.com>; Tue, 3 Sep 2019 15:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aZlO028U27t for <tcpm@ietfa.amsl.com>; Tue, 3 Sep 2019 15:31:02 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F67A12004F for <tcpm@ietf.org>; Tue, 3 Sep 2019 15:31:02 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id t17so1131809wmi.2 for <tcpm@ietf.org>; Tue, 03 Sep 2019 15:31:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gZGw3uSGD6Gemn2OM61Y5Q3GUOJ3R9FOcv5FVMxOtJI=; b=TNSurTVLD+lmJyal9KbaToF5CEw6a2x26uH0ddlKC8xo3zsJwoM9Hl9kUk5t2zPgCK SaK5pugSjW86VdXpv3p7M2hvdNyQ8XKi8u2RgZ6QYIp+Bq5ejzDWrZW3mbrNQFRMPj4g BfcHTPOONQ01JNpRe7x/8REbrkaDewukQ/TlrLAlHN0MVbjNnNB+x7aJYHWS6+owOBVE yt44XFA2scwX7fanaVT3OIq/JvDbQyriuk5e5do3WtRakou4FSdAjdnVpA+dE9MOfs5B H3P5K1ItFQfKTNH5MXoU3G8ABifwHNQpslN0XJ9sgJhqKOY7pAu7/vuzIeBNlcKlgWSx psLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gZGw3uSGD6Gemn2OM61Y5Q3GUOJ3R9FOcv5FVMxOtJI=; b=Ro4bQab9aarvrsJLgX+3qiSSqt1TeSMKqbhddiJaRR38Za4Gp8buQKOyTcD/AEAafd wyDAnjJJTvnWgNgsLYtRZbJyQ14N9+eflJw2hdmbClT480Kf/fhkA8g4gVKDhWi9xffO CHasTZ18c3zDx3oIrnbween0GM5HoKUV1BWaomJg9YwcyrEBfEscHZ6hznIC0MaZm1MV 1APGWXEE2QugzP9PY7u5E3w9Z+7Goe78QOXRN+KLVCwsNAuQFruYTBGoQzw1BmgVSL9w BlTJuWERdLcvXd7LS/yd9ZSYDHwv9JYRJ8tZTu7gA/attQ3EZOfd8oL4/0qJkCppL05M YIxw==
X-Gm-Message-State: APjAAAUAwvOF/EugfNTYqrjHzy1t3XZfZbn4h1IkDSbplorR2jG6UFIx YSb1qedW7cSXS/SE0VeWBnx8gj7T8FnkyoFLRjNAW0PP
X-Google-Smtp-Source: APXvYqyEIrX03tj3q7tLsv1y+NUzLJxESDV+Yvn0GnMZJMIU5A7H4/kloRzjBczieiw8dh5YwoTrWnd20FgLuWsvT0k=
X-Received: by 2002:a7b:c013:: with SMTP id c19mr1693075wmb.34.1567549860878; Tue, 03 Sep 2019 15:31:00 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 03 Sep 2019 15:30:49 -0700
Message-ID: <CAM4esxQR5zeHC0g0MmCG3iF2js_2BU6+tdwCKi4ZiGFYMr5MRg@mail.gmail.com>
To: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a01d0d0591ada4e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/8OBhYaWTiSfsp7wXU_R8rh5uFvo>
Subject: [tcpm] draft-ietf-tcpm-rack-05 review
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 03 Sep 2019 22:31:05 -0000

Late in the day, but I have a few nits on this draft.

(1) The definition of RACK.rtt in Sec 5.2 does not match the Step 2
pseudocode in Sec 6.2:

"RACK.rtt" is the RTT of the most recently transmitted packet that
   has been delivered (either cumulatively acknowledged or selectively
   acknowledged) on the connection.

6.2 :

If the ACK is not ignored as invalid, update the RACK.rtt to be the
   RTT sample calculated using this ACK, and continue.

...

RACK.rtt = rtt
           If RACK_sent_after(Packet.xmit_ts, Packet.end_seq
                              RACK.xmit_ts, RACK.end_seq):

The definition implies that RACK.rtt should only be send if
RACK_sent_after(), but IIUC this is not what the the text and pseudocode
say.

(2) Sec 7.1

RACK always marks the entire
   TSO blob lost...

unless, of course, some of them are sacked?

(3) sec 7.3
We have evaluated using the smoothed RTT (SRTT from
   [RFC6298 <https://tools.ietf.org/html/rfc6298>] RTT estimation) or
the most recently measured RTT
   (RACK.rtt) using an experiment similar to that in the Performance
   Evaluation section.  They do not make any significant difference in
   terms of total recovery latency.

If there is truly no difference, then why not use SRTT as the standard?
Every TCP implementation has to store this, while min_rtt is unneeded
for many (most?) congestion controls.

Alternatively, you could strengthen this paragraph to not sound like
it makes no difference.

Thanks for your work on this.

Martin