[tcpm] Comments on CUBIC slides for tcpm meeting on Fri

Markku Kojo <kojo@cs.helsinki.fi> Fri, 29 July 2022 11:23 UTC

Return-Path: <kojo@cs.helsinki.fi>
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 6FF7FC1C9FC4 for <tcpm@ietfa.amsl.com>; Fri, 29 Jul 2022 04:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi
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 mFocXtrxi017 for <tcpm@ietfa.amsl.com>; Fri, 29 Jul 2022 04:23:09 -0700 (PDT)
Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21142C1C9528 for <tcpm@ietf.org>; Fri, 29 Jul 2022 04:23:05 -0700 (PDT)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Fri, 29 Jul 2022 14:23:01 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:subject:message-id:mime-version:content-type; s= dkim20130528; bh=QjrnO43l0tbc/22G+GYGsb5CEobk6KM8bKmvzqDlrLU=; b= bgC9fOhu0eyZXbE0cPM/DiLWr2mFZZnJRBF8IwOOZThm9xFoNOlcZPuzGHu7TDcB eSlR7+CfKKpjDnCUpspmB3ryGbJ7zXl0/Ccx3AqP+8vFm2zWK189YGCgCPT3KhwS 2qhmNq20HyFXT5fAN8+u9El9McM57B5QieLxRl5AfiQ=
Received: from hp8x-60 (85-76-102-15-nat.elisa-mobile.fi [85.76.102.15]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Fri, 29 Jul 2022 14:23:01 +0300 id 00000000005A0403.0000000062E3C315.0000332B
Date: Fri, 29 Jul 2022 14:22:59 +0300
From: Markku Kojo <kojo@cs.helsinki.fi>
To: tcpm@ietf.org
Message-ID: <alpine.DEB.2.21.2207290443390.7292@hp8x-60.cs.helsinki.fi>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/vt9GXOqxm3GnxYj-f7hRiF6IeD4>
Subject: [tcpm] Comments on CUBIC slides for tcpm meeting on Fri
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: Fri, 29 Jul 2022 11:23:16 -0000

Hi all,

I browsed quickly the slide set for rfc8312bis.

A few comments about the issues as the text on slides does not 
quite capture all issues that well.


Slide 2, Issue 2:

It is not that doubling in slow start makes 0.5 convenient, but it makes 
it necessary.

Beta = 0.5 is designed such that the buffer *is full* after the decrease 
in slow start. Therefore, using Beta > 0.5 results overload, i.e, 
unnecessarily injecting packets that are only dropped by a tail-drop 
router due to overload.

Please see the reasoning for Beta = 0.5 in [Jacob88].

We have tons of studies and over three decades of experience for Beta= 0.5 
in slow start, so for a standards track RFC we don't need any additional 
testing. It is already the currently specified draft standard (RFC 5681). 
Instead, deviating from Beta=0.5 when in slow start is in conflict with 
RFC 5681 and requires justification. The draft does not give any.
Nor does it say what potential benefits it would bring. AFAICT nothing, it 
only hurts the flow itself. Of course, being too aggressive during 
recovery from slow-start overshoot when competing with other flows will 
potentially give unustfied gain for the flow as it steals the capacity 
from others.

[Jacob88] V. Jacobson, Congestion avoidance and control, SIGCOMM '88.

Issue 4 and 5 are missing. I've recently sent a separate description for 
the issue 4. For issue 5, we have discussion in github and summary sent 
earlier. I try to send a separate issue description to the wg list 
shortly I am not able to send it before the wg meeting.

Thanks,

/Markku