Re: [iccrg] AIMD versus AIAD

Bob Briscoe <ietf@bobbriscoe.net> Fri, 20 November 2020 17:53 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583243A0CED for <iccrg@ietfa.amsl.com>; Fri, 20 Nov 2020 09:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level:
X-Spam-Status: No, score=-1.1 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 uHTDq4ICxygy for <iccrg@ietfa.amsl.com>; Fri, 20 Nov 2020 09:53:18 -0800 (PST)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 3E9093A0CD7 for <iccrg@irtf.org>; Fri, 20 Nov 2020 09:53:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xoitpAHJ10IPUKz/qj1e0XJEYXriuITINkQ/tKEh3nk=; b=rrI2mX5YdTHTxs+72kUl3PVlW uM/B1RXaddIRs/Bfa+8vLMkJn045LGbwht+1aT/HSupW1Q4CPL59aEt5l4UOZiNcxuk87xMxW5toZ 2TiEQU4QYujnbPRsLWDeO3JzVrH12AUeR4x98pZqtN9DqCu7NbhEoRxYGHNYzrbT3I4n3CX60rQw9 1Ev+EsCD4tSGtMR53uIhcRI4YEcEFW4xgiJiYVJbzRIm0F3OykDpoc71G0o6Ixzg3sk3clCka5vZ8 4oh3c+j8mek0pgNwRLfeyiWpYbYWnX4G+jWWlSSDDpSV+opxastPZyx6RnV4YeGDheJNmQiwyiCfv fgi5SUHNw==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:60600 helo=[192.168.1.11]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1kgAax-00A7bN-NQ; Fri, 20 Nov 2020 17:53:16 +0000
To: Jana Iyengar <jri.ietf@gmail.com>, Jonathan Morton <chromatix99@gmail.com>
Cc: iccrg IRTF list <iccrg@irtf.org>
References: <5026FF59-8D58-4E7A-9026-42CE387E934D@gmail.com> <CACpbDccGRCdW1+mF3UHFdF6D8bA46jeczeTx24vJ1a7Z8ZbvJw@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <6cb5762b-7c7a-2237-eba8-1ec3246133b5@bobbriscoe.net>
Date: Fri, 20 Nov 2020 17:53:14 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CACpbDccGRCdW1+mF3UHFdF6D8bA46jeczeTx24vJ1a7Z8ZbvJw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------F6FD887552A6E24496183203"
Content-Language: en-GB
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/Ojd_LgUW_q7IMkUQO3JEtNzNg84>
Subject: Re: [iccrg] AIMD versus AIAD
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2020 17:53:20 -0000

Jonathan,

On 20/11/2020 07:59, Jana Iyengar wrote:
> Jonathan,
>
>     MD:  O(1) signals causes O(N) reduction in cwnd.
>
>
> That's not quite right. MD refers to a multiplicative reduction in the 
> rate or window _per RTT_. That is, the reduction in the window is 
> f(window). That's a critical aspect of the definition of all these 
> terms. This goes all the way back to Chiu and Jain 
> <https://www.cse.wustl.edu/~jain/papers/ftp/cong_av.pdf>.
>
>     Conversely, looking at DCTCP and ignoring the low-pass filters
>     which disappear in the long run, each CE mark causes half a
>     segment to be subtracted from the cwnd.  This is classic Additive
>     Decrease. 
>
>
> For the same reason, this is not correct. Presumably, since the number 
> of CE marks are f(window), I would argue that the reduction _over an 
> RTT_ is f(window). That makes this MD, not AD.

[BB]  Indeed, thanks Jana,

@Jonathan, the difference you are grappling with between DCTCP's 
response and Reno's is what makes Reno doubly multiplicative, whereas 
DCTCP is singly multiplicative (deliberately). The doubly multiplicative 
cause Reno's sqrt.

Let's see if I can explain this. I'll outline rough 'balance equations' 
between:
* the addition to W in a round and
* the subtractions from W in a round.
In steady state the two will be equal.
(But please don't beat me up about the numerical constants - they aren't 
correct 'cos I'm simplifying)
I'll use 'NACK' to mean either a dropped packet or an ECN-marked packet

==Reno==
AI: W <- W + 1                                                 Eqn (1)
MD: W <- W - W/2 * (probability of at least one NACK in a round)        
Eqn (2)

Definition: p is the probability of any individual packet being marked 
during this round.
So the probability of any one of W packets being NACK'd is p*W.

So Eqn(2) becomes
MD: W <- W - W/2 * p*W

At balance: AI = MD
     1 = pW^2/2
Rearranging: W = sqrt(2/p)

With a more precise model, the constant is roughly 3/2, not 2, but I'll 
just call it C for now.
W = sqrt(C/p)
or
p = C/(W^2)                                                             
Eqn (3)

==DCTCP==

AI: W <- W + 1                                                         
     Eqn (4)
MD: W <- W - alpha*W/2 * (probability of at least one NACK in a round)   
     Eqn (5)
As with Eqn (3), that is:
MD: W <- W - alpha*W/2 * p*W

At balance: AI = MD
     1 = p*alpha*W^2/2

Given alpha is the EWMA of p over a number of rounds, in steady state, 
alpha -> p.
     1 = p^2 * W^2/2
Rearranging: W = 2/p                                                     
Eqn (6)

===Scaling==

Let's call the number of NACKs in a round, v.
By the definition of p:
     v = pW.

Substituting from the balance formulae for W:
v_reno = C/(W^2) * W
             = C/W                                                     
             Eqn (7)

v_dctcp: v = p * 2/p
                 = 2       Eqn (8)

So, as W increases,
     v_reno reduces proportionately.
     v_dctcp remains invariant at 2

That's why DCTCP can be called scalable.


HTH


Bob

>
> - jana
>
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/