Re: Last Call: <draft-ietf-tsvwg-rfc5405bis-13.txt> (UDP Usage Guidelines) to Best Current Practice

Mark Allman <mallman@icir.org> Tue, 31 May 2016 18:58 UTC

Return-Path: <mallman@icir.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FF112D14B for <ietf@ietfa.amsl.com>; Tue, 31 May 2016 11:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 bFcCfjp3oXzs for <ietf@ietfa.amsl.com>; Tue, 31 May 2016 11:58:04 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3842B12D151 for <ietf@ietf.org>; Tue, 31 May 2016 11:57:58 -0700 (PDT)
Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u4VIvv36006999 for <ietf@ietf.org>; Tue, 31 May 2016 11:57:57 -0700 (PDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 444E049DE7FC for <ietf@ietf.org>; Tue, 31 May 2016 14:57:57 -0400 (EDT)
To: ietf@ietf.org
From: Mark Allman <mallman@icir.org>
Subject: Re: Last Call: <draft-ietf-tsvwg-rfc5405bis-13.txt> (UDP Usage Guidelines) to Best Current Practice
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Born to Run
X-URL-0: http://www.icir.org/mallman-files/Document63239.docx
X-URL-1: http://www.icir.org/mallman-files/Document47838.html
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 31 May 2016 14:57:57 -0400
Message-ID: <34060.1464721077@lawyers.icir.org>
Sender: mallman@icir.org
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/2aYni7zq3FDvSqnM7Tl7MqsSAPo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mallman@icir.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2016 18:58:06 -0000

This I-D needs a little work WRT the RTO words, IMO.

About the doc's words ...

  - I'd be interested to hear why it is RECOMMENDED to adhere to the
    RTO algorithm in RFC6298.  In my view, in 2016 this is just
    unnecessary and wrong (see my broader opinion below).  (That
    said, if someone wants to use that algorithm, I think it is
    fine... but, prescribing it is not needed, IMO.)

  - I'd also like to see the normative text better underscore the
    importance of backoff.

  - "TCP requires the initial RTT to be set to no less than 1
    second" ... TCP requires the initial ***RTO*** be no less than 1
    second.  There is a difference between the RTT and the RTO and
    this draft is pretty liberal with using them interchangeably
    (which is both confusing and wrong).

  - And, it isn't quite clear whether the document is saying that UDP
    apps should use the full 6298 algorithm or just that for computing
    the SRTT.  If the former then why discuss the SRTT?  And, if the
    latter then it needs to better indicate how UDP apps are supposed to
    use half the algorithm.

  - Further, it notes the RTT is used for things like rate control
    that I am not sure 6298 applies to.  Certainly it wasn't
    designed for that.  Do we know it is reasonable for rate
    control?  Is it important we nail down the precise RTT
    estimation for rate control?

A broader opinion is that we should just elide these words in favor
of a set of general RTO guidelines that span protocols (see
draft-ietf-tcpm-rto-consider ; which goes beyond TCP, but is in TCPM
for now because TCP is where it started, but comments would be
appreciated from all corners).

FWIW.

allman


--
http://www.icir.org/mallman/