Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-eval-test-09: (with COMMENT)

Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> Thu, 23 May 2019 17:02 UTC

Return-Path: <zaheduzzaman.sarker@ericsson.com>
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 6D16712012E; Thu, 23 May 2019 10:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 N5kO0hAbbl35; Thu, 23 May 2019 10:02:22 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on060a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::60a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A7012013C; Thu, 23 May 2019 10:02:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tIpbip9xyJL01LYg1bH1/21M3ZlxSBufumbi7trlbII=; b=n3z8CfS5MmWI/rk1IndCvDwBKPBJT2VGh1wbzWsvH23rdx49u63vMpOWtqnxSyIWM8ycjdtvJ2XN96jPh+CpdX5mJZ+CuCwrdWxtiPsnhOg9606bjbweJMuKHftiqw4EdufpXafUgM/gpVNsJRiqJkMVyYWehwT9SW76GRaiV8A=
Received: from HE1PR0701MB3020.eurprd07.prod.outlook.com (10.168.93.142) by HE1PR0701MB2747.eurprd07.prod.outlook.com (10.168.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.12; Thu, 23 May 2019 17:02:14 +0000
Received: from HE1PR0701MB3020.eurprd07.prod.outlook.com ([fe80::50d9:a935:8171:d8a7]) by HE1PR0701MB3020.eurprd07.prod.outlook.com ([fe80::50d9:a935:8171:d8a7%10]) with mapi id 15.20.1922.017; Thu, 23 May 2019 17:02:14 +0000
From: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
To: Colin Perkins <csp@csperkins.org>, Mirja Kuehlewind <ietf@kuehlewind.net>
CC: Benjamin Kaduk <kaduk@mit.edu>, "rmcat-chairs@ietf.org" <rmcat-chairs@ietf.org>, Benjamin Kaduk via Datatracker <noreply@ietf.org>, "draft-ietf-rmcat-eval-test@ietf.org" <draft-ietf-rmcat-eval-test@ietf.org>, "rmcat@ietf.org" <rmcat@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-rmcat-eval-test-09: (with COMMENT)
Thread-Index: AQHU3+zOU8aGVZBTcE6hlWnTuotx+6YZPKiAgAFdjACAADdUAIAN1FcAgD+pwQCAESSVgA==
Date: Thu, 23 May 2019 17:02:14 +0000
Message-ID: <F7FD5C7A-1871-443A-B482-79F91ABE1D7C@ericsson.com>
References: <155197033601.24667.6429871717336324511.idtracker@ietfa.amsl.com> <3C53B15F-9C66-4C64-8C15-A643EADE6B54@ericsson.com> <20190323134227.GZ88959@kduck.mit.edu> <0E1DBC98-6486-483C-8CEA-893BAC4F930E@ericsson.com> <20190324135134.GM77890@kduck.mit.edu> <FDC681F4-5EDC-466E-9A73-77B00F76FBEB@kuehlewind.net> <90551451-DAB9-4444-ABBB-3331A3FF4A2A@csperkins.org>
In-Reply-To: <90551451-DAB9-4444-ABBB-3331A3FF4A2A@csperkins.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.19.0.190512
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com;
x-originating-ip: [85.238.211.27]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f28da8a7-4b65-488e-b5c1-08d6dfa0679b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2747;
x-ms-traffictypediagnostic: HE1PR0701MB2747:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <HE1PR0701MB274754108CFDC12D39AF85E99F010@HE1PR0701MB2747.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00462943DE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39860400002)(366004)(376002)(396003)(189003)(199004)(256004)(54906003)(81156014)(66476007)(66446008)(64756008)(73956011)(446003)(76176011)(58126008)(316002)(71200400001)(76116006)(110136005)(8676002)(66556008)(33656002)(81166006)(66066001)(68736007)(102836004)(66946007)(2616005)(6116002)(6506007)(53546011)(3846002)(71190400001)(25786009)(36756003)(82746002)(8936002)(11346002)(99286004)(476003)(86362001)(7736002)(2906002)(53936002)(83716004)(4326008)(6436002)(6306002)(6512007)(305945005)(6246003)(14454004)(508600001)(229853002)(26005)(5660300002)(6486002)(966005)(486006)(44832011)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2747; H:HE1PR0701MB3020.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: fZSnfKkKs0aL15Lunkrpu/neGjFGrX23tO0XVJnqlkbtjWddEFHyqzHCF9iChClqu+LYx7+hqYQ6KfkexW/scpbfguaFVB/6MSqAVfs45Ozhe/mWn8xR4pDKYlYv841UXUwBFN60qWNQeJcVTsFkcufmX6j/Sr5heWDHW0b7Z0eMCx8YPu3Z9uyi7GZsYDxQ83++9i7lPJuOIVo3S35fL2FMAVfnkreFcKVNzxTJS3FQH6RF3/1Cj1s/amyvSqDLSM2wMAMnpQU+GWKmH9zmbrSDvzBx7tAGTL+FTV4JAsp3AOMXt1PCMLPXjLkxFMBCRzYQNhH+rUj9B89p/JnlGVLkj9P/eyJKVvjXsDnK5VPIB2iH7iZDcUL65kby/bYAKLCOU22UpT/9dy2pNmI9oIGOTSIOvsbVP3sZlDAOQkQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <AB6D94AA8F9A8C46A8893A79CA5A2215@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f28da8a7-4b65-488e-b5c1-08d6dfa0679b
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2019 17:02:14.4041 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zaheduzzaman.sarker@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2747
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/tNZ0-zNxfdptX4peQc5b2Cif0ns>
Subject: Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-eval-test-09: (with COMMENT)
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: Thu, 23 May 2019 17:02:26 -0000

