Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is)

Fred Baker <fredbaker.ietf@gmail.com> Sun, 12 March 2023 00:30 UTC

Return-Path: <fredbaker.ietf@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 3A994C14CE30 for <tsvwg@ietfa.amsl.com>; Sat, 11 Mar 2023 16:30:00 -0800 (PST)
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_DNSWL_NONE=-0.0001, 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 z7ACsCVnBotO for <tsvwg@ietfa.amsl.com>; Sat, 11 Mar 2023 16:29:55 -0800 (PST)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 E5E65C14CE2C for <tsvwg@ietf.org>; Sat, 11 Mar 2023 16:29:55 -0800 (PST)
Received: by mail-pl1-x62e.google.com with SMTP id y11so9392939plg.1 for <tsvwg@ietf.org>; Sat, 11 Mar 2023 16:29:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678580995; h=to:references:message-id:cc:date:in-reply-to:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=HmkESQW6qHdZgyJIikh0IW1NW91ZV3uQJtOyJUYVC58=; b=pwYy60NDPs6Dr4I94ewOVV+QTT4Pj57jJkCqUsBTvHZDonzER+WO5faoWKuMjhfHhw Je4knJZg4MaIYCwEUcxzfl262uprtwodIY8+uPDQmNM00ivCbr+0xiPpm9LawsWpK6mh jM9fmV6K7e3swm1cg3q9v0H+lgy+J6QHdYGonsi+NcNIMGltcGJf5RxS56PzTqJ72vOu +mqLlVL94RILnpwP4aZMGZQ1Zi4gY478QGcyfoPyTt3Pz5S0reZvWxGXOEawQsIxJdR0 86DTPGnMN4OqTw95ICpBc19piUGpRLwRv3XA+JNV0jtoxG6mrzyeLVWa/C0OMZ2kDVJL BJ4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678580995; h=to:references:message-id:cc:date:in-reply-to:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HmkESQW6qHdZgyJIikh0IW1NW91ZV3uQJtOyJUYVC58=; b=5dsiBl20fGonhdFb1ewEkqzCI6UepATx9uMPTRDbUzXlJBGqQt1+n207KJe8cw2W7q MoVOvV8AXYCmKK52jVf3RaHL9Vet7ur3HEGwOBXcx9leXjYcXfsUp7b8b11d6Q6G7KrS KV17yGmNfClrf5JfhMrQYo0VBeiQavi+8pG9vtuNB+CrPg0UZBYSWsZ3AopUJKvQ1tYG +og0eTPu+L0duyYvyAiW4OhiuB4HeD758QdBGU2lBaqctZuwur8Z8bxnYxG9WSVJKaFA wz1pgkZk9bWbJfQR01+HfxG77uDnk5D01HIrLZsg2PY73+8ETgwBx9a1t7Xuf9CJVn8Z NuCA==
X-Gm-Message-State: AO0yUKXxhglo9Dt72s+tOQE39aHFw2IpYEcHfMtwyqzkn6JkKsanYA/L gNVi0g53T3kW85EoC2DOM8L+rVev5Kw=
X-Google-Smtp-Source: AK7set8j954Lc1FZsXJZAmP3t5SN7V2aR/G1lqWIDfuJjf2zbThcOknxl8QbpK1qspIRraX6prPu2A==
X-Received: by 2002:a17:902:9b8a:b0:19a:acc2:73e4 with SMTP id y10-20020a1709029b8a00b0019aacc273e4mr25817134plp.22.1678580995090; Sat, 11 Mar 2023 16:29:55 -0800 (PST)
Received: from smtpclient.apple ([2600:8801:d605:5e00:6970:7374:69cb:ffca]) by smtp.gmail.com with ESMTPSA id u9-20020a17090341c900b0019a593e45f1sm1973971ple.261.2023.03.11.16.29.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Mar 2023 16:29:54 -0800 (PST)
From: Fred Baker <fredbaker.ietf@gmail.com>
X-Google-Original-From: Fred Baker <FredBaker.IETF@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
In-Reply-To: <EDED2A65-DE02-428B-99F9-1CB20FFFB139@cablelabs.com>
Date: Sat, 11 Mar 2023 16:29:42 -0800
Cc: Ruediger.Geib@telekom.de, tsvwg@ietf.org
Message-Id: <772C91A4-290E-4A78-9BDF-111CEFCC679F@gmail.com>
References: <EDED2A65-DE02-428B-99F9-1CB20FFFB139@cablelabs.com>
To: Greg White <g.white@cablelabs.com>
X-Mailer: iPhone Mail (20D67)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/n3eh5hgdh-qJ6CDhY8L-yF1YmTM>
Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Mar 2023 00:30:00 -0000


Sent using a machine that autocorrects in interesting ways...

> On Mar 11, 2023, at 4:05 PM, Greg White <g.white@cablelabs.com> wrote:
> 
> [GW] Sections 6 & 12 already mention the consequences of both options on an application (and the consequences there are fairly obvious).  I guess you are asking more broadly, what are the consequences of PHB implementers choosing the re-marking/re-classification option vs choosing the discard option, in a game-theory sense?  For applications that are sensitive to packet loss, I suppose PHB implementations that choose the discard option would create a stronger disincentive for application mismarking, but on the other hand would likely create a greater degradation even for NQB-compliant applications in overload situations, as compared to PHB implementations that choose re-marking/re-classification. For applications that are out-of-order intolerant (i.e. treating a sequence gap the same as a packet loss), I suppose the two PHB implementations are roughly equivalent. 

Discarding is a measurable event if the packet contains something that can be treated as a sequence number. Dropping it into a different queue can improve the effective rate of the packet, or delay it, depending on the momentary statistics of the other queue; if the queue happens to be empty at that nanosecond, for example, it effectively adds the rates of the two queues for the duration f the packet.

I suspect your statement of the impact is somewhat cavalier.