[tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 27 May 2024 02:53 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EABCC15109C for <tsvwg@ietfa.amsl.com>; Sun, 26 May 2024 19:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFheoYP9lezO for <tsvwg@ietfa.amsl.com>; Sun, 26 May 2024 19:53:08 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A383C14F686 for <tsvwg@ietf.org>; Sun, 26 May 2024 19:53:03 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1f44b5b9de6so19463415ad.3 for <tsvwg@ietf.org>; Sun, 26 May 2024 19:53:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716778382; x=1717383182; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:cc:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nxBOU3v9RJLIu5owt1v66uXGeqSmIrVY+YRhonwTlvk=; b=ifiuRJB/kwECqGDf612mpDc83l8OAa2DiN7eQ7A7xS1Hl+Z/a0bzQvqWCJbJh0vcO0 pWKr9KpI+zoiuS/SneDvVRG+7Zvx4w9uttpHm2ia898kIA1vcZWVT4mWPXH34/HoVK09 mJ5GMH59nj/7RsJ4viRjjA5ogYH8Qt3+Fg9vGlsqoQcG68fUrPlIhSiY+unForDqpT4I xLq1ZRwZrt195xCW47/WGQuVtwC/tRF5vfrDhVMNt5wA4/pNt3Ul7MbEnguTfCrhSZd/ O9Mxjkk5vBbKZu1jOVqgJb9t7TEOUZppae30V7G04euVnaAAOGJWDPt/389V2rHIeWje vUEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716778382; x=1717383182; h=content-transfer-encoding:in-reply-to:from:cc:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nxBOU3v9RJLIu5owt1v66uXGeqSmIrVY+YRhonwTlvk=; b=bOb9G7ZeD4wnVbk9Tk32YgvSTMlgsk4oe36VnijbV9bIXnEYVGD85tg/VcBqPz4nOD RK5/W3i17HoLSsUOptgOvp9WwetKMCzMpJU4J8A0xiGZ7/815UGxtQWvCGW4WZbgbuqH H7zaLzdL2QphctU2gIqOfXYtQLkUxyjhY57woeo4iz5RhX/3SAY9lSGMtK+qqEEwtFoD ie7fbsYkc2SCDFrCt+ZVsTLCqAssa9mWU9tDMoX1dBi/N1PgLfQmcjSdlIPiVoNqXF+J OG4C8vUnVpEtLlZgiXbPQN8z97ewWvcKwCn8dgAskA6p6/pC+uJ/W+0z57Xy3AbmiKjj wLGA==
X-Gm-Message-State: AOJu0YwsB9Om4vnjt6UTQd4OlYAdk/v0X2+LgftBv5E2Shcn+s1rguh/ 7qzvhj4MBPLPTskTPUZ0XcyfUhCv8jANJzDGAAngHXCXHWZjzc48lGsSbdO1
X-Google-Smtp-Source: AGHT+IGB/7v08BZyAWnEBrr8FEZ7RLB/Yh4cBt+JqDVh81pK3HmFOBpD4CznxV34QqVvuneMi+0w6g==
X-Received: by 2002:a17:902:e80c:b0:1f3:1036:a262 with SMTP id d9443c01a7336-1f4486bd0e6mr100879585ad.12.1716778382246; Sun, 26 May 2024 19:53:02 -0700 (PDT)
Received: from ?IPV6:2404:4400:541d:a600:44b7:2c2e:2bc6:8707? ([2404:4400:541d:a600:44b7:2c2e:2bc6:8707]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f44c967acbsm49787225ad.149.2024.05.26.19.53.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 May 2024 19:53:01 -0700 (PDT)
Message-ID: <075c9da4-df83-4286-85f3-d36553fac3ba@gmail.com>
Date: Mon, 27 May 2024 14:52:58 +1200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: tsvwg@ietf.org
References: <171619088820.9700.17122047615729502291@ietfa.amsl.com> <65a001f0-386e-4d3a-b41a-1ae75a195aca@erg.abdn.ac.uk>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <65a001f0-386e-4d3a-b41a-1ae75a195aca@erg.abdn.ac.uk>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: KQQFVR55BTLXMXMFOPLTRNKU6OJXRNUS
X-Message-ID-Hash: KQQFVR55BTLXMXMFOPLTRNKU6OJXRNUS
X-MailFrom: brian.e.carpenter@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "Black, David" <David.Black@dell.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ej3Rk8FVIuopmM0xMwZqndECTGs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

Hi,

This is a brief review of draft-ietf-tsvwg-nqb-23. This is the first time I've read the draft for a very long time. It looks pretty good to me, but of course I have a few comments below. (I no longer subscribe to tsvwg, so please Cc me if appropriate.)

In  3.1 "Non-Queue-Building Behavior" we find:

"In contrast, Queue-Building (QB) microflows include those that use TCP or QUIC..."

I can easily imagine an NQB application that chooses to use a reliable transport layer even for a small, intermittent flow. So the implication of this phrase that only QB flows use a reliable transport seems wrong to me.

In 3.2 "Relationship to the Diffserv Architecture":

"in many cases the implementation of Diffserv PHBs has historically involved prioritization of service classes with respect to one another, which sets up the zero-sum game"

This is a very important remark (and of course is exactly what RFC2474 wanted to avoid), but a bit later we find:

"NQB is expected to be treated with the same priority as Default..."

Oh dear. Perhaps "NQB is expected to be treated similarly to Default..."

In 4.1 "Non-Queue-Building Sender Requirements"

"Microflows that are eligible to be marked with the NQB DSCP are typically UDP microflows that send traffic at a low data rate relative to typical network path capacities."

Or, as noted above, intermittent and low data rate TCP (or even QUIC) flows.

In 4.3 "Aggregation of other DSCPs into the NQB PHB":

"[NOTE (to be removed by RFC-Editor): this section references the obsoleted RFC2598..."

I would leave that note in place; it's helpful to the reader.

In 4.4 "Cross-domain usage and DSCP Re-marking":

I think there needs to be an explanation of how this section relates to RFC 8100, but David Black is probably the best person to comment on that.

In 7.3 "Wi-Fi Networks":

There are several references to what an implementation of RFC8325 should do, but there is no specific change to RFC8325. Either state exactly what is changed in the text of RFC8325, or remove the "Updates:" tag.

9 "Implementation Status":

Thank you for including this.

In Appendix B "Comparison with Expedited Forwarding"

"NQB primarily recommends traffic protection located at each potential bottleneck, where actual queuing can be detected and where excess traffic can be reclassified into the Default PHB rather than dropping it."

It would be good to clarify that this does *not* mean re-marking the packet, just treating it as if it was marked as Default. (Assuming that's what you mean.)

Regards
    Brian Carpenter