From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DF21D3CB35 for ; Sat, 24 Aug 2019 22:41:39 -0400 (EDT) Received: by mail-lf1-x131.google.com with SMTP id 62so9763134lfa.8 for ; Sat, 24 Aug 2019 19:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=YbtgZXMw/Qs/XET6p1RgktXrnX3gemLAZWmJsnxEgto=; b=AL0rroSLzo4b4jQuu0Jm0nLhnnbBQzFY/CnXwDol670Cov90Ykv8fP1h7tCE3taK85 YZTUuMjptJONv1d6LuVrewwS+ePOn+0oHKtQQ9iDEvKJEPAT7CHAt30oi+rGxKcNYjkU +XWr2mDscCzcxCLCSvxuGrOo0zH8+9xagZgyZa4TVe0xhuFSvvZE3hz5zh2nsgjBS4lZ 7V4N7uuT0MkfydTsSVqFD32jbItAxygof0T30axNwuIcjExYIVdyu7O/zq0Uzjpr7ni9 GEt3ffxdwzik6WPdMct/0eiIqvMgRo+pU8IsORrKRFsdgddf345nZbJMQsNhbFeREpgW yPvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=YbtgZXMw/Qs/XET6p1RgktXrnX3gemLAZWmJsnxEgto=; b=GyGEFKrd/8DgffgqRHl6RoNEpL0+9G6pHLMbYQTrJkd5Qn3BhF7PE6zNzfBz58bQs8 hCShOKbrpQcCWaabSBOrIyhl0w7aMIc3TQqhzQEc3cBo/LGQ0Miv9imwcgIs8Sozpzev Eh7XIv81dF3SW8w/McM/Wod3DH3qaHvv7Y7BNvYKB9pJXn4VWCiU5B/cIa2VwTCoWREn 3DTwOMuPzne+NXVw7TRO3Q08RvgwcQnmW/HLqQBRlLXTvrkS1/dANw94WWgCLXtyLRei YYvnKW9mZFqsO5RlF0yMTESUdmXSXXaws9RADX3NzKJX8ncrshFGr6XysH6E0+UuXEXa B8dg== X-Gm-Message-State: APjAAAUKKJMxfYB13GwK/IO2heG9nF+2k5k4I0xrj2zn+bWJFV+/Ns1S OR3ks0Q6eHoVIsVcffz8wllUxNu2Iv0= X-Google-Smtp-Source: APXvYqzguc/VUsrFoFbABcmdGhLSUpn0wlh9+gFRfFlgZzNXvikTdXQsPSDqAsix2G6j1ZjJ4W59gg== X-Received: by 2002:ac2:410e:: with SMTP id b14mr6618643lfi.123.1566700898384; Sat, 24 Aug 2019 19:41:38 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-237-193-nat-p.elisa-mobile.fi. [83.245.237.193]) by smtp.gmail.com with ESMTPSA id u9sm1578446lja.27.2019.08.24.19.41.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Aug 2019 19:41:37 -0700 (PDT) From: Jonathan Morton Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <236694E9-6EC8-466A-AF5D-F0C94A3C13F4@gmail.com> Date: Sun, 25 Aug 2019 05:41:36 +0300 Cc: ECN-Sane To: tsvwg IETF list X-Mailer: Apple Mail (2.3445.9.1) Subject: [Ecn-sane] morton REVIEW of draft-white-tsvwg-nqb-02 X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 02:41:40 -0000 Summarising and condensing observations from various quarters, and upon = carefully reading the draft myself=E2=80=A6 In a specification introducing a new DSCP, it is necessary to: 1: Identify the (proposed) codepoint in question, subject to formal = assignment by IANA. 2: Identify the types of traffic which should be marked with the new = DSCP. 3: Describe the PHB to be applied to traffic carrying that DSCP, = avoiding over-specification. These three requirements can be met much more concisely than the draft = presently achieves. In particular, the draft should focus on the = immediate technical issues, refrain from editorialising or marketing, = and does not need to be written like a white-paper (despite the primary = author's name). For an example of the latter, it is not necessary to = include catechism phrases like: > (Section 4) > "Some questions that arise when considering endpoint marking are: How = can an application determine whether it is queue building or not, given = that the sending application is generally not aware of the available = capacity of the path to the receiving endpoint?" I and others take particular exception to the editorialising around FQ = qdiscs. It should be perfectly sufficient to observe that not all = network environments have FQ installed or are presently considered = suitable for FQ deployment, and therefore that some other method of = identifying NQB flows than "uses less than its fair share of the = bandwidth" (which FQ identifies naturally) would be useful for these = environments. That is sufficient motivation for the NQB DSCP, and = limiting the discussion of FQ to that point would probably shorten the = draft by half. In terms of identifying traffic suitable for the NQB DSCP, I would = specifically identify the following categories: 1: Simple request-response protocols, such as DNS and NTP. 2: Latency-sensitive protocols that are not capacity-seeking, such as = VoIP and realtime multiplayer games, and for which the EF (Expedited = Forwarding) DSCP is not appropriate. 3: Capacity-seeking protocols whose congestion control algorithms are = specifically designed to avoid building either persistent or transient = queues, and for which the LE (Least Effort) DSCP would not be more = appropriate. These could include certain variants of TCP, but TCPs = using ordinary versions of Reno or CUBIC could be identified as = counterexamples with an explanation of the correct distinction to br = drawn. Contrary to assertions made in the draft, it is not yet established that = mis-marking traffic as NQB is harmless. In particular, if an effective = "queue protection mechanism" is not provided (noting that it is optional = in the spec), an adversary is able to increase the latency and/or the = packet loss of NQB flows by flooding the NQB queue. For an adversary = interested in disrupting NQB traffic, that is an advantage not afforded = by a similar flood composed of best-effort marked traffic. We can = reasonably predict that adversaries will take such an interest, given = that NQB traffic is likely to include (pseudo) telephone calls and = gaming sessions. A "queue protection mechanism" is mentioned as a SHOULD requirement of = the PHB, but is not described in an IETF document but an = industry-specific external specification. My understanding is that, = ironically, this externally-specified algorithm is broadly similar to = FQ. Such a normative reference needs to be brought within the IETF, so = that the association is not lost if the external specification moves = URLs or goes offline in future. > 6. End-to-end Support > In contrast to the existing standard DSCPs, which are typically only = meaningful within a DiffServ Domain (e.g. an AS), this DSCP would be = intended for end-to-end usage across the Internet. It was my impression that the "standard" DSCPs were in fact intended for = end-to-end usage across the Internet, but that misinterpretation of the = specifications has led to DSCPs frequently being erased or corrupted on = typical Internet paths. It is certainly true that this situation has = made Diffserv much less practically useful from an end-to-end = perspective. > (Section 8.3) > As discussed in [RFC8325], most implementations use a default DSCP to = User Priority mapping that utilizes the most significant three bits of = the DiffServ Field to select User Priority. In the case of the 0x2A = codepoint, this would map to UP_5 which is in the "Video" Access = Category (one level above "Best Effort"). >=20 > Systems that utilize [RFC8325], SHOULD map the 0x2A codepoint to UP_6 = in the "Voice" Access Category. This is obviously wrong and SHOULD be deleted. As I understand it, 0x2A was suggested as a suitable DSCP *specifically* = so that it would naturally map to UP_5 and thus the "Video" category. = There are significant practical ramifications associated with placing = capacity-seeking traffic, which may legitimately be marked NQB, in the = "Voice" category; in particular it leads to considerably higher priority = for airtime access, which is specifically stated as a non-goal elsewhere = in the draft. Even the "Video" category gives some additional priority, = but is not as damaging to other RF-spectrum users in the vicinity. Better wording might be: > Systems that utilize [RFC8325], MAY map the 0x2A codepoint to UP_5 in = the "Video" Access Category. Otherwise, they SHOULD map it to UP_0 in = the "Best Effort" Access Category. If this change is not made, I recommend that capacity-seeking protocols = be removed entirely from the list of suitable traffic types. - Jonathan Morton