Hi Colin,

I have just submitted a -10 version where I believe I have addressed all the comments I have received so far.

BR

Zahed   
 
Ericsson Research
 
Network Architecture and Protocols 
Network Orchestration & Automation
zaheduzzaman.sarker@ericsson.com
 
Ericsson
Torshamnsgatan 23
164 83, Stockholm
Sweden
 

On 2019-05-12, 23:15, "Colin Perkins" <csp@csperkins.org> wrote:

    Hi,
    
    Just to follow-up: are there still updates required from the authors of this doc, or is it ready to progress?
    
    Colin
    
    
    
    > On 2 Apr 2019, at 10:02, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
    > 
    > Hi Zahed, hi Ben,
    > 
    > Just a quick note below.
    > 
    >> On 24. Mar 2019, at 14:51, Benjamin Kaduk <kaduk@mit.edu> wrote:
    >> 
    >>>>   Section 3
    >>>> 
    >>>>            +  Bottleneck-link capacity: defines minimum capacity of the
    >>>>               end-to-end path
    >>>> 
    >>>>   I'm not sure I'd describe this as the "minimum capacity of the
    >>>>   end-to-end path", since attempts to use anything larger than this value
    >>>>   will pile up at the bottleneck.
    >>>> 
    >>>> [ZS] hmm, I guess that is why that link will act as bottleneck link for a respective testcase. If the flows remain below that capacity it should not experience queuing and as you said anything above that capacity will observe queuing. The job of the congestion control algorithm will be to avoid queuing.
    >>> 
    >>>   I think I was expecting "maximum capacity" to be more appropriate than
    >>>   "minimum capacity".  Perhaps I'm confused about what is intended here.
    >>> 
    >>> (disclaimer. this has been done in the long past and I hope my memory is supporting me on explaining it ☺)
    >>> 
    >>> The thinking was that the bottleneck-link capacity was not equals to the maximum link capacity. That means if the maximum link capacity is X then the bottleneck-link capacity is Y , where Y<X and (X-Y) capacity is used by other traffic traversing that link. Hence, in the test if a link is assumed to be bottleneck then the "the bottleneck-link capacity" is the minimum capacity available to the media flow traversing that path. 
    >> 
    >> Ah, that makes sense.  Maybe "minimum guaranteed capacity" or similar would
    >> convey the intent better.
    > 
    > The word “guaranteed” would be confusing here as people would associate this with some kind of resource reservation. Maybe "minimum link capacity of the end-to-end path”.
    > 
    > Mirja
    > 
    > 
    > 
    
    
    
    -- 
    Colin Perkins
    https://csperkins.org/