[tcpm] (no subject)

Jana Iyengar <jri.ietf@gmail.com> Fri, 22 November 2019 03:55 UTC

Return-Path: <jri.ietf@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 7DD9C120967 for <tcpm@ietfa.amsl.com>; Thu, 21 Nov 2019 19:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 Sbbt000-PLmL for <tcpm@ietfa.amsl.com>; Thu, 21 Nov 2019 19:55:04 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 6FA3B1208E1 for <tcpm@ietf.org>; Thu, 21 Nov 2019 19:55:04 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id v201so3345811lfa.11 for <tcpm@ietf.org>; Thu, 21 Nov 2019 19:55:04 -0800 (PST)
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=Pv+tw8qvhOIfXDdnEiF5icGesrRI8qASplXJHuBl+nE=; b=nOIgBRosd7ynba2lunBHXwKLnKkFJVX/8jM6uuueqxH+tozDjfdw7dkx0VDDIQsY7E /U30wvvzWzvzV9EgU47+evacg2FfC5+uA+zIwF9805r0mAlOmMdYmsEUHmPRcCbD4C1H RywXUFCCEqeohIKayaZ3r+HQAC/THUMPx14eK13NGzpNOj/hs9qFkkWivQbH4L2WsQts mfwqyTMWFGf0uTdMyspjWenEoX75ykygnilM0D2eAFSHZfn3RBZRhxDxVP7NoHN8PA/L RcszWa7YR1Z8Nk2obG7+x+P4dwEj2J/eGOydnmgQpgkZPUjP2+H/PEIYE/3zknbCye1a i1/g==
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=Pv+tw8qvhOIfXDdnEiF5icGesrRI8qASplXJHuBl+nE=; b=FegOcwHRJKNEivMzPk7svXBxvmSq+VxxbhyDZ2jSgJ8FabCGxc4Qv6JlmxKlQQvjnj sAL75Vz5my2RGOPzmPIvzoA55EYzAFGDV76ntkGpwkyOT9VVlPgqrWR/2b7W65oZAc4A +Ulp+SyG88rS54L7acv1Scue07DaUxay422ss5TgTga+vuwcxd9lPl50jVlSA9EiPhBe iqiv4GnAyF1G5IXGk0fSb0j/X58s7Nnws5HTInvxh7OpByZ+sVQ4txPKCq2RWGR8RO+8 tzrR2gsDdxgmkx8jvB126aR9HMgI++8poSJzJ2BK6+Q7aT5gnJDEq1fZQln3dcDF70Df jK+A==
X-Gm-Message-State: APjAAAXbqxqEXbUGs6aYf1yyWpIV77mbqeZvEL7soIEjHX7uQrH6VUOy 10quW5leZqqxa7gkIE28F7cloGY6MBfN63uoDCZoQLAcOU8=
X-Google-Smtp-Source: APXvYqxH/aHOFh1tX9skTiD5qeIBuLWJ7wp5z5NE2eVR5veecRbydihyS1v2+13SkOh0y6raqOp/AQ/I3P0R5EnnqY4=
X-Received: by 2002:ac2:4c8e:: with SMTP id d14mr2282425lfl.32.1574394902509; Thu, 21 Nov 2019 19:55:02 -0800 (PST)
MIME-Version: 1.0
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Fri, 22 Nov 2019 11:54:51 +0800
Message-ID: <CACpbDcfKnPzej_NC1TDauABg0k1Je=rJ-qi8AHMxMYQ169q5CQ@mail.gmail.com>
To: tcpm@ietf.org, mallman@icir.org
Content-Type: multipart/alternative; boundary="000000000000e67f400597e7600e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/WNGODSgPK6uZTR7edVmAi5HX59U>
Subject: [tcpm] (no subject)
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: Fri, 22 Nov 2019 03:55:07 -0000

Mark,

Apologies for this late review. It's been a while since I read the draft,
and I have just a couple of comments.

I have one high-order point. The document limits itself to transports where
loss detection *and retransmission* occurs. Specifically, Section (S.2)
says: "The requirements in this document only apply to cases where loss
detected via a timer is repaired by a retransmission of the original data.
Other cases are certainly possible---e.g., replacing the lost data with an
updated version---but fall outside the scope of this document."

There are a couple of other places as well ("all timer-based retransmission
mechanisms", and also in requirement (3)). I would suggest that the draft
applies to loss detection, not to recovery or retransmission. Specifically,
QUIC detects loss using a Probe Timeout (equivalent to an RTO), but may not
retransmit lost data for a variety of reasons. Is there a reason to
preclude this behavior?

More generally, TCP conflates *what* to send with *when* to send it, and
whether to send something is presumed "yes". QUIC decouples these pieces,
and that may be true of other future protocols as well. (This is true of
SCTP using the partial-reliability extension as well, RFC 3758).

The requirements in the document already apply to these protocols, because
the principles apply to the loss detection function of the transport, not
the recovery function.

In terms of text changes, I think simply removing "and retransmission" from
most places is adequate to achieve this. Requirement (3) however relies on
the data getting acked, which can be generalized. The current text is:
"The backoff SHOULD be removed after the successful repair of the lost data
and subsequent transmission of non-retransmitted data."
This can be replaced by:
"The backoff SHOULD be removed after an acknowledgement is received for a
subsequently sent packet."
---

Editorial suggestions:
- remove para beginning with "This document is a bit "weird" ...", and also
drop the phrase "At this point, however" from the beginning of the next
para. This is unnecessary text, IMO.
- Take it or leave it: change title from "Requirements" to "Guidelines".

- jana