Re: [rmcat] Proposed update to draft-ietf-rmcat-coupled-cc

Anna Brunstrom <anna.brunstrom@kau.se> Fri, 28 December 2018 23:20 UTC

Return-Path: <anna.brunstrom@kau.se>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B5E12426E for <rmcat@ietfa.amsl.com>; Fri, 28 Dec 2018 15:20:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3
X-Spam-Level: ***
X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kau.se
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 aOYs-bM1zM3a for <rmcat@ietfa.amsl.com>; Fri, 28 Dec 2018 15:20:03 -0800 (PST)
Received: from smtp1.kau.se (smtp1.kau.se [130.243.21.250]) by ietfa.amsl.com (Postfix) with ESMTP id 59409124D68 for <rmcat@ietf.org>; Fri, 28 Dec 2018 15:20:00 -0800 (PST)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by smtp1.kau.se (Postfix) with ESMTP id 0ADDB18173F7 for <rmcat@ietf.org>; Sat, 29 Dec 2018 00:20:00 +0100 (CET)
Received: from Exch-A2.personal.kau (exch-a2.kau.se [130.243.19.83]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id wBSNJwiZ138971 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for <rmcat@ietf.org>; Sat, 29 Dec 2018 00:19:58 +0100
Received: from [192.168.1.100] (130.243.27.149) by Exch-A2.personal.kau (130.243.19.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1415.2; Sat, 29 Dec 2018 00:19:39 +0100
To: rmcat@ietf.org
References: <123D38B4-AF74-40FF-B7F9-0A1A9CFCFCC9@ifi.uio.no>
From: Anna Brunstrom <anna.brunstrom@kau.se>
Message-ID: <3f1eaa60-275e-c668-ce08-bc142fd8147c@kau.se>
Date: Sat, 29 Dec 2018 00:19:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <123D38B4-AF74-40FF-B7F9-0A1A9CFCFCC9@ifi.uio.no>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: [130.243.27.149]
X-ClientProxiedBy: Exch-A2.personal.kau (130.243.19.83) To Exch-A2.personal.kau (130.243.19.83)
X-Bayes-Prob: 0.9999 (Score 5, tokens from: outbound, outbound-kau-se:default, kau-se:default, base:default, @@RPTN)
X-p0f-Info: os=Windows 7 or 8, link=Ethernet or modem
X-CanIt-Geo: No geolocation information available for 192.168.1.100
X-CanItPRO-Stream: outbound-kau-se:outbound (inherits from outbound-kau-se:default, kau-se:default, base:default)
X-Canit-Stats-ID: 09XhzjWvX - 98612c8d061f - 20181229
X-Antispam-Training-Forget: https://mailfilter.sunet.se/canit/b.php?c=f&i=09XhzjWvX&m=98612c8d061f&rlm=outbound-kau-se&t=20181229
X-Antispam-Training-Nonspam: https://mailfilter.sunet.se/canit/b.php?c=n&i=09XhzjWvX&m=98612c8d061f&rlm=outbound-kau-se&t=20181229
X-Antispam-Training-Phish: https://mailfilter.sunet.se/canit/b.php?c=p&i=09XhzjWvX&m=98612c8d061f&rlm=outbound-kau-se&t=20181229
X-Antispam-Training-Spam: https://mailfilter.sunet.se/canit/b.php?c=s&i=09XhzjWvX&m=98612c8d061f&rlm=outbound-kau-se&t=20181229
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kau.se; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=canit; bh=dmC0Jej5pQ3 GCMIuBXpVYZxStLBimwgSb3uYcraFqzY=; b=HP2ui49gGX7TZGHtNoxhZqisT10 jYnGlX4CWlrahvtxKh6W6CWjGJpFwwTWZAO6u8imLcoynASU9xJaiO9TXrGW1fo9 ffAe8jPv/+GH0XdGuka1H1nqie07xxRyZ8HXQ6hyELvjK1hZvyKa4iRsoN/mnGOU xbJKxddTMzwS1JmW9FlRlqpydZQJiEISYKZwnCNEQSLWeLOk6Ty9E+effB9rXmoy n52DIetv4h8iTQRGddQdHry936FZ7SlYwWbq0i0fz2k3jAb/QYXXchrQLwNuRDhb VISVNQYFjO2XMrqcll5JZ4u3FDWrWuTEN4ePh450PExXYTZHj3S4SVoovfg==
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/h-7_VTL3TjbBGXn943kkq19BAEI>
Subject: Re: [rmcat] Proposed update to draft-ietf-rmcat-coupled-cc
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Dec 2018 23:20:05 -0000

Hi Michael, all,

I also had two questions on the new algorithm (as an individual)

- Step (d) checks if there are flows that are limited by their DR and 
cannot accept their share of the TLO. In principle I guess this step 
would need to be repeated until there are no flows that can not use 
their share as the TLO may again grow in this step?

- Step (d) also looks strange to me. Seems FSE_R(i) > DR(i) would never 
be true after step (c)?

Cheers,
Anna


On 2018-12-11 09:14, Michael Welzl wrote:
> Dear all,
>
> In Bangkok, Julius Flohr presented an issue with application-limited senders and our "active" coupling algorithm in draft-ietf-rmcat-coupled-cc-07
> Indeed we kept it out of the algorithm on purpose as a way to keep it simple (early, when we brought our algorithm to the group, simplicity was a major concern) - see slide 6 here:
> https://www.ietf.org/proceedings/88/slides/slides-88-rmcat-0.pdf
> "included in the next version" never happened ... well better late than never  ;-)
>
> Julius also proposed a fix that looked very simple, but it didn't really work well for more than 2 flows. Thanks to his help, we can now present a double-checked algorithm update that fixes the problem. Please find this algorithm update (changing the text in section 5.3.1) below. Given that our draft is already in the RFC editor queue, how should we now proceed?
>
> Cheers,
> Michael & Safiqul
>
> PS: two further minor text changes are necessary: 1) the new algorithm talks about the Desired Rate (DR), which the draft now only introduces in appendix C; we would need to move this definition up, to section 5.3. Also, algorithm 2 in section 5.3.2 just changes step 3 (a) of algorithm 1, but because it was so short, the text currently just copies the whole algorithm from the section above. Since the algorithm is now longer, we think it would be better to change this text to just say that step 3 (a) from above is altered for algorithm 2.
>
>
> ---------------------------------------------------------------------------
>
>
> OLD:
>
>        (a)  It updates S_CR.
>
>               S_CR = S_CR + CC_R(f) - FSE_R(f)
>
>
>        (b)  It calculates the sum of all the priorities, S_P.
>
>               S_P = 0
>               for all flows i in FG do
>                   S_P = S_P + P(i)
>               end for
>
>
>        (c)  It calculates the sending rates for all the flows in an FG
>             and distributes them.
>
>               for all flows i in FG do
>                   FSE_R(i) = (P(i)*S_CR)/S_P
>                   send FSE_R(i) to the flow i
>               end for
>
>
> ***************************************************************************************
> ***************************************************************************************
>
>
> NEW:  [NOTE: (a) and (b) as above ]
>
>        (a)  It updates S_CR.
>
>               S_CR = S_CR + CC_R(f) - FSE_R(f)
>
>
>        (b)  It calculates the sum of all the priorities, S_P.
>
>               S_P = 0
>               for all flows i in FG do
>                   S_P = S_P + P(i)
>               end for
>
>
>        (c)  It calculates the sending rates for all the flows in
>             an FG, the total leftover rate (TLO) from flows that are
>             limited by their desired rate, and the sum of the priorities
>             of all other flows, S_P2.
>
>               TLO = 0
>               S_P2 = 0
>               for all flows i in FG do
>                   FSE_R(i) = P(i) * S_CR / S_P
>                   if FSE_R(i) > DR(i) then
>                      TLO = TLO + FSE_R(i) - DR(i)
>                      FSE_R(i) = DR(i)
>                   else
>                      S_P2 = S_P2 + P(i)
>                   end if
>               end for
>
>
>        (d)  It checks if there are flows that are limited by their DR
>             and cannot accept their share of the TLO, and updates TLO
>             and S_P2 accordingly.
>
>               for all flows i in FG do
>                   if FSE_R(i) > DR(i) then
>                       if FSE_R(i) + TLO * P(i) / S_P2 > DR(i) then
>                          TLO = TLO - ( DR(i) - FSE_R(i) )
>                          FSE_R(i) = DR(i)
>                          S_P2 = S_P2 - P(i)
>                       end if
>                   end if
>               end for
>
>
>        (e)  It assigns the non-limited flow their share of the total
>             leftover rate and sends all the rates to all the flows.
>
>               for all flows i in FG do
>                   if FSE_R(i) < DR(i) then
>                      FSE_R(i) = FSE_R(i) + P(i) * TLO / S_P2
>                   end if
>                   send FSE_R(i) to the flow i
>               end for