IETF Logo Mail Archive

Re: [tcpm] WGLC for draft-ietf-tcpm-alternativebackoff-ecn-06

Michael Welzl <michawe@ifi.uio.no> Mon, 19 March 2018 16:34 UTC

Return-Path: <michawe@ifi.uio.no>
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 3254E12D874 for <tcpm@ietfa.amsl.com>; Mon, 19 Mar 2018 09:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 lkbQUEdeew19 for <tcpm@ietfa.amsl.com>; Mon, 19 Mar 2018 09:34:11 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCE612D7FC for <tcpm@ietf.org>; Mon, 19 Mar 2018 09:34:11 -0700 (PDT)
Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <michawe@ifi.uio.no>) id 1exxjd-00059P-7Y; Mon, 19 Mar 2018 17:34:09 +0100
Received: from dhcp-82c4.meeting.ietf.org ([31.133.130.196]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.90_1) (envelope-from <michawe@ifi.uio.no>) id 1exxjc-000CrB-Gj; Mon, 19 Mar 2018 17:34:09 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_6A258F7F-E629-47FD-9D18-E8D904F5F5AD"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Welzl <michawe@ifi.uio.no>
X-Priority: 3
In-Reply-To: <31CCB8D4D5D645849D5804DFB17FD030@srichardlxp2>
Date: Mon, 19 Mar 2018 16:34:07 +0000
Cc: tcpm@ietf.org
Message-Id: <2945F9B8-60FA-49E4-86AC-36E2C331CE85@ifi.uio.no>
References: <7A3A6ECE-550B-4E5F-9D61-83C8969A7B93@fh-muenster.de> <23187136694049B3BEA2C7FAD794E280@srichardlxp2> <AD0AB4B8-4FE5-4DE1-B525-AA706011463C@ifi.uio.no> <31CCB8D4D5D645849D5804DFB17FD030@srichardlxp2>
To: Richard Scheffenegger <rs.ietf@gmx.at>
X-Mailer: Apple Mail (2.3273)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 31.133.130.196 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.130.196; envelope-from=michawe@ifi.uio.no; helo=dhcp-82c4.meeting.ietf.org;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.015, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: EBBA00702A360B187442739D7C862B434AFE4B62
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/gp20zUyl8VTGLv_kSZ4AIvZsYnE>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-alternativebackoff-ecn-06
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 19 Mar 2018 16:34:14 -0000

Hi,


> On Mar 19, 2018, at 3:31 PM, Richard Scheffenegger <rs.ietf@gmx.at> wrote:
> 
> 
> Hi Michael,
> 
> Just thinking that the difference between loss vs. ECN cwn reduction might be defined as a relative value of each other, rather than an absolute;

Ah, got it.


> In my example, Cubic on FreeBSD used beta 0.8, while Cubic Linux uses 0.7; with the research showing a sensible Cubic ECN reaction on Linux being 0.85, correct? (~50% closer to 1).

Correct - though beta_ecn = 0.8 also worked fine for Cubic; 0.85 just seemed to be a slightly better choice in our experiments.


> So when using Cubic w/ beta 0.8 (as FreeBSD), would a sensible value for Cubic ECN there a value of 0.9?

- no, I don’t think it works like this. Whether a value for backoff with ECN is good or bad depends on the overall algorithm behavior, including its increase behavior - not just on its loss backoff factor.

Cheers,
Michael

v2.46.0 | Report a Bug | By Email | System Status