Re: [L4s-discuss] Irregularities in results from L4S testing

Matteo Guarna S303434 <matteo.guarna@studenti.polito.it> Thu, 07 September 2023 13:33 UTC

Return-Path: <matteo.guarna@studenti.polito.it>
X-Original-To: l4s-discuss@ietfa.amsl.com
Delivered-To: l4s-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AD7C14F721 for <l4s-discuss@ietfa.amsl.com>; Thu, 7 Sep 2023 06:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=studenti.polito.it
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 rSxkWunISBkw for <l4s-discuss@ietfa.amsl.com>; Thu, 7 Sep 2023 06:33:10 -0700 (PDT)
Received: from compass.polito.it (compass.polito.it [130.192.55.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE8AC15199C for <l4s-discuss@ietf.org>; Thu, 7 Sep 2023 06:33:09 -0700 (PDT)
Received: from compass-fwd (localhost [127.0.0.1]) by compass.polito.it (Postfix) with ESMTP id 800F46001EE5 for <l4s-discuss@ietf.org>; Thu, 7 Sep 2023 15:33:06 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by compass.polito.it (Postfix) with ESMTP id 7EB5C6001EE1 for <l4s-discuss@ietf.org>; Thu, 7 Sep 2023 15:33:06 +0200 (CEST)
Authentication-Results: compass.polito.it (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=studenti.polito.it
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= studenti.polito.it; h=user-agent:x-sender:message-id:references :in-reply-to:subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version:received:received; s=y2k10; t=1694093585; bh=XjT4O pdWKPyAYau5deyC5+umL2pbZTRZyq7SB2asoaI=; b=QwaBjSg/z1npVXF48AH+D afbBPBc0w7sGkXZsWI0bUzI0Z9RCJh1bYy+ACtgFM8DaHaYNANkqKUu3iPJhQAYo vHqfW9jirTvJeWeYuKREiiesQEb0tQum3Hbw1o9b56p3jDp8cR/08XMDJCa1fl9m gtTDfS5YuN+i3MQUCn+N0Y=
X-Virus-Scanned: amavisd-new at studenti.polito.it
Received: from compass.polito.it ([127.0.0.1]) by localhost (compass.polito.it [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sgLR1kL_Ajck for <l4s-discuss@ietf.org>; Thu, 7 Sep 2023 15:33:05 +0200 (CEST)
X-AccountStatus: yes
Received: from mail.studenti.polito.it (mail.studenti.polito.it [130.192.55.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: s256987@studenti.polito.it) by compass.polito.it (Postfix) with ESMTPSA id F10086001ED1 for <l4s-discuss@ietf.org>; Thu, 7 Sep 2023 15:33:05 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Thu, 07 Sep 2023 15:33:05 +0200
From: Matteo Guarna S303434 <matteo.guarna@studenti.polito.it>
To: l4s-discuss@ietf.org
In-Reply-To: <8eea45b1cd4862fa731babeab073fc74@studenti.polito.it>
References: <181d20c79294d87ca7e3c4a398457cb2@studenti.polito.it> <6460de788e810fc720d196304e9cd228@studenti.polito.it> <8eea45b1cd4862fa731babeab073fc74@studenti.polito.it>
Message-ID: <0c6dffb73da73f0c47a7b5382e41203e@studenti.polito.it>
X-Sender: matteo.guarna@studenti.polito.it
User-Agent: Roundcube Webmail/1.2-rc
X-Webmail-IP: [ 93.36.161.1 ]
X-Encoded-IP: RzU6yY4HY6QEGhnPC9W/TV5xsmo22b1LzSKeN/HM+IsP5flulLtiUHwVUjMY8vjYRU+skO7DlwA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/l4s-discuss/9mfKSwZHCLIYgo2-KV2v3QquGHU>
Subject: Re: [L4s-discuss] Irregularities in results from L4S testing
X-BeenThere: l4s-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Low Latency, Low Loss, Scalable Throughput \(L4S\) " <l4s-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l4s-discuss>, <mailto:l4s-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l4s-discuss/>
List-Post: <mailto:l4s-discuss@ietf.org>
List-Help: <mailto:l4s-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l4s-discuss>, <mailto:l4s-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Sep 2023 13:33:14 -0000

Thanks a lot Sebastian Moeller, Koen De Schepper, Robert Joseph McMahon 
and Vihdi Goel, you've all been incredibly helpful.

I am really greatful for everybody's help, you helped me solve all my 
doubts!

I wish you all a great day

Matteo


Il 2023-09-05 21:44 Matteo Guarna S303434 ha scritto:
> Greetings,
> 
> I am currently conducting research for my thesis on the L4S suite. As
> part of my research, I have deployed a simple testbed to examine the
> behavior of a TCP-Prague data flow when deployed in conjunction with a
> TCP-Cubic flow on a congested, L4S-capable network link.
> 
> For the network configuration and host setup, I have utilized the
> source code available at the following GitHub repository:
> 
> https://github.com/L4STeam/linux/tree/testing .
> 
> While my initial tests have been generally successful, I have
> encountered two specific issues:
> 
> 1 - The TCP-Prague and TCP-Cubic flows do not seem to equitably share
> available bandwidth. In some cases, TCP-Prague appears to consume up
> to two/thirds of the channel's capacity.
> 
> 2 - Upon inspecting the packets to assess the correctness of the
> protocol's behavior, I observed that the proportion of TCP-Prague ACK
> packets with the TCP ECE (Explicit Congestion Notification Echo) flag
> is approximately 5/9 of the total ACK packets, while the percentage of
> transmitted packets marked by the queue remains consistently at around
> 8%. While I did not anticipate a strict 1:1 ratio, this result still
> strikes me as peculiar.
> 
> Additionally, I noted that all TCP-Prague packets inherently carry the
> CWR (Congestion Window Reduced) flag by default. It appears to me (if
> I'm not mistaken) to be an intentional implementation choice by the
> developers, as detailed in the source code found at
> https://github.com/L4STeam/linux/blob/testing/net/ipv4/tcp_prague.c ,
> specifically beginning at line 53. I would appreciate confirmation
> regarding this implementation choice and assurance that it does not
> adversely impact its compliance with the standard.
> 
> I extend my sincere gratitude in advance to anyone who can provide
> insights or assistance with these matters.
> 
> Best regards,
> 
> Matteo Guarna
> 
> 
> P.s.
> 
> I someone wants a more detailed insight regarding my testplant and my
> results, I had tried to ask for help by opening an issue on the
> repository's github, where I provided a more in-depth description of
> my experiment. The conversation is available here:
> 
> https://github.com/L4STeam/linux/issues/21