Re: [tsvwg] question regarding L4S claims

Jonathan Morton <chromatix99@gmail.com> Thu, 04 June 2020 11:32 UTC

Return-Path: <chromatix99@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 950083A08E3 for <tsvwg@ietfa.amsl.com>; Thu, 4 Jun 2020 04:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 k5XAdj-T9fKq for <tsvwg@ietfa.amsl.com>; Thu, 4 Jun 2020 04:32:11 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 20C153A08DD for <tsvwg@ietf.org>; Thu, 4 Jun 2020 04:32:11 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id m18so6811618ljo.5 for <tsvwg@ietf.org>; Thu, 04 Jun 2020 04:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dnt3EHEC6/O9IeA5DJM6ZtK11c7OzCQkf9kr79AEYSs=; b=SsSZ0qfHwAv/jqBfeCGkWZpj1LACg967dDo6yrQvNef8yaKs6+JIojkjUHKmm3aaCR lwKvBPJaczrh1XAVZ3WSsxVZz7hVTHnSSVduUl+P5gYq8NpRCO4Z7m0OGauKGoF/vevk oX/XPbTFV1RAkRoenH/eUuVjKCrkuJuYwFEziJAj97n/EGBm/AjFhyYUnXiRZKXyeptg lrZv/oEJwbAMTPI4ipc0nW1XRcchFvGjfeLE5KfX+ZPVFXNAFLZX4RHsdgRs7ctMJ1r6 Nfo0D+UL1lC1BuEbHTzmu5N2bpBuHe7F0ZjpFCGhgioMW+pPLuTyuJwVnTnHaZqtn7jf OsMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dnt3EHEC6/O9IeA5DJM6ZtK11c7OzCQkf9kr79AEYSs=; b=QZXiIbqaOy6qPlG5iJItlLDrtQCcxVu1I9YGsrVC3X4RVwHQb2k1ovupFwikp/yOde czoR4cDRdewwu6/BFY1059B0qQCVlYAo2J3WNLMRcUFiRBkKD46bn/yB8W+wZ4/E33Wd ZMXgbZbmIsmUDx5y/gd1TqMOmx6WS5qJqtWx9USxqgRWqaagbE+VLnsZoL6OnWD1b9JF sGSNlc+yzNxaZjb3Bn8vvEix/KgnyUuZL9Z0Wr1f2STkpP0/zzEtIqLylfVMnKSKQO3k wOkK0WylkF8U4tlihnPcbf8Lqx57mt/GBsgxoO1+D8mGkxFlcPjnlcRqpeedrt83PR/V 1qhQ==
X-Gm-Message-State: AOAM531fBczYbQEhn9T8K257kaewZteNzHgeJWmQOSNIb452E5Lj5l6Z c4xxExMAj2uASsP+8XyZNx8=
X-Google-Smtp-Source: ABdhPJykEDt7ZVD+zPzgUsWnbwMiJ6e7Vg79wUHcm/N82JvoyFUpn0Mjbm8l+lo6GXMdpqGGNcEL/g==
X-Received: by 2002:a2e:b5ca:: with SMTP id g10mr2061011ljn.370.1591270329136; Thu, 04 Jun 2020 04:32:09 -0700 (PDT)
Received: from jonathartonsmbp.lan (83-245-237-14-nat-p.elisa-mobile.fi. [83.245.237.14]) by smtp.gmail.com with ESMTPSA id 15sm1135010ljw.46.2020.06.04.04.32.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 04:32:08 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <E3F3E880-0A67-4C6A-8F23-DD7E129E96CD@gmx.de>
Date: Thu, 04 Jun 2020 14:32:06 +0300
Cc: TSVWG <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2A2330D-DAC3-4189-A5EE-D33F7CE49B90@gmail.com>
References: <E3F3E880-0A67-4C6A-8F23-DD7E129E96CD@gmx.de>
To: Sebastian Moeller <moeller0@gmx.de>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/mWszUOpBOrT-cH75bhwicfIB0Dc>
Subject: Re: [tsvwg] question regarding L4S claims
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 04 Jun 2020 11:32:13 -0000

> On 4 Jun, 2020, at 12:27 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> 3) 99.9th %ile queuing delay: the assumption here seems to be that only the single AQM hop actually controls all variable RTT jitter. And that 99.9 is a relevant number here, which obviously is debatable.

I've been wanting to bring up something related to this point for a while, but other matters have previously taken precedence.  My question is: when and under what circumstances does the observed 99.9th-percentile delay occur?

In the case of fq_codel, tested with a conventional TCP stream, it will obviously be at the termination of slow-start, when the exponential growth (doubling cwnd per RTT) cannot be stopped instantaneously, but continues for one more RTT after the first congestion signal is given (which for CUBIC may be a delay signal interpreted by HyStart).  So the peak queue depth at slow-start termination will tend to be at least the baseline path RTT, and will then quickly settle down to congestion-avoidance mode in which the peak delay is only slightly greater than the Codel target (ie. 5ms).  And I remind readers that fq_codel protects other flows from experiencing the peak delay of one flow's startup.

The situation with L4S is less obvious, noting that the data presented is very old, and comes from DCTCP rather than any recent version of TCP Prague.  I consider it likely that DCTCP's slow-start is terminated prematurely by L4S' very aggressive AQM interacting with the natural burstiness of an unpaced slow-start, so the early phase is characterised primarily by linear rather than exponential growth.  We might therefore reasonably guess (in the absence of a corresponding time-series plot which could confirm or deny this hypothesis) that the 99.9th-percentile delay quoted for DCTCP corresponds to the congestion-avoidance phase rather than slow-start.

If true, the quoted 4.5ms figure would represent only a couple of milliseconds' improvement over the congestion-avoidance latency performance of fq_codel with CUBIC, and an actual deficit of perhaps a millisecond compared to CUBIC-SCE performance with an SCE-enabled AQM, both at default settings.  And of course it is entirely possible to delete the slow-start phase entirely and rely only on the linear or polynomial growth factors, as long as you're willing to accept the greater delay before the path capacity is actually found.  If minimising peak latency is paramount, that might just be a sacrifice you have to accept.

But it's pretty clear that remote-rendering VR headset displays is not practical over a network.  It's barely practical even within a single, up-to-date gaming-spec PC, without involving a network link at all.  I can entirely believe a 20ms latency budget for that application, as it's consistent with a 90fps minimum frame rate for VR headsets that I've seen quoted elsewhere.  That equates to 11ms between frames, and the information needed to start rendering that frame has to be prepared in advance.  Just getting data over a USB cable reliably within 9ms is challenging enough!

 - Jonathan Morton