Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up

Yoshifumi Nishida <nsd.ietf@gmail.com> Thu, 14 July 2022 09:12 UTC

Return-Path: <nsd.ietf@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC892C14CF09; Thu, 14 Jul 2022 02:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 r33ahUQkuloY; Thu, 14 Jul 2022 02:12:26 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 564CFC14F742; Thu, 14 Jul 2022 02:12:26 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id bu1so1663811wrb.9; Thu, 14 Jul 2022 02:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bVg8cRh9LvmZ8D0n3Gz1NmzVLuPnUHeDYkuUgnxDRMA=; b=MCqOlBr9aNkccSNyVRFzOX0ZZR8aR558IkRAIx5DjXc7XvC3xGE1G+l0MKdSitgBw2 omSp5XXtK6wHUQbwFRpQIapbVJq3NR2aNR4wmViiASnoy8FtIXQ5FIyNRIolFQ6PNQHP eWJsTts9k5A0wsEAbzjCpRcbvPYkjAygwwZjgsBNMfluCBNbZJ7yR2fXv8wnNzA8NlVe gLG+MAJmHEwTFTEmjJnyXNoMBxH9aKGUlig6GqWP6ylrsUco9Okve8wBoe/qAIkYFN6X JmeQZrkZeOgZ4pgKoCxY7Rd9MoT4UlYq5p6H1syr0FjorU5gpaMLGLL0QjEdgzz2pLx9 pRMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bVg8cRh9LvmZ8D0n3Gz1NmzVLuPnUHeDYkuUgnxDRMA=; b=nxWIB+V0jgRwWyQvtWSxE6ulKetItHBNZgnTpmt7IBPXwt7SPtbS4XmO3XZvmWWqIP 1IJfeQzgBrrmZZr367C9CAI9PL5DZHb82QZja/ZlZqaDi9S5sIlLQsuMUL/rfk/SJlYz vUpmV7AqWJnowD+VMKYUfrflo+xceKbNpzK9Z6XRWNJhl1tCUvwxnNjvBHSjELR5nJKO 3XlOlZgJ9RwmYrnQTzPXwazjJe01d9xaFglYXMOYBMfg4cWGhApkY4yliS1bCSaCEQGp cdewSpLVBDv0JC1utm8acDJAdQBFmv1+MfWYSHSH4QscwZhGzjMU6lCPU6txGs0dFvjw LvfQ==
X-Gm-Message-State: AJIora/pxoAIqzE2CNx87V0NySZtDkgCnNigB4Cs8nLJ4dddQ+Vv/LSU mnfLTszvu+xS4ATe4YoJ54nj1M3ZGTuw3yMPfpM=
X-Google-Smtp-Source: AGRyM1vmLU6d+I9kON3u46RLZD26Nfa9NssZKbzDEyInKI50XKNApUPt8+YuGrHd8TJ7bLdYeAJhpBEUnA0nhCjeOIY=
X-Received: by 2002:a5d:69ca:0:b0:21d:640c:79f6 with SMTP id s10-20020a5d69ca000000b0021d640c79f6mr7368637wrw.309.1657789943786; Thu, 14 Jul 2022 02:12:23 -0700 (PDT)
MIME-Version: 1.0
References: <alpine.DEB.2.21.2206301429210.7292@hp8x-60.cs.helsinki.fi> <AEE43039-8EA0-4FB9-A605-C5C845DF4355@apple.com> <alpine.DEB.2.21.2207041843260.7292@hp8x-60.cs.helsinki.fi> <CAAK044TTZKXphE2rW7aFc2TnBLmMK0U+J61ZKzZXYvOmX_TdSA@mail.gmail.com> <alpine.DEB.2.21.2207120355450.7292@hp8x-60.cs.helsinki.fi>
In-Reply-To: <alpine.DEB.2.21.2207120355450.7292@hp8x-60.cs.helsinki.fi>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Thu, 14 Jul 2022 02:12:12 -0700
Message-ID: <CAAK044TGu8WMn1ht0tqyKVK+sSg6POrLU3HU5VE8yd8ouMHb8w@mail.gmail.com>
To: Markku Kojo <kojo@cs.helsinki.fi>
Cc: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>, Vidhi Goel <vidhi_goel@apple.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b6323b05e3c04caf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ERcijQ6zAT_I8uboVquK0J06XOI>
Subject: Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jul 2022 09:12:26 -0000

Hi Markku,

Thanks for the comments. I think we're mostly on the same page for RFC9002.
I put some comments on the issue 1 part.

On Mon, Jul 11, 2022 at 7:54 PM Markku Kojo <kojo@cs.helsinki.fi> wrote:

>
> > BTW, my intention is not saying RFC9002 is overly aggressive. I just
> meant comparing with reno precisely might
> > not be a very good idea for modern networks.
>
> Agreed, it is not overly aggressive.
>
> I am not saying that CUBIC should be precisely as aggressive as Reno even
> though its design goal has been to be equally aggressive in the
> Reno-friendly region.
>
> Instead, with the issue 1, for example, a CUBIC flow competing with a
> Reno flow will incorrectly and against its design goal opt out
> roughly every second cwnd decrease that the Reno flow executes. Doesn't
> that result in systematic and significant difference in peformance like
> the measuement results that I've pointed to also confirm?
>
> I think we'll need more analysis on this point.
Let's say a CUBIC connection has 50 packets cwnd and a Reno connection has
51 packets cwnd, the available buffer is only 100 packets.
In this case, I'm not very sure which connection of packets will be dropped
hence not sure about the consequences.
I still believe we cannot be sure until we see some deep analysis for this.
This may take time, but I think it's necessary to get the conclusion on
this point.
--
Yoshi