From nobody Wed Mar 1 05:49:57 2017 Return-Path: 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 8FF6C1294F3 for ; Wed, 1 Mar 2017 05:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 P-FcL7hSA__n for ; Wed, 1 Mar 2017 05:49:53 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AF8129493 for ; Wed, 1 Mar 2017 05:49:53 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id u48so30608984wrc.0 for ; Wed, 01 Mar 2017 05:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=hugE3IuYKPPXw5Pxtc40kxDd3kBtoEUxc7PWtdUWvKc=; b=PN9Tk3s3eflqy9zorirqzteH5cn77tEeQRTZ32a4DZbMnJjt2HfD1/wOuf1RFOklhm zPm3EzgKrtHuIo6vOcibTcuiI8xaaUzWYh9/jSsJeLipYJyy1Fci0d3MloHBZCf7Jw6q AAfIRLTPvyrieHi347p1kPrvFuam7oA8ATaf+TvD//YKNHTbqeMKWVb9V1ky6bNI/ZSj 1mZvwaeNW7DKwX51pKhJ3qF/CBqc9NffkP+x6XIIby3D981Kf/u9pngm+jY8h0c56fx3 weKQfc4dyEoNVDqH90zsY9SB2ccD68VFQiENnEOEWwBNXc5HLHK/8zizJNamUQmZGq/V x6jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=hugE3IuYKPPXw5Pxtc40kxDd3kBtoEUxc7PWtdUWvKc=; b=KPJuNiqS6g8fJyFr3ckKH+EddKnDWlHvgUtG3fkPPnPeAHb+ZtOT9kSxK+MJ7u8rno onmWN/guROtg2zh0EqsbQu74v8bjeNsE7hqcTGwnXLHfAFcECtCo6Lt2VkyfVLmAGcVs lwIM8PJC6fEthny3IoB/CNBMCFE4S+X4sI3zUyfi8XBXDz3Rx0+rDU1EB/v/KaMJmyEA 4/EJlbyrf6i4IpezNL1cYFfe8CtL/WQSKmJdX8SQBfnZB6gHaW9uYP037eOorucvcHsG X5bZdMlAjmiidp/kydyF9zF1irQQnAYM/1ztJUysESYtltTLC9VVGawe2D1gETRUYpjk cPnA== X-Gm-Message-State: AMke39mvpLgeAJ0b8kstzpIUbHOFILiX+7D/xtLNPaMe11O6gijhLUvTqauaZcYhUa2w2cNwoqWzuK8uNQTzzQ== X-Received: by 10.223.178.9 with SMTP id u9mr6865412wra.121.1488376191711; Wed, 01 Mar 2017 05:49:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Wed, 1 Mar 2017 05:49:31 -0800 (PST) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 1 Mar 2017 14:49:31 +0100 Message-ID: To: rmcat@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rmcat] Doubt regarding REMB and SSRCs X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 13:49:55 -0000 Hi, It's not clear for me what the "SSRC feedback" entries in the REMB message mean. According to the draft [*]: -------------------- Num SSRC (8 bits): Number of SSRCs in this message. SSRC feedback (32 bits): Consists of one or more SSRC entries which this feedback message applies to. -------------------- At the same time, the draft says: --------------------- This feedback message is used to notify a sender of multiple media streams over the same RTP session of the total estimated available bit rate on the path to the receiving side of this RTP session. --------------------- The meaning of "RTP session" is hard to explain nowadays, so I'll assume it means "a media transport" (which in the context of WebRTC points to an ICE established "connection" which can carry multiple SSRC streams). So, if for example Alice is receiving audio (SSRC 1111) and video (SSRC 2222) over a BUNDLEd transport, and assuming Alice can just receive 500 kbits/s, how should REMB messages generated by Alice look like? Should these REMB messages contain both SSRC 1111 and SSRC 2222 and indicate 500000 as media bit rate? What would happen if Alice sends a REMB just including the SSRC 1111 and 500000 as media bit rate? Should Bob limit its audio bitrate up to 500kbit/s and send whatever he wants regarding its video stream? Thanks a lot. [*] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03 --=20 I=C3=B1aki Baz Castillo From nobody Wed Mar 1 06:17:02 2017 Return-Path: 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 A041D1295E2 for ; Wed, 1 Mar 2017 06:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 7e27CzQDOp3E for ; Wed, 1 Mar 2017 06:17:00 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601DB129474 for ; Wed, 1 Mar 2017 06:17:00 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id n11so339388wma.1 for ; Wed, 01 Mar 2017 06:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=f9CbsdaVufkG+SG3VARd4VnaN0df7tpW4+PDr3IIMT4=; b=fvbnGEzJauB8zQhV++DV80VZ5BnwcFD1AhbFRnqjdAJ3yjh5BDegn2hrzTTRHnYvGy 8B69GbyKu2rqvDBxm+bEifuBwZjkIlI4VgxSOkPMLLtmO8VKKAyT5FmzFUIasIZBHUra hBq/mexlKBYQBzRqwn1WAMpsnLJgB6Giip0yhR9pQOwFn6zVZeQGmBHWlF9kA7QY823n ymt6a8KSP/FiI//g+7Q+mlUH86J7Bv4O2cpfTEyklIKIZXjq4m+srngcJiub7f2UQ6+z rBRkiLRybAySjJXYmP4932X9+jti9zLkfVvnG8I0mBfZ/l8K2SLniWqkEU416KAISt4J dnZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=f9CbsdaVufkG+SG3VARd4VnaN0df7tpW4+PDr3IIMT4=; b=PBDC3YjcuZ58TPCa0UMBy1+bzh5DQUyw+Y/X3K4GkRg1w1s24S58Jvw3iuy/qZJoh8 3MGHc0KXWQPt4Ca6ubOmhSqqwX191fRcaU2Pn//ICMcKHymYDzDzVs0thNtn/20YNGzL WVVQnuL23TGlkpIdEUu8cBKPo6M7lC2RiHAwT6t3ilwTibGxLTBhmrEmTC9OSAOhb0hO Bkhdn+TE80C4vc5ujDs6FLQJgHYa3KJtC4m+TTx7GD9+BmnyAoId0XcjSfhKQOFJWdpm NQWzboKgHaEQAdHI5uWiP9dISRlef99IWVuJl98Q2zKcU5nM9GFpA7vf/4g3+wt9TIPg NApg== X-Gm-Message-State: AMke39mBYATO2eDURx/wof05tssoW6yPnHrjvB4Aaui+T+4/s5FcKXNIC2GZM1GqlrsOEGvK1OJEvekVYZUUSA== X-Received: by 10.28.142.73 with SMTP id q70mr3777633wmd.3.1488377818521; Wed, 01 Mar 2017 06:16:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Wed, 1 Mar 2017 06:16:38 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 1 Mar 2017 15:16:38 +0100 Message-ID: To: rmcat@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rmcat] Doubt regarding REMB and SSRCs X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 14:17:01 -0000 2017-03-01 14:49 GMT+01:00 I=C3=B1aki Baz Castillo : > It's not clear for me what the "SSRC feedback" entries in the REMB > message mean. According to the draft [*]: I've just found a related thread: https://mailarchive.ietf.org/arch/msg/rmcat/t71fzDtaQatyi2yA9wa0yRfhXHI ------------------------------------------------- >> the maximum bitrate, is it defined as the maximum bitrate for a particu= lar stream, or the maximum bitrate for the whole "Session"? > It depends on how many and which SSRCs are reported in the feedback messa= ge. As per the draft, it is up to the implementation (or the congestion con= trol algorithm) to choose which SSRCs, i.e., it could report just the SSRCs= of audio or video or a combination. ------------------------------------------------- So it seems that it's up to the sender to re-distribute the estimated bit rate across all the indicated SSRCs (if many in a single REMB), right? --=20 I=C3=B1aki Baz Castillo From nobody Wed Mar 1 12:34:43 2017 Return-Path: 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 DF3C6126BF7 for ; Wed, 1 Mar 2017 12:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 2s_aIB6LVLXd for ; Wed, 1 Mar 2017 12:34:41 -0800 (PST) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (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 2FABC126579 for ; Wed, 1 Mar 2017 12:34:41 -0800 (PST) X-Spam-Processed: mail.kau.se, Wed, 01 Mar 2017 21:34:33 +0100 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 213.113.183.245 X-MDArrival-Date: Wed, 01 Mar 2017 21:34:33 +0100 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: rmcat@ietf.org To: rmcat@ietf.org References: From: Anna Brunstrom Message-ID: <7bf39539-365d-c3d6-5d9d-1be305033be8@kau.se> Date: Wed, 1 Mar 2017 21:34:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rmcat] Scheduling of virtual interim meeting X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 20:34:43 -0000 Dear all, The rmcat virtual interim meeting will be held on Thursday April 27, 17:00-19:00 CET. Please mark the date and time in your calendars. Best Regards, Anna On 2017-02-18 19:22, Anna Brunstrom wrote: > Dear all, > > As previously announced, we plan to hold a virtual interim to progress > the rmcat work. In order to schedule the interim, please indicate your > availability at http://doodle.com/poll/xmzc3hwvuiz2d63s. > > The poll will close on Monday February 27. > > Best Regards, > Anna > > > On 2017-02-10 18:38, Anna Brunstrom wrote: >> Dear all, >> >> As we only have one probable and three confirmed attendees for an >> rmcat session in Chicago, we will not hold a meeting this time. >> >> We will come back shortly for instead scheduling a virtual interim a >> few weeks after IETF 98. >> >> Best Regards, >> Anna >> >> >> On 2017-02-01 11:09, Martin Stiemerling wrote: >>> Dear all, >>> >>> The WG chairs would like to get a poll about who out of the rmcat WG >>> intends to travel to the IETF 98 meeting in Chicago. >>> >>> Please let us know until Feb 5th midnight by replying to this email. >>> >>> We would plan for an interim meeting shortly after the IETF 98 >>> meeting in case that there is not a critical mass intending to >>> attend a RMCAT session. >>> >>> Regards, >>> >>> Martin >>> >> >> > From nobody Fri Mar 3 07:20:23 2017 Return-Path: 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 3BD211294BC for ; Fri, 3 Mar 2017 07:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 J2EoU_vVJkTM for ; Fri, 3 Mar 2017 07:20:20 -0800 (PST) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (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 7CC1812940F for ; Fri, 3 Mar 2017 07:20:20 -0800 (PST) X-Spam-Processed: mail.kau.se, Fri, 03 Mar 2017 16:20:11 +0100 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 193.11.155.184 X-MDArrival-Date: Fri, 03 Mar 2017 16:20:11 +0100 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: rmcat@ietf.org To: rmcat@ietf.org References: <7bf39539-365d-c3d6-5d9d-1be305033be8@kau.se> From: Anna Brunstrom Message-ID: Date: Fri, 3 Mar 2017 16:20:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7bf39539-365d-c3d6-5d9d-1be305033be8@kau.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rmcat] Scheduling of virtual interim meeting X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:20:22 -0000 Dear all, Small correction. The time should be 17:00-19:00 CEST. Anna On 2017-03-01 21:34, Anna Brunstrom wrote: > Dear all, > > The rmcat virtual interim meeting will be held on Thursday April 27, > 17:00-19:00 CET. > > Please mark the date and time in your calendars. > > Best Regards, > Anna > > > On 2017-02-18 19:22, Anna Brunstrom wrote: >> Dear all, >> >> As previously announced, we plan to hold a virtual interim to >> progress the rmcat work. In order to schedule the interim, please >> indicate your availability at http://doodle.com/poll/xmzc3hwvuiz2d63s. >> >> The poll will close on Monday February 27. >> >> Best Regards, >> Anna >> >> >> On 2017-02-10 18:38, Anna Brunstrom wrote: >>> Dear all, >>> >>> As we only have one probable and three confirmed attendees for an >>> rmcat session in Chicago, we will not hold a meeting this time. >>> >>> We will come back shortly for instead scheduling a virtual interim a >>> few weeks after IETF 98. >>> >>> Best Regards, >>> Anna >>> >>> >>> On 2017-02-01 11:09, Martin Stiemerling wrote: >>>> Dear all, >>>> >>>> The WG chairs would like to get a poll about who out of the rmcat >>>> WG intends to travel to the IETF 98 meeting in Chicago. >>>> >>>> Please let us know until Feb 5th midnight by replying to this email. >>>> >>>> We would plan for an interim meeting shortly after the IETF 98 >>>> meeting in case that there is not a critical mass intending to >>>> attend a RMCAT session. >>>> >>>> Regards, >>>> >>>> Martin >>>> >>> >>> >> > > From nobody Wed Mar 15 02:18:11 2017 Return-Path: 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 32FD31299CB for ; Wed, 15 Mar 2017 02:18:10 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 naehee0JFiAi for ; Wed, 15 Mar 2017 02:18:08 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694551299D2 for ; Wed, 15 Mar 2017 02:18:08 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id u108so6613453wrb.3 for ; Wed, 15 Mar 2017 02:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=3XuBS7a0DBKNQU8gnmvj5sceOxvJ2RO9x6Pz2CtvYIg=; b=dzUKGYQMvxdjbWNpwYOSeO9dSkOT/YJ0qSRFCLJVsT8L3pCjNLab6B/GFvy5uAdrke vBRY6FVBnb0FNU8LDfxR5T5fOGtU1LKPVhklOM4FkxbxaY3vQc3mBHqRmyvkSI4D84Ip eAujg/tkTFHqy1+O/4R5wBAUfInL1WWK1GUAffusuSX3Eojkx1hmPBaVv1Pqgp778Fh3 3aZw86r8sSebKXMI9uY5jepwOggXWrV+P0340BztxvqOrN+BX5pX5d/mAFHIMJQOi5Vi x68Inmi06No2TUBxSlBb+rI42WtXU9bCrIizMqhLy3xvadDKlPe4/K/iVabX9DV0QEZC cx+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=3XuBS7a0DBKNQU8gnmvj5sceOxvJ2RO9x6Pz2CtvYIg=; b=GoCqYPCtQlJu7bC1a+Vh2cH2tPfkAX+Ajq8v46xq0dLDpf+IpMn4FgZe0oY70Y9zwo cSDnhrmcXSeyc5z3bteBnT0ruCExRcY8i2odiaypZYK6XLPqLL5Xq+6Yq5pOQyZjWK/D wPuChbiOrm5MgZZgKc8tmxotsEwZFHJh/y9sQ1sV5PqSY9YZh32M19V7+RBbxNii5zRm 6FbchAIlI9N+O/rZADD8StmCJBrZH99WzGVOK8mCqCpIHKo7niIBinCzPgiEbmGdj69x rtD7ZdGudpcviWlabjTbAD3SaAr4c8fTltlp4HUUn/A2ObRw6UZo5MG4tICywwXp7VWz u2nw== X-Gm-Message-State: AFeK/H2L27D7oGwNRXRpEp5U0BeIBtGGiZZ174G1IwLm1XwGqCL+OgOHOKAYKKBhSR2fzQ== X-Received: by 10.223.168.80 with SMTP id l74mr2016276wrc.184.1489569486599; Wed, 15 Mar 2017 02:18:06 -0700 (PDT) Received: from mn-mn0F-2.local (p2003000611009C24D04827ED0727B076.dip0.t-ipconnect.de. [2003:6:1100:9c24:d048:27ed:727:b076]) by smtp.googlemail.com with ESMTPSA id m201sm2999712wmd.19.2017.03.15.02.18.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 02:18:05 -0700 (PDT) From: Martin Stiemerling To: "rmcat WG (rmcat@ietf.org)" Message-ID: <6adc065d-49a6-37f3-4dea-407d2a81b6d1@gmail.com> Date: Wed, 15 Mar 2017 10:18:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 09:18:10 -0000 Dear all, Please find here the document shepherd review of Summary: Draft is not ready for submitting it to the AD, as it has a few items to be checked first which are formal issues and but no technical flaws! Issues: 1) ID nits has a number of issues, noteable these: a) The copyright year in the IETF Trust and authors Copyright Line does not match the current year b) The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. c) Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. a) is easily fixable, when recompiling the draft b) This is a bigger issue: The draft specifies a number of protocol behaviors, but is never using any of the RFC 2119 keywords. While not using the RFC 2119 keywords is acceptable for an experimental draft it is troublesome on the long run. The intention is for sure to move this draft to standards track, once the experimental phase is over. However, at this later stage RFC 2119 key words will be required. c) a bit of work, but easily fixable. Other comments beyond idnits: - Section 4.1.1.1: It says that the constantns are deduced from experiments. In what context have these experiments been specified, carried out and documented? Is this something you can refer you? The current text is a bit underspecified in that respect. - Section 4.1.1.1, page 10, bottom: " TARGET_BITRATE_MIN Min target bitrate [bps]. TARGET_BITRATE_MAX Max target bitrate [bps]. " I assume that the notion [bps] shall introduce the unit of this constant. Please specify that this is the notion you are using for specifying the unit. - Section 9. IANA Considerations: This is not section for IANA but more a question for the WG. Please remove the text from this section and place it in a new section "Open Issues" or similar. There is currently no request to IANA. Please state just this and the request to remove the section before publication as RFC. - Appendix A.4 looks like a regular section, with the note that this is an experimental version and needs further vetting during the experimentation period, isn't it? Thanks, Martin From nobody Thu Mar 16 07:37:15 2017 Return-Path: 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 20B70129492; Thu, 16 Mar 2017 07:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 pvQH9ghX0tvJ; Thu, 16 Mar 2017 07:37:12 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 825201294E7; Thu, 16 Mar 2017 07:37:11 -0700 (PDT) X-AuditID: c1b4fb2d-2dacd98000006193-e1-58caa315be9b Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 81.A3.24979.513AAC85; Thu, 16 Mar 2017 15:37:09 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 16 Mar 2017 15:36:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xPxZoJcru5dGCv581hEHzDZBWfzt1BN0rx+F736fxtc=; b=P2vbiyS8y/VkS5TW1X5Jsxtc0FlDGQO5sOIE6UKbiXrjWqSBGR80MEQK2sdl9RHLwTHwp232tfqeIxE6tNbM8U2yyHo1/6Y+PibJNE4nfCBVyXs86XtNalX9poDpTGbKzZTIZo918OMtgO6exbIFYpFZCe0MqV876aZ2d5aF8AI= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Thu, 16 Mar 2017 14:36:48 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0977.010; Thu, 16 Mar 2017 14:36:48 +0000 From: Ingemar Johansson S To: Martin Stiemerling , "rmcat WG (rmcat@ietf.org)" CC: "draft-ietf-rmcat-scream-cc@ietf.org" Thread-Topic: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07 Thread-Index: AQHSnb6kEkS9FXFVJ0KWeoLH6agMq6GXhPTA Date: Thu, 16 Mar 2017 14:36:48 +0000 Message-ID: References: <6adc065d-49a6-37f3-4dea-407d2a81b6d1@gmail.com> In-Reply-To: <6adc065d-49a6-37f3-4dea-407d2a81b6d1@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.85] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:q9PQicp2hfR3kITQs8pbN/uHwcW3HBPbfuyjdHQFzkDOUUl3DtmJppeT5Fsj42+SZ2OV5yHuBnFUq/0FsS4pd+J6rEssWq2c+hkIkkepg+Jtkx3GvFSziPu0+wb8eu8PKPg+RSAJolGHo292mDzopVCjkLG3wap1WIwVYLTG+WMMwgM3WeREvZ4Ee/DQXCpPm63WEZsAFU1z//kCHIsDVSZKu47SRkpfzGKoW+PyA+bKIHI0XML5MbIVlJgWFTjNYFiQJgRk4LnaZxIE4U3MjzR8wYJViiFQPfrIBhemSlaEqRHsiwQvhTE/D5ZcLITFBfda6M5nb2JfSLTs0+tsgw== x-ms-office365-filtering-correlation-id: 25082a27-773c-4969-824e-08d46c79e0e9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254033); SRVR:DB4PR07MB345; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(13464003)(51914003)(86362001)(230783001)(7696004)(77096006)(305945005)(2950100002)(102836003)(6116002)(229853002)(2906002)(66066001)(74316002)(81166006)(4326008)(53546007)(53936002)(8676002)(39060400002)(6246003)(38730400002)(8936002)(3846002)(3280700002)(33656002)(2900100001)(25786008)(6506006)(54356999)(50986999)(99286003)(7736002)(9686003)(6306002)(55016002)(189998001)(3660700001)(6436002)(76176999)(5660300001)(122556002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 14:36:48.4093 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42KZGbHdQFd08akIg7bLZhZrPptZTHo6jcli 9c0PbA7MHjtn3WX3WLLkJ1MAUxSXTUpqTmZZapG+XQJXxuLjzSwFn7QqNs20bWB8otnFyMkh IWAi0X5mHksXIxeHkMA6Ron+1d2MEM4JRonLk9qZQapYBHqZJdaet4RITGWS2HbrKRuEc4xR 4vrmA6wgVWwCNhIrD31nBLFFBKIlHv3cBRZnFgiUuPN7E9gkYQFXiQ8vNjBD1LhJrJp1jQ3C NpJ4v+MZG8Q2VYkjR/Yzgdi8AlES+49cBasXApo/o2UuWJxTwFbi2Yn/YPWMArIS97/fY4HY JS5x68l8JojfBCSW7DnPDGGLSrx8/I8V5GhGgV5GifN974AcDqCEgsTDrX4gcQmBbmaJV1O3 QTX7SrQcgzhOAuiZB2t7oOxMib3ft7BD2FoSHUdmMUE0z2CSOLV/FStEQkbi6MY1LBCJfywS PQf6WCDel5K4e6WTEcKWkXhxZy/rBEbNWUgunwV0FLOApsT6XfoQYUWJKd0P2WeBA0NQ4uTM JywLGFlWMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgSmj4NbfuvuYFz92vEQowAHoxIP74ew kxFCrIllxZW5hxglOJiVRHgPhgKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKa nZpakFoEk2Xi4JRqYJyw+myu2p3jFtI8h3s10ismSWQoBQl92lxu7hGgJGnAMOGh5oS61Yv4 rJezHdx/6U78Os+L507f4D5aMPdEi19Kgde8S1X8OxXqSg7bWL7ha9He43VMruzG7yWTmlOO 7/ofdr3xo8ept/vc272UWJd2XxP2unp0bafuuoD7/o0Hfp4Od+TOPaLEUpyRaKjFXFScCADJ kmqVGwMAAA== Archived-At: Subject: Re: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:37:14 -0000 SGkNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LCBjb21tZW50cyBpbmxpbmUuDQoNCi9JbmdlbWFy DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFydGluIFN0aWVtZXJs aW5nIFttYWlsdG86bWxzLmlldGZAZ21haWwuY29tXQ0KPiBTZW50OiBkZW4gMTUgbWFycyAyMDE3 IDEwOjE4DQo+IFRvOiBybWNhdCBXRyAocm1jYXRAaWV0Zi5vcmcpIDxybWNhdEBpZXRmLm9yZz4N Cj4gU3ViamVjdDogW3JtY2F0XSBTaGVwaGVyZCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ybWNhdC1z Y3JlYW0tY2MtMDcNCj4gDQo+IERlYXIgYWxsLA0KPiANCj4gUGxlYXNlIGZpbmQgaGVyZSB0aGUg ZG9jdW1lbnQgc2hlcGhlcmQgcmV2aWV3IG9mDQo+IA0KPiBTdW1tYXJ5Og0KPiBEcmFmdCBpcyBu b3QgcmVhZHkgZm9yIHN1Ym1pdHRpbmcgaXQgdG8gdGhlIEFELCBhcyBpdCBoYXMgYSBmZXcgaXRl bXMgdG8gYmUNCj4gY2hlY2tlZCBmaXJzdCB3aGljaCBhcmUgZm9ybWFsIGlzc3VlcyBhbmQgYnV0 IG5vIHRlY2huaWNhbCBmbGF3cyENCj4gDQo+IElzc3VlczoNCj4gMSkgSUQgbml0cyBoYXMgYSBu dW1iZXIgb2YgaXNzdWVzLCBub3RlYWJsZSB0aGVzZToNCj4gDQo+IGEpIFRoZSBjb3B5cmlnaHQg eWVhciBpbiB0aGUgSUVURiBUcnVzdCBhbmQgYXV0aG9ycyBDb3B5cmlnaHQgTGluZSBkb2VzIG5v dA0KPiBtYXRjaCB0aGUgY3VycmVudCB5ZWFyDQo+IGIpIFRoZSBkb2N1bWVudCBkb2Vzbid0IHVz ZSBhbnkgUkZDIDIxMTkga2V5d29yZHMsIHlldCBoYXMgdGV4dA0KPiByZXNlbWJsaW5nIFJGQyAy MTE5IGJvaWxlcnBsYXRlIHRleHQuDQo+IGMpIEZvdW5kIHNvbWV0aGluZyB3aGljaCBsb29rcyBs aWtlIGEgY29kZSBjb21tZW50IC0tIGlmIHlvdSBoYXZlIGNvZGUNCj4gc2VjdGlvbnMgaW4gdGhl IGRvY3VtZW50LCBwbGVhc2Ugc3Vycm91bmQgdGhlbSB3aXRoICc8Q09ERSBCRUdJTlM+JyBhbmQN Cj4gJzxDT0RFIEVORFM+JyBsaW5lcy4NCj4gDQo+IGEpIGlzIGVhc2lseSBmaXhhYmxlLCB3aGVu IHJlY29tcGlsaW5nIHRoZSBkcmFmdA0KW0lKXSBPSw0KDQo+IA0KPiBiKSBUaGlzIGlzIGEgYmln Z2VyIGlzc3VlOg0KPiBUaGUgZHJhZnQgc3BlY2lmaWVzIGEgbnVtYmVyIG9mIHByb3RvY29sIGJl aGF2aW9ycywgYnV0IGlzIG5ldmVyIHVzaW5nIGFueSBvZg0KPiB0aGUgUkZDIDIxMTkga2V5d29y ZHMuIFdoaWxlIG5vdCB1c2luZyB0aGUgUkZDIDIxMTkga2V5d29yZHMgaXMgYWNjZXB0YWJsZQ0K PiBmb3IgYW4gZXhwZXJpbWVudGFsIGRyYWZ0IGl0IGlzIHRyb3VibGVzb21lIG9uIHRoZSBsb25n IHJ1bi4NCj4gVGhlIGludGVudGlvbiBpcyBmb3Igc3VyZSB0byBtb3ZlIHRoaXMgZHJhZnQgdG8g c3RhbmRhcmRzIHRyYWNrLCBvbmNlIHRoZQ0KPiBleHBlcmltZW50YWwgcGhhc2UgaXMgb3Zlci4g SG93ZXZlciwgYXQgdGhpcyBsYXRlciBzdGFnZSBSRkMgMjExOSBrZXkgd29yZHMNCj4gd2lsbCBi ZSByZXF1aXJlZC4NCltJSl0gT0ssIHllcy4gVGhpcyBjYW4gdGFrZSBhIGZldyBob3VycyB0byBm aXgsIHNob3VsZCBub3QgYmUgdG9vIHRyb3VibGVzb21lLCBJIGhvcGUuIEkgaGFkIHdvcnNlIGlz c3VlcyB3aXRoIHJmYzYyMzYgYXMgdGhlIFJGQzIxMTkga2V5d29yZHMgaGFkIHRvIGJlIGNob3Nl biBjYXJlZnVsbHkgaW4gbGlnaHQgb2YgZXhpc3RpbmcgU0RQIGFuZCBTSVAgc3BlY3MuIFRoaXMg b25lIHNob3VsZCBiZSBtb3JlIHNpbXBsZSwgSSBob3BlLg0KDQo+IA0KPiBjKSBhIGJpdCBvZiB3 b3JrLCBidXQgZWFzaWx5IGZpeGFibGUuDQpbSUpdIE9LDQoNCj4gDQo+IE90aGVyIGNvbW1lbnRz IGJleW9uZCBpZG5pdHM6DQo+IA0KPiAtIFNlY3Rpb24gNC4xLjEuMTogSXQgc2F5cyB0aGF0IHRo ZSBjb25zdGFudG5zIGFyZSBkZWR1Y2VkIGZyb20gZXhwZXJpbWVudHMuDQo+IEluIHdoYXQgY29u dGV4dCBoYXZlIHRoZXNlIGV4cGVyaW1lbnRzIGJlZW4gc3BlY2lmaWVkLCBjYXJyaWVkIG91dCBh bmQNCj4gZG9jdW1lbnRlZD8gSXMgdGhpcyBzb21ldGhpbmcgeW91IGNhbiByZWZlciB5b3U/IFRo ZSBjdXJyZW50IHRleHQgaXMgYSBiaXQNCj4gdW5kZXJzcGVjaWZpZWQgaW4gdGhhdCByZXNwZWN0 Lg0KW0lKXSBUaGVyZSBhcmUgZXhwZXJpbWVudHMgcmVzdWx0cyBwcmVzZW50ZWQgYXQgdGhlIFJN Q0FUIG1lZXRpbmdzLCBsYXN0IHRpbWUgd2FzICBpbiBCZXJsaW4gKGh0dHBzOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtcm1jYXQtMC5wZGYgKSwgSXQgaXMg cG9zc2libGUgdGhhdCBJIGNhbiBwcmVzZW50IG5ldyByZXN1bHRzIHNvb24uIFF1ZXN0aW9uIGlz IGluIHdoaWNoIGZvcm0gc2hvdWxkIHRoZSByZXN1bHRzIGJlIHByZXNlbnRlZCA/LiBJcyBtYXRl cmlhbCBwcmVzZW50ZWQgYXQgUk1DQVQgc3VmZmljaWVudC4NCg0KPiANCj4gLSBTZWN0aW9uIDQu MS4xLjEsIHBhZ2UgMTAsIGJvdHRvbToNCj4gIiBUQVJHRVRfQklUUkFURV9NSU4NCj4gICAgICAg TWluIHRhcmdldCBiaXRyYXRlIFticHNdLg0KPiANCj4gICAgIFRBUkdFVF9CSVRSQVRFX01BWA0K PiAgICAgICBNYXggdGFyZ2V0IGJpdHJhdGUgW2Jwc10uDQo+ICINCj4gDQo+IEkgYXNzdW1lIHRo YXQgdGhlIG5vdGlvbiBbYnBzXSBzaGFsbCBpbnRyb2R1Y2UgdGhlIHVuaXQgb2YgdGhpcyBjb25z dGFudC4NCj4gUGxlYXNlIHNwZWNpZnkgdGhhdCB0aGlzIGlzIHRoZSBub3Rpb24geW91IGFyZSB1 c2luZyBmb3Igc3BlY2lmeWluZyB0aGUgdW5pdC4NCltJSl0gSWYgSSB1bmRlcnN0YW5kIGl0IGNv cnJlY3QgeW91IG1lYW4gdGhhdCBJIHNob3VsZCBzcGVjaWZ5IHRoYXQgW2Jwc10gaW5kaWNhdGUg dGhlIHVuaXQgImJpdHMgcGVyIHNlY29uZCIsIHJpZ2h0ID8NCg0KPiANCj4gDQo+IC0gU2VjdGlv biA5LiBJQU5BIENvbnNpZGVyYXRpb25zOg0KPiBUaGlzIGlzIG5vdCBzZWN0aW9uIGZvciBJQU5B IGJ1dCBtb3JlIGEgcXVlc3Rpb24gZm9yIHRoZSBXRy4gUGxlYXNlIHJlbW92ZQ0KPiB0aGUgdGV4 dCBmcm9tIHRoaXMgc2VjdGlvbiBhbmQgcGxhY2UgaXQgaW4gYSBuZXcgc2VjdGlvbiAiT3BlbiBJ c3N1ZXMiIG9yDQo+IHNpbWlsYXIuIFRoZXJlIGlzIGN1cnJlbnRseSBubyByZXF1ZXN0IHRvIElB TkEuIFBsZWFzZSBzdGF0ZSBqdXN0IHRoaXMgYW5kIHRoZQ0KPiByZXF1ZXN0IHRvIHJlbW92ZSB0 aGUgc2VjdGlvbiBiZWZvcmUgcHVibGljYXRpb24gYXMgUkZDLg0KW0lKXSBPSw0KDQo+IA0KPiAt IEFwcGVuZGl4IEEuNCBsb29rcyBsaWtlIGEgcmVndWxhciBzZWN0aW9uLCB3aXRoIHRoZSBub3Rl IHRoYXQgdGhpcyBpcyBhbg0KPiBleHBlcmltZW50YWwgdmVyc2lvbiBhbmQgbmVlZHMgZnVydGhl ciB2ZXR0aW5nIGR1cmluZyB0aGUgZXhwZXJpbWVudGF0aW9uDQo+IHBlcmlvZCwgaXNuJ3QgaXQ/ DQpbSUpdIFllcy4gVGhlIHByb3Bvc2VkIGZlZWRiYWNrIHdoaWxlIHdhaXRpbmcgZm9yIHNvbWUg a2luZCBvZiBnZW5lcmljIGZlZWRiYWNrLCB0aGlzIGlzIHRoZSBiZXN0IG9uZSBjYW4gZG8gd2l0 aCBleGlzdGluZyBzdGFuZGFyZGl6ZWQgZmVlZGJhY2suIFRoZSBmZWVkYmFjayBpbnRlbnNpdHkg aXMgdmVyaWZpZWQgaW4gc2ltdWxhdG9yIG92ZXIgYSBsYXJnZSByYW5nZSBvZiBiaXRyYXRlcywg YW5kIGFsc28gdmVyaWZpZWQgaW4gYW4gZXhwZXJpbWVudGFsIHRlc3RiZWQgZm9yIGEgaGlnaCBx dWFsaXR5IHZpZGVvIHNvbHV0aW9uIG92ZXIgTFRFLzVHLiBUaGUgb2JqZWN0aXZlIGhhcyBiZWVu IHRvIGVuc3VyZSBhIGZlZWRiYWNrIHJhdGUgdGhhdCBpcyBub3Qgb3Zlcmx5IGhpZ2ggYW5kIHRo YXQgYXQgdGhlIHNhbWUgdGltZSBkb2VzIG5vdCBsaW1pdCB0aHJvdWdocHV0LiBJdCBpcyBub3Qg cnVsZWQgb3V0IHRoYXQgdGhlIGVxdWF0aW9ucyBpbiBzZWN0aW9uIEEuNC4yIG1heSBjaGFuZ2Ug ZHVyaW5nIHRoZSBleHBlcmltZW50YXRpb24gcGVyaW9kLg0KDQo+IA0KPiBUaGFua3MsDQo+IA0K PiAgICBNYXJ0aW4NCj4gDQoNCg== From nobody Wed Mar 22 10:39:32 2017 Return-Path: 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 677171294B1 for ; Wed, 22 Mar 2017 10:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 kYCYYeMIKjXs for ; Wed, 22 Mar 2017 10:39:27 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5989C1294E5 for ; Wed, 22 Mar 2017 10:39:27 -0700 (PDT) Received: from [130.209.247.112] (port=62087 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cqkEF-00009V-Fm; Wed, 22 Mar 2017 17:39:24 +0000 From: Colin Perkins Message-Id: <43BFB16D-4D42-420F-AE4E-FAEC71E2339B@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_2697BEA4-AC15-498F-A3D2-14A142C30876" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 22 Mar 2017 17:39:17 +0000 In-Reply-To: <3D88BE15-2E05-490A-A5BB-98993D892A52@csperkins.org> Cc: "rmcat@ietf.org" , David Hayes To: Anna Brunstrom References: <01258ecf-6a8a-1e8f-20f9-8d105ccb889e@kau.se> <3D88BE15-2E05-490A-A5BB-98993D892A52@csperkins.org> X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [rmcat] RMCAT WGLC: draft-ietf-rmcat-sbd-05 - ends Dec 4 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 17:39:30 -0000 --Apple-Mail=_2697BEA4-AC15-498F-A3D2-14A142C30876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, (Posting as an individual participant, not as WG co-chair) I reviewed the changes in version -06 of this draft. Comments below. > On 6 Dec 2016, at 18:35, Colin Perkins wrote: >=20 >> On 13 Nov 2016, at 15:06, Anna Brunstrom > wrote: >> This email announces a RMCAT Working Group Last Call (WGLC) on: >>=20 >> Shared Bottleneck Detection for Coupled Congestion Control for RTP = Media >> draft-ietf-rmcat-sbd-05 = >> Due to the IETF week, this WGLC will run for 3 weeks, ending at = midnight US Eastern Time on Sunday, December 4. Comments should = preferably be sent to the rmcat@ietf.org list, = although purely editorial comments may be sent directly to the authors = at draft-ietf-rmcat-sbd@ietf.org = - if doing so, please cc: the WG chairs at rmcat-chairs@tools.ietf.org = . >>=20 >> We are looking for at least a couple of reviews during WGLC, so = please help review the document.=20 >=20 >=20 > (Posting as an individual participant, not as WG co-chair) >=20 > I=E2=80=99ve reviewed this draft. In general, I think it=E2=80=99s in = very good shape, and suitable for publication as an experimental RFC. I = do, however, have some comments: >=20 > - If I understand correctly, the draft replies on feedback sent every = T seconds, where T=3D350ms by default. Such feedback is, presumably, to = be sent by RTCP, since that is the standard back-channel for RTP flows. = The RTCP reporting interval depends on the allocated RTCP bandwidth, the = number of participants, and the size of the RTCP packets, and can vary = between tens of milliseconds and tens of seconds. It=E2=80=99s unlikely = to be exactly 350ms, although values of that order are not unreasonable. = To what extent does the proposed mechanism depend on the precise timing = of the feedback, and what are the acceptable upper- and lower-bounds on = the feedback interval if the mechanism is to work? It would be useful if = the draft could include some discussion of this, to aid both = implementors and those looking to design congestion control and feedback = mechanisms.=20 A note has been added in -06 saying: Note that the mechanism bases its calculations on the interval T. = It=09 does not require T to be the feedback interval, only that=09 calculations can be performed over measurements made in that=09 interval. I don=E2=80=99t think this is sufficient. How are the measurements made? = The draft suggests using draft-ietf-rmcat-feedback-message but that = doesn=E2=80=99t provide measurements over the same timescale. It might = be reasonable to use this, or some other XR block, with aggregation = across multiple reports, but the draft should explain =E2=80=93 or at = least, outline =E2=80=93 what aggregation needs to be done, and how. > - Section 3.3.1 has a sequence of steps that start =E2=80=9Cgroup = flows whose=E2=80=A6=E2=80=9D. I find this a little hard to follow, in = particular it=E2=80=99s not clear what flows are left ungrouped after = each stage. Would changing these steps to start =E2=80=9C=46rom the = remaining set of ungrouped flows, group those flows whose=E2=80=A6=E2=80=9D= reflect the intent and be clearer?=20 The revised text is still not clear. It says, for example, =E2=80=9CSubdiv= ide freq_est groups=E2=80=9D, but doesn=E2=80=99t say what a =E2=80=9Cfreq= _est group=E2=80=9D is. Similarly for the other steps. If the goal is = that step 3 sub-divides the groups identified in step 2, for example, = then say that. > - Are the mechanisms in sections 3.4 and 3.5 required to be = implemented, or are the optional? Some normative language might help to = make it clearer what an implementation should do with these. It=E2=80=99s = not clear if they=E2=80=99re essential parts of the algorithm, or = enhancements for some situations. >=20 > - In general, for a protocol specification, I think the draft would = benefit from a more prescriptive (=E2=80=9Cwhen this happens, do = this=E2=80=9D) style of writing. I don=E2=80=99t think that=E2=80=99s a = blocker for Experimental, but something to consider if it=E2=80=99s = later revised for standards track. >=20 > - Section 4.1, 2nd paragraph: I assume the suggestion is that each = flow should use its media clock? Do any issues that arise when trying to = group flows that use RTP different clock rates (e.g., the case where the = audio flow has an 8kHz clock and the video flow has a 90kHz clock)? Perhaps I missed it, but this doesn=E2=80=99t appear to have been = addressed. > - The draft says little about how feedback is to be conveyed. Is the = expectation that the information can be extracted from the standard RTCP = reception reports, or maybe XR blocks? It would be helpful if the draft = could either point to existing feedback mechanisms that are suitable, or = state that RTCP extensions will be needed.=20 >=20 Thanks, Colin --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_2697BEA4-AC15-498F-A3D2-14A142C30876 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

(Posting as an individual participant, not as WG = co-chair)

I reviewed the changes in version -06 = of this draft. Comments below.

On = 6 Dec 2016, at 18:35, Colin Perkins <csp@csperkins.org> = wrote:

On 13 = Nov 2016, at 15:06, Anna Brunstrom <anna.brunstrom@kau.se> wrote:

This email announces a RMCAT Working Group Last Call (WGLC) on:

Shared Bottleneck = Detection for Coupled Congestion Control for RTP Media
draft-ietf-rmcat-sbd-05

Due to the IETF week, this WGLC = will run for 3 weeks, ending at midnight US Eastern Time on Sunday, December 4.  Comments should preferably be sent to the rmcat@ietf.org list, although purely editorial comments may be sent directly to the authors at draft-ietf-rmcat-sbd@ietf.org - = if doing so, please cc: the WG chairs at rmcat-chairs@tools.ietf.org.

We are looking for at least a couple of reviews = during WGLC, so please help review the document.


(Posting as an individual participant, = not as WG co-chair)

I=E2=80=99ve reviewed this draft. In general, I think it=E2=80=99s = in very good shape, and suitable for publication as an experimental RFC. = I do, however, have some comments:

- = If I understand correctly, the draft replies on feedback sent every T seconds, where T=3D350ms by default. = Such feedback is, presumably, to be sent by RTCP, since that is the = standard back-channel for RTP flows. The RTCP reporting interval depends = on the allocated RTCP bandwidth, the number of participants, and the = size of the RTCP packets, and can vary between tens of milliseconds and = tens of seconds. It=E2=80=99s unlikely to be exactly 350ms, = although values of that order are not unreasonable. To what extent does = the proposed mechanism depend on the precise timing of the feedback, and = what are the acceptable upper- and lower-bounds on the feedback interval = if the mechanism is to work? It would be useful if the draft could = include some discussion of this, to aid both implementors and those = looking to design congestion control and feedback = mechanisms. 

A note has been added in -06 saying:

    Note that the mechanism bases its = calculations on the interval T.  It
    does = not require T to be the feedback interval, only that
    calculations can be performed over measurements = made in that =
    interval.

I don=E2=80=99t think this is sufficient. How are = the measurements made? The draft suggests = using draft-ietf-rmcat-feedback-message but that doesn=E2=80=99t = provide measurements over the same timescale. It might be reasonable to = use this, or some other XR block, with aggregation across multiple = reports, but the draft should explain =E2=80=93 or at least, outline =E2=80= =93 what aggregation needs to be done, and how.

- Section 3.3.1 has a sequence of steps that start =E2=80=9Cgr= oup flows whose=E2=80=A6=E2=80=9D. I find this a little hard to = follow, in particular it=E2=80=99s not clear what flows are left = ungrouped after each stage. Would changing these steps to start =E2=80=9C=46= rom the remaining set of ungrouped flows, group those flows = whose=E2=80=A6=E2=80=9D reflect the intent and be clearer? 

The revised text is still not clear. It says, for = example, =E2=80=9CSubdivide freq_est groups=E2=80=9D, but doesn=E2=80=99t = say what a =E2=80=9Cfreq_est group=E2=80=9D is. Similarly for the other = steps. If the goal is that step 3 sub-divides the groups identified in = step 2, for example, then say that.

- Are the mechanisms in sections 3.4 and 3.5 required to be = implemented, or are the optional? Some normative language might help to = make it clearer what an implementation should do with these. It=E2=80= =99s not clear if they=E2=80=99re essential parts of the algorithm, = or enhancements for some situations.

- In general, for a protocol = specification, I think the draft would benefit from a more prescriptive = (=E2=80=9Cwhen this happens, do this=E2=80=9D) style of writing. I = don=E2=80=99t think that=E2=80=99s a blocker for Experimental, but = something to consider if it=E2=80=99s later revised for standards = track.

- Section 4.1, 2nd paragraph: I = assume the suggestion is that each flow should use its media clock? = Do any issues that arise when trying to group flows that use RTP = different clock rates (e.g., the case where the audio flow has an = 8kHz clock and the video flow has a 90kHz clock)?

Perhaps I missed it, but this doesn=E2=80=99t = appear to have been addressed.

- The draft says little about how feedback is to be = conveyed. Is the expectation that the information can be extracted = from the standard RTCP reception reports, or maybe XR blocks? It would = be helpful if the draft could either point to existing feedback = mechanisms that are suitable, or state that RTCP extensions will be = needed. 


Thanks,
Colin



-- Colin Perkins
https://csperkins.org/




= --Apple-Mail=_2697BEA4-AC15-498F-A3D2-14A142C30876-- From nobody Wed Mar 22 15:49:14 2017 Return-Path: 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 7380512896F; Wed, 22 Mar 2017 15:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 7RwXijwvCxzS; Wed, 22 Mar 2017 15:49:10 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C335A1273E2; Wed, 22 Mar 2017 15:49:10 -0700 (PDT) Received: from [81.187.2.149] (port=39991 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cqp40-0006d2-DQ; Wed, 22 Mar 2017 22:49:09 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Colin Perkins In-Reply-To: <66C087EE-823A-43C9-8E8B-A2364FD6511B@csperkins.org> Date: Wed, 22 Mar 2017 22:49:03 +0000 Cc: draft-ietf-rmcat-coupled-cc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <79DC47FB-2032-444C-9654-A0A87F93CC18@csperkins.org> References: <148111854325.13729.9946710085994858033.idtracker@ietfa.amsl.com> <66C087EE-823A-43C9-8E8B-A2364FD6511B@csperkins.org> To: "rmcat WG (rmcat@ietf.org)" X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:49:13 -0000 WG, There were no objections, so the chairs will prepare the write-up for = this draft to send to the IESG in order to request publication. Colin (as WG co-chair) > On 9 Dec 2016, at 23:26, Colin Perkins wrote: >=20 > WG, >=20 > The authors recently submitted draft-ietf-rmcat-coupled-cc-05. = Following the discussion in the working group session at IETF 97 in = Seoul, this moves the text on how to use coupled congestion control with = the Google congestion control (GCC) algorithm from the main text to an = appendix, and makes the reference to GCC informative. The rest of the = document is updated to use NADA as the example, rather than NADA and = GCC. These changes are intended to prevent the coupled congestion = control draft from blocking on a normative reference to GCC, since the = GCC draft is not yet finished. They are not intended to change the scope = of the work. >=20 > The authors have also taken the opportunity to add some minor = clarifications to the general recommendations, adding text on Stateful = algorithms and Rate Jumps, in what is now Section 6.2 of the draft. >=20 > This draft has completed working group last call. However, since there = was some discussion around these changes in the meeting, the chairs = would like to re-open the working group last call for an additional week = to ensure there are no objections. If you object to the changes in this = version of the draft, please comment to the list by 16 December 2016. If = there are no objections, the chairs will prepare the write-up to send = this to the IESG in early 2017. >=20 > Colin > (as WG co-chair) >=20 >=20 >=20 >=20 >=20 >> On 7 Dec 2016, at 13:49, Internet-Drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the RTP Media Congestion Avoidance = Techniques of the IETF. >>=20 >> Title : Coupled congestion control for RTP media >> Authors : Safiqul Islam >> Michael Welzl >> Stein Gjessing >> Filename : draft-ietf-rmcat-coupled-cc-05.txt >> Pages : 25 >> Date : 2016-12-07 >>=20 >> Abstract: >> When multiple congestion controlled RTP sessions traverse the same >> network bottleneck, combining their controls can improve the total >> on-the-wire behavior in terms of delay, loss and fairness. This >> document describes such a method for flows that have the same = sender, >> in a way that is as flexible and simple as possible while minimizing >> the amount of changes needed to existing RTP applications. It >> specifies how to apply the method for the NADA congestion control >> algorithm, and provides suggestions on how to apply it to other >> congestion control algorithms. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-rmcat-coupled-cc-05 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-coupled-cc-05 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >=20 > --=20 > Colin Perkins > https://csperkins.org/ From nobody Wed Mar 22 16:33:27 2017 Return-Path: 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 56A811270A7; Wed, 22 Mar 2017 16:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 A0UHxMLu6rzl; Wed, 22 Mar 2017 16:33:21 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FC9127201; Wed, 22 Mar 2017 16:33:21 -0700 (PDT) Received: from [81.187.2.149] (port=48490 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cqpkl-0002wi-Cp; Wed, 22 Mar 2017 23:33:20 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Colin Perkins In-Reply-To: <79DC47FB-2032-444C-9654-A0A87F93CC18@csperkins.org> Date: Wed, 22 Mar 2017 23:33:18 +0000 Cc: "rmcat WG (rmcat@ietf.org)" Content-Transfer-Encoding: quoted-printable Message-Id: <0A54D20B-45D0-41F6-AAAD-923A60F6C285@csperkins.org> References: <148111854325.13729.9946710085994858033.idtracker@ietfa.amsl.com> <66C087EE-823A-43C9-8E8B-A2364FD6511B@csperkins.org> <79DC47FB-2032-444C-9654-A0A87F93CC18@csperkins.org> To: draft-ietf-rmcat-coupled-cc@ietf.org X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:33:24 -0000 Authors, I=E2=80=99ve reviewed this draft while preparing the IESG write-up and = request for publication. I have a number of minor questions and = comments: - Section 2 defines a Flow and gives an example as =E2=80=9Can RTP = session, or a sub-session that is multiplexed onto a single RTP = session=E2=80=9D. I believe this example is incorrect, and what is = intended is =E2=80=9Can RTP Stream [RFC7656], or a group of RTP Streams = multiplexed onto a single RTP session=E2=80=9D (Section 2.1.10 of RFC = 7656 defines the term RTP Stream carefully, so I think a reference is = useful; it also defines the term RTP Session in Section 2.2.2). Can you = please check and update are necessary. - Section 3 discusses limitations of the proposed algorithms. Would it = be appropriate to add a brief applicability statement either here, or in = the Introduction, stating that the described mechanisms are believed = safe to use, but are experimental and are presented for wider review and = operational evaluation? - Section 5.1, bullet 1, notes that flows share a bottleneck if = they=E2=80=99re sent on the same 5-tuple and have the same DSCP value. = Should this also note that they need the same ECT mark? With the = proposed L4S ECN experiments, we=E2=80=99re likely to see quite = different behaviour between flows with NotECT/ECT(0) and those with = ECT(1) marking.=20 - Section 5.2 defines the priority in the range 0.1 to 1. Assuming 0.1 = is correct, it might be worth adding a brief note to explain this = choice, since readers might think it a typo for the more typical range = of 0 to 1.=20 - Section 5.2, in the paragraph following the bullet points, the draft = suggests mapping priority levels from RTCWEB using the values 1, 2, 4, = and 8 =E2=80=93 how do these relate to the 0.1 to 1 range? - Section 5.3 defines terminology and describes the two algorithms. The = terminology used is inconsistent, sometimes using FSE_R and sometimes = FSE_R(f). If the intent is that these are the same variable, the = terminology should be aligned (I assume to FSE_R(f) since they=E2=80=99re = per-flow values, but the important point is that it=E2=80=99s = consistent). If there=E2=80=99s intended to be a difference between the = overall and per-flow values, can you please check that they=E2=80=99re = used consistently, and add a sentence to clarify the meanings of the = terms.=20 - Section 5.3 also uses P and P(i) in a manner that suggests they=E2=80=99= re referring to the same parameter. Similarly for CC_R =E2=80=93 should = it be CC_R(i)? - Appendix C: similar terminology comments apply. - Appendix C: =E2=80=9Chighly experimental=E2=80=9D =E2=80=93 It might = be useful to add a brief applicability statement for implementors so = they know whether this is safe to deploy outside of testbed = environments. Thanks, Colin > On 22 Mar 2017, at 22:49, Colin Perkins wrote: >=20 > WG, >=20 > There were no objections, so the chairs will prepare the write-up for = this draft to send to the IESG in order to request publication. >=20 > Colin > (as WG co-chair) >=20 >=20 >=20 >> On 9 Dec 2016, at 23:26, Colin Perkins wrote: >>=20 >> WG, >>=20 >> The authors recently submitted draft-ietf-rmcat-coupled-cc-05. = Following the discussion in the working group session at IETF 97 in = Seoul, this moves the text on how to use coupled congestion control with = the Google congestion control (GCC) algorithm from the main text to an = appendix, and makes the reference to GCC informative. The rest of the = document is updated to use NADA as the example, rather than NADA and = GCC. These changes are intended to prevent the coupled congestion = control draft from blocking on a normative reference to GCC, since the = GCC draft is not yet finished. They are not intended to change the scope = of the work. >>=20 >> The authors have also taken the opportunity to add some minor = clarifications to the general recommendations, adding text on Stateful = algorithms and Rate Jumps, in what is now Section 6.2 of the draft. >>=20 >> This draft has completed working group last call. However, since = there was some discussion around these changes in the meeting, the = chairs would like to re-open the working group last call for an = additional week to ensure there are no objections. If you object to the = changes in this version of the draft, please comment to the list by 16 = December 2016. If there are no objections, the chairs will prepare the = write-up to send this to the IESG in early 2017. >>=20 >> Colin >> (as WG co-chair) >>=20 >>=20 >>=20 >>=20 >>=20 >>> On 7 Dec 2016, at 13:49, Internet-Drafts@ietf.org wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the RTP Media Congestion Avoidance = Techniques of the IETF. >>>=20 >>> Title : Coupled congestion control for RTP media >>> Authors : Safiqul Islam >>> Michael Welzl >>> Stein Gjessing >>> Filename : draft-ietf-rmcat-coupled-cc-05.txt >>> Pages : 25 >>> Date : 2016-12-07 >>>=20 >>> Abstract: >>> When multiple congestion controlled RTP sessions traverse the same >>> network bottleneck, combining their controls can improve the total >>> on-the-wire behavior in terms of delay, loss and fairness. This >>> document describes such a method for flows that have the same = sender, >>> in a way that is as flexible and simple as possible while minimizing >>> the amount of changes needed to existing RTP applications. It >>> specifies how to apply the method for the NADA congestion control >>> algorithm, and provides suggestions on how to apply it to other >>> congestion control algorithms. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ >>>=20 >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-rmcat-coupled-cc-05 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-coupled-cc-05 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ From nobody Thu Mar 23 06:47:36 2017 Return-Path: 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 5E70B129721 for ; Thu, 23 Mar 2017 06:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 GoYgjnBBABPv for ; Thu, 23 Mar 2017 06:47:28 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 171C2129704 for ; Thu, 23 Mar 2017 06:47:28 -0700 (PDT) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cr35J-0007qi-Mw; Thu, 23 Mar 2017 14:47:25 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx02.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cr35F-000GcV-W3; Thu, 23 Mar 2017 14:47:25 +0100 Content-Type: multipart/mixed; boundary="Apple-Mail=_87383AA4-BFA4-45C1-9A7D-AD3DE4914708" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <0A54D20B-45D0-41F6-AAAD-923A60F6C285@csperkins.org> Date: Thu, 23 Mar 2017 14:47:19 +0100 Cc: rmcat WG , draft-ietf-rmcat-coupled-cc@ietf.org Message-Id: <9DCBD472-DFFF-43CF-BBDC-6241BEA2C67A@ifi.uio.no> References: <148111854325.13729.9946710085994858033.idtracker@ietfa.amsl.com> <66C087EE-823A-43C9-8E8B-A2364FD6511B@csperkins.org> <79DC47FB-2032-444C-9654-A0A87F93CC18@csperkins.org> <0A54D20B-45D0-41F6-AAAD-923A60F6C285@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 3 total rcpts 53106 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.011, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9B6999B90224AAEE1BB7CB8A7B603C765CD0EE8A X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 12780 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 13:47:34 -0000 --Apple-Mail=_87383AA4-BFA4-45C1-9A7D-AD3DE4914708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Colin, Thanks a lot, this was very helpful ! We incorporated your comments = and attach the updated draft to this email, as right now submission is = closed. Some answers in line: > On 23 Mar 2017, at 00:33, Colin Perkins wrote: >=20 > Authors, >=20 > I=E2=80=99ve reviewed this draft while preparing the IESG write-up and = request for publication. I have a number of minor questions and = comments: >=20 > - Section 2 defines a Flow and gives an example as =E2=80=9Can RTP = session, or a sub-session that is multiplexed onto a single RTP = session=E2=80=9D. I believe this example is incorrect, and what is = intended is =E2=80=9Can RTP Stream [RFC7656], or a group of RTP Streams = multiplexed onto a single RTP session=E2=80=9D (Section 2.1.10 of RFC = 7656 defines the term RTP Stream carefully, so I think a reference is = useful; it also defines the term RTP Session in Section 2.2.2). Can you = please check and update are necessary. Thanks a lot - of course you're right! We changed the definition of a = flow as follows: "A flow is the entity that congestion control is operating on. It could, = for example, be a transport layer connection, or an RTP stream , whether or not this RTP stream is multiplexed onto = an RTP session with other RTP streams." > - Section 3 discusses limitations of the proposed algorithms. Would it = be appropriate to add a brief applicability statement either here, or in = the Introduction, stating that the described mechanisms are believed = safe to use, but are experimental and are presented for wider review and = operational evaluation? OK, done, at the end of the introduction. > - Section 5.1, bullet 1, notes that flows share a bottleneck if = they=E2=80=99re sent on the same 5-tuple and have the same DSCP value. = Should this also note that they need the same ECT mark? With the = proposed L4S ECN experiments, we=E2=80=99re likely to see quite = different behaviour between flows with NotECT/ECT(0) and those with = ECT(1) marking.=20 Good catch! Done > - Section 5.2 defines the priority in the range 0.1 to 1. Assuming 0.1 = is correct, it might be worth adding a brief note to explain this = choice, since readers might think it a typo for the more typical range = of 0 to 1.=20 >=20 > - Section 5.2, in the paragraph following the bullet points, the draft = suggests mapping priority levels from RTCWEB using the values 1, 2, 4, = and 8 =E2=80=93 how do these relate to the 0.1 to 1 range? Another good catch! The value range really doesn't matter for our = algorithm, but 0 is not allowed (it might lead to a division by 0). To clarify all of this, we have removed the "0.1 to 1" example in the = priority definition, and changed the text talking about 1, 2, 4 and 8 = levels to the following: *** Note that the absolute range of priorities does not matter: the algorithm works with a flow's priority portion of the sum of all priority values. For example, if there are two flows, flow 1 with priority 1 and flow 2 with priority 2, the sum of the priorities is 3. Then, flow 1 will be assigned 1/3 of the aggregate sending rate and flow 2 will be assigned 2/3 of the aggregate sending rate. Priorities can be mapped to the "very-low", "low", "medium" or "high" priority levels described in [I-D.ietf-rtcweb-transports] by simply using the values 1, 2, 4 and 8, respectively. *** > - Section 5.3 defines terminology and describes the two algorithms. = The terminology used is inconsistent, sometimes using FSE_R and = sometimes FSE_R(f). If the intent is that these are the same variable, = the terminology should be aligned (I assume to FSE_R(f) since they=E2=80=99= re per-flow values, but the important point is that it=E2=80=99s = consistent). If there=E2=80=99s intended to be a difference between the = overall and per-flow values, can you please check that they=E2=80=99re = used consistently, and add a sentence to clarify the meanings of the = terms.=20 >=20 > - Section 5.3 also uses P and P(i) in a manner that suggests they=E2=80=99= re referring to the same parameter. Similarly for CC_R =E2=80=93 should = it be CC_R(i)? Fixed everywhere. > - Appendix C: similar terminology comments apply. Fixed everywhere (here it also applies to the variables DR, new_DR and = Rate). > - Appendix C: =E2=80=9Chighly experimental=E2=80=9D =E2=80=93 It might = be useful to add a brief applicability statement for implementors so = they know whether this is safe to deploy outside of testbed = environments. done (we added "and not safe to deploy outside of testbed environments" = after "highly experimental"). Cheers, Michael --Apple-Mail=_87383AA4-BFA4-45C1-9A7D-AD3DE4914708 Content-Disposition: attachment; filename=draft-ietf-rmcat-coupled-cc-06.txt Content-Type: text/plain; name="draft-ietf-rmcat-coupled-cc-06.txt" Content-Transfer-Encoding: quoted-printable RTP Media Congestion Avoidance Techniques (rmcat) S. Islam Internet-Draft M. Welzl Intended status: Experimental S. Gjessing Expires: September 24, 2017 University of Oslo March 23, 2017 Coupled congestion control for RTP media draft-ietf-rmcat-coupled-cc-06 Abstract When multiple congestion controlled RTP sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. It specifies how to apply the method for the NADA congestion control algorithm, and provides suggestions on how to apply it to other congestion control algorithms. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 24, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Islam, et al. Expires September 24, 2017 [Page 1] =0C Internet-Draft Coupled congestion control for RTP media March 2017 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architectural overview . . . . . . . . . . . . . . . . . . . 5 5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . 9 5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 10 6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. General recommendations . . . . . . . . . . . . . . . . . 11 7. Expected feedback from experiments . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Application to GCC . . . . . . . . . . . . . . . . . 15 Appendix B. Scheduling . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Example algorithm - Passive FSE . . . . . . . . . . 16 C.1. Example operation (passive) . . . . . . . . . . . . . . . 19 Appendix D. Change log . . . . . . . . . . . . . . . . . . . . . 23 D.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . 23 D.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 23 D.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 23 D.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 23 D.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 24 D.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 24 D.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 24 D.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . 24 D.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 24 D.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 24 D.2.4. Changes from -02 to -03 . . . . . . . . . . . . . . . 24 D.2.5. Changes from -03 to -04 . . . . . . . . . . . . . . . 24 D.2.6. Changes from -04 to -05 . . . . . . . . . . . . . . . 25 D.2.7. Changes from -05 to -06 . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Islam, et al. Expires September 24, 2017 [Page 2] =0C Internet-Draft Coupled congestion control for RTP media March 2017 1. Introduction When there is enough data to send, a congestion controller must increase its sending rate until the path's capacity has been reached; depending on the controller, sometimes the rate is increased further, until packets are ECN-marked or dropped. This process inevitably creates undesirable queuing delay when multiple congestion controlled connections traverse the same network bottleneck. The Congestion Manager (CM) [RFC3124] couples flows by providing a single congestion controller. It is hard to implement because it requires an additional congestion controller and removes all per- connection congestion control functionality, which is quite a significant change to existing RTP based applications. This document presents a method to combine the behavior of congestion control mechanisms that is easier to implement than the Congestion Manager [RFC3124] and also requires less significant changes to existing RTP based applications. It attempts to roughly approximate the CM behavior by sharing information between existing congestion controllers. It is able to honor user-specified priorities, which is required by rtcweb [RFC7478]. The described mechanisms are believed safe to use, but are experimental and are presented for wider review and operational evaluation. 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Available Bandwidth: The available bandwidth is the nominal link capacity minus the amount of traffic that traversed the link during a certain time interval, divided by that time interval. Bottleneck: The first link with the smallest available bandwidth along the path between a sender and receiver. Flow: A flow is the entity that congestion control is operating on. It could, for example, be a transport layer connection, an RTP stream [RFC7656], whether or not this RTP stream is multiplexed onto an RTP session with other RTP streams. Flow Group Identifier (FGI): Islam, et al. Expires September 24, 2017 [Page 3] =0C Internet-Draft Coupled congestion control for RTP media March 2017 A unique identifier for each subset of flows that is limited by a common bottleneck. Flow State Exchange (FSE): The entity that maintains information that is exchanged between flows. Flow Group (FG): A group of flows having the same FGI. Shared Bottleneck Detection (SBD): The entity that determines which flows traverse the same bottleneck in the network, or the process of doing so. 3. Limitations Sender-side only: Coupled congestion control as described here only operates inside a single host on the sender side. This is because, irrespective of where the major decisions for congestion control are taken, the sender of a flow needs to eventually decide on the transmission rate. Additionally, the necessary information about how much data an application can currently send on a flow is often only available at the sender side, making the sender an obvious choice for placement of the elements and mechanisms described here. Shared bottlenecks do not change quickly: As per the definition above, a bottleneck depends on cross traffic, and since such traffic can heavily fluctuate, bottlenecks can change at a high frequency (e.g., there can be oscillation between two or more links). This means that, when flows are partially routed along different paths, they may quickly change between sharing and not sharing a bottleneck. For simplicity, here it is assumed that a shared bottleneck is valid for a time interval that is significantly longer than the interval at which congestion controllers operate. Note that, for the only SBD mechanism defined in this document (multiplexing on the same five-tuple), the notion of a shared bottleneck stays correct even in the presence of fast traffic fluctuations: since all flows that are assumed to share a bottleneck are routed in the same way, if the bottleneck changes, it will still be shared. Islam, et al. Expires September 24, 2017 [Page 4] =0C Internet-Draft Coupled congestion control for RTP media March 2017 4. Architectural overview Figure 1 shows the elements of the architecture for coupled congestion control: the Flow State Exchange (FSE), Shared Bottleneck Detection (SBD) and Flows. The FSE is a storage element that can be implemented in two ways: active and passive. In the active version, it initiates communication with flows and SBD. However, in the passive version, it does not actively initiate communication with flows and SBD; its only active role is internal state maintenance (e.g., an implementation could use soft state to remove a flow's data after long periods of inactivity). Every time a flow's congestion control mechanism would normally update its sending rate, the flow instead updates information in the FSE and performs a query on the FSE, leading to a sending rate that can be different from what the congestion controller originally determined. Using information about/from the currently active flows, SBD updates the FSE with the correct Flow State Identifiers (FSIs). This document describes both active and passive versions, however the passive version is put into the appendix as it is extremely experimental. Figure 2 shows the interaction between flows and the FSE, using the variable names defined in Section 5.2. ------- <--- Flow 1 | FSE | <--- Flow 2 .. ------- <--- .. Flow N ^ | | ------- | | SBD | <-------| ------- Figure 1: Coupled congestion control architecture Islam, et al. Expires September 24, 2017 [Page 5] =0C Internet-Draft Coupled congestion control for RTP media March 2017 Flow#1(cc) FSE Flow#2(cc) ---------- --- ---------- #1 JOIN ----register--> REGISTER REGISTER <--register-- JOIN #1 #2 CC_R(1) ----UPDATE----> UPDATE (in) #3 NEW RATE <---FSE_R(1)-- UPDATE (out) --FSE_R(2)-> #3 NEW RATE Figure 2: Flow-FSE interaction Since everything shown in Figure 1 is assumed to operate on a single host (the sender) only, this document only describes aspects that have an influence on the resulting on-the-wire behavior. It does, for instance, not define how many bits must be used to represent FSIs, or in which way the entities communicate. Implementations can take various forms: for instance, all the elements in the figure could be implemented within a single application, thereby operating on flows generated by that application only. Another alternative could be to implement both the FSE and SBD together in a separate process which different applications communicate with via some form of Inter-Process Communication (IPC). Such an implementation would extend the scope to flows generated by multiple applications. The FSE and SBD could also be included in the Operating System kernel. 5. Roles This section gives an overview of the roles of the elements of coupled congestion control, and provides an example of how coupled congestion control can operate. 5.1. SBD SBD uses knowledge about the flows to determine which flows belong in the same Flow Group (FG), and assigns FGIs accordingly. This knowledge can be derived in three basic ways: 1. =46rom multiplexing: it can be based on the simple assumption = that packets sharing the same five-tuple (IP source and destination address, protocol, and transport layer port number pair) and having the same values for the Differentiated Services Code Point (DSCP) and the ECN field in the IP header are typically treated in the same way along the path. The latter method is the only one specified in this document: SBD MAY consider all flows that use the same five-tuple, DSCP and ECN field value to belong to the same FG. This classification applies to certain tunnels, or Islam, et al. Expires September 24, 2017 [Page 6] =0C Internet-Draft Coupled congestion control for RTP media March 2017 RTP flows that are multiplexed over one transport (cf. [transport-multiplex]). Such multiplexing is also a recommended usage of RTP in rtcweb [rtcweb-rtp-usage]. 2. Via configuration: e.g. by assuming that a common wireless uplink is also a shared bottleneck. 3. =46rom measurements: e.g. by considering correlations among measured delay and loss as an indication of a shared bottleneck. The methods above have some essential trade-offs: e.g., multiplexing is a completely reliable measure, however it is limited in scope to two end points (i.e., it cannot be applied to couple congestion controllers of one sender talking to multiple receivers). A measurement-based SBD mechanism is described in [I-D.ietf-rmcat-sbd]. Measurements can never be 100% reliable, in particular because they are based on the past but applying coupled congestion control means to make an assumption about the future; it is therefore recommended to implement cautionary measures, e.g. by disabling coupled congestion control if enabling it causes a significant increase in delay and/or packet loss. Measurements also take time, which entails a certain delay for turning on coupling (refer to [I-D.ietf-rmcat-sbd] for details). Using system configuration to decide about shared bottlenecks can be more efficient (faster to obtain) than using measurements, but it relies on assumptions about the network environment. 5.2. FSE The FSE contains a list of all flows that have registered with it. For each flow, it stores the following: o a unique flow number f to identify the flow o the FGI of the FG that it belongs to (based on the definitions in this document, a flow has only one bottleneck, and can therefore be in only one FG) o a priority P(f), which here is assumed to be represented as a positive number within a fixed range. o The rate used by the flow in bits per second, FSE_R(f). Note that the absolute range of priorities does not matter: the algorithm works with a flow's priority portion of the sum of all priority values. For example, if there are two flows, flow 1 with priority 1 and flow 2 with priority 2, the sum of the priorities is 3. Then, flow 1 will be assigned 1/3 of the aggregate sending rate Islam, et al. Expires September 24, 2017 [Page 7] =0C Internet-Draft Coupled congestion control for RTP media March 2017 and flow 2 will be assigned 2/3 of the aggregate sending rate. Priorities can be mapped to the "very-low", "low", "medium" or "high" priority levels described in [I-D.ietf-rtcweb-transports] by simply using the values 1, 2, 4 and 8, respectively. In the FSE, each FG contains one static variable S_CR which is the sum of the calculated rates of all flows in the same FG. This value is used to calculate the sending rate. The information listed here is enough to implement the sample flow algorithm given below. FSE implementations could easily be extended to store, e.g., a flow's current sending rate for statistics gathering or future potential optimizations. 5.3. Flows Flows register themselves with SBD and FSE when they start, deregister from the FSE when they stop, and carry out an UPDATE function call every time their congestion controller calculates a new sending rate. Via UPDATE, they provide the newly calculated rate and optionally (if the algorithm supports it) the desired rate. The desired rate is less than the calculated rate in case of application- limited flows; otherwise, it is the same as the calculated rate. Below, two example algorithms are described. While other algorithms could be used instead, the same algorithm must be applied to all flows. Names of variables used in the algorithms are explained below. o CC_R(f) - The rate received from the congestion controller of flow f when it calls UPDATE. o FSE_R(f) - The rate calculated by the FSE for flow f. o S_CR - The sum of the calculated rates of all flows in the same FG; this value is used to calculate the sending rate. o FG - A group of flows having the same FGI, and hence sharing the same bottleneck. o P(f) - The priority of flow f which is received from the flow's congestion controller; the FSE uses this variable for calculating FSE_R(f). o S_P - The sum of all the priorities. Islam, et al. Expires September 24, 2017 [Page 8] =0C Internet-Draft Coupled congestion control for RTP media March 2017 5.3.1. Example algorithm 1 - Active FSE This algorithm was designed to be the simplest possible method to assign rates according to the priorities of flows. Simulations results in [fse] indicate that it does however not significantly reduce queuing delay and packet loss. (1) When a flow f starts, it registers itself with SBD and the FSE. FSE_R(f) is initialized with the congestion controller's initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, it adds its FSE_R(f) to S_CR. (2) When a flow f stops or pauses, its entry is removed from the list. (3) Every time the congestion controller of the flow f determines a new sending rate CC_R(f), the flow calls UPDATE, which carries out the tasks listed below to derive the new sending rates for all the flows in the FG. A flow's UPDATE function uses a local (i.e. per-flow) temporary variable S_P, which is the sum of all the priorities. (a) It updates S_CR. S_CR =3D S_CR + CC_R(f) - FSE_R(f) (b) It calculates the sum of all the priorities, S_P. S_P =3D 0 for all flows i in FG do S_P =3D 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) =3D (P(i)*S_CR)/S_P send FSE_R(i) to the flow i end for Islam, et al. Expires September 24, 2017 [Page 9] =0C Internet-Draft Coupled congestion control for RTP media March 2017 5.3.2. Example algorithm 2 - Conservative Active FSE This algorithm extends algorithm 1 to conservatively emulate the behavior of a single flow by proportionally reducing the aggregate rate on congestion. Simulations results in [fse] indicate that it can significantly reduce queuing delay and packet loss. (1) When a flow f starts, it registers itself with SBD and the FSE. FSE_R(f) is initialized with the congestion controller's initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, it adds its FSE_R(f) to S_CR. (2) When a flow f stops or pauses, its entry is removed from the list. (3) Every time the congestion controller of the flow f determines a new sending rate CC_R(f), the flow calls UPDATE, which carries out the tasks listed below to derive the new sending rates for all the flows in the FG. A flow's UPDATE function uses a local (i.e. per-flow) temporary variable S_P, which is the sum of all the priorities, and a local variable DELTA, which is used to calculate the difference between CC_R(f) and the previously stored FSE_R(f). To prevent flows from either ignoring congestion or overreacting, a timer keeps them from changing their rates immediately after the common rate reduction that follows a congestion event. This timer is set to 2 RTTs of the flow that experienced congestion because it is assumed that a congestion event can persist for up to one RTT of that flow, with another RTT added to compensate for fluctuations in the measured RTT value. (a) It updates S_CR based on DELTA. if Timer has expired or not set then DELTA =3D CC_R(f) - FSE_R(f) if DELTA < 0 then // Reduce S_CR proportionally S_CR =3D S_CR * CC_R(f) / FSE_R(f) Set Timer for 2 RTTs else S_CR =3D S_CR + DELTA end if end if (b) It calculates the sum of all the priorities, S_P. Islam, et al. Expires September 24, 2017 [Page 10] =0C Internet-Draft Coupled congestion control for RTP media March 2017 S_P =3D 0 for all flows i in FG do S_P =3D 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) =3D (P(i)*S_CR)/S_P send FSE_R(i) to the flow i end for 6. Application This section specifies how the FSE can be applied to specific congestion control mechanisms and makes general recommendations that facilitate applying the FSE to future congestion controls. 6.1. NADA Network-Assisted Dynamic Adapation (NADA) [I-D.ietf-rmcat-nada] is a congestion control scheme for rtcweb. It calculates a reference rate r_ref upon receiving an acknowledgment, and then, based on the reference rate, it calculates a video target rate r_vin and a sending rate for the flows, r_send. When applying the FSE to NADA, the UPDATE function call described in Section 5.3 gives the FSE NADA's reference rate r_ref. The recommended algorithm for NADA is the Active FSE in Section 5.3.1. In step 3 (c), when the FSE_R(i) is "sent" to the flow i, this means updating r_ref(r_vin and r_send) of flow i with the value of FSE_R(i). 6.2. General recommendations This section provides general advice for applying the FSE to congestion control mechanisms. Receiver-side calculations: When receiver-side calculations make assumptions about the rate of the sender, the calculations need to be synchronized or the receiver needs to be updated accordingly. This applies to TFRC [RFC5348], for example, where simulations showed somewhat less favorable results when using the FSE without a receiver-side change [fse]. Islam, et al. Expires September 24, 2017 [Page 11] =0C Internet-Draft Coupled congestion control for RTP media March 2017 Stateful algorithms: When a congestion control algorithm is stateful (e.g., TCP, with Slow Start, Congestion Avoidance and Fast Recovery), these states should be carefully considered such that the overall state of the aggregate flow is correct. This may require sharing more information in the UPDATE call. Rate jumps: The FSE-based coupling algorithms can let a flow quickly increase its rate to its fair share, e.g. when a new flow joins or after a quiescent period. In case of window-based congestion controls, this may produce a burst which should be mitigated in some way. An example of how this could be done without using a timer is presented in [anrw2016], using TCP as an example. 7. Expected feedback from experiments The algorithm described in this memo has so far been evaluated using simulations covering all the tests for more than one flow from [I-D.ietf-rmcat-eval-test] (see [IETF-93], [IETF-94]). Experiments should confirm these results using at least the NADA congestion control algorithm with real-life code (e.g., browsers communicating over an emulated network covering the conditions in [I-D.ietf-rmcat-eval-test]. The tests with real-life code should be repeated afterwards in real network environments and monitored. Experiments should investigate cases where the media coder's output rate is below the rate that is calculated by the coupling algorithm (FSE_R(i) in algorithms 1 and 2, section 5.3). Implementers and testers are invited to document their findings in an Internet draft. 8. Acknowledgements This document has benefitted from discussions with and feedback from Andreas Petlund, Anna Brunstrom, Colin Perkins, David Hayes, David Ros (who also gave the FSE its name), Ingemar Johansson, Karen Nielsen, Kristian Hiorth, Mirja Kuehlewind, Martin Stiemerling, Varun Singh, Xiaoqing Zhu, and Zaheduzzaman Sarker. The authors would like to especially thank Xiaoqing Zhu and Stefan Holmer for helping with NADA and GCC. This work was partially funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). Islam, et al. Expires September 24, 2017 [Page 12] =0C Internet-Draft Coupled congestion control for RTP media March 2017 9. IANA Considerations This memo includes no request to IANA. 10. Security Considerations In scenarios where the architecture described in this document is applied across applications, various cheating possibilities arise: e.g., supporting wrong values for the calculated rate, the desired rate, or the priority of a flow. In the worst case, such cheating could either prevent other flows from sending or make them send at a rate that is unreasonably large. The end result would be unfair behavior at the network bottleneck, akin to what could be achieved with any UDP based application. Hence, since this is no worse than UDP in general, there seems to be no significant harm in using this in the absence of UDP rate limiters. In the case of a single-user system, it should also be in the interest of any application programmer to give the user the best possible experience by using reasonable flow priorities or even letting the user choose them. In a multi-user system, this interest may not be given, and one could imagine the worst case of an "arms race" situation, where applications end up setting their priorities to the maximum value. If all applications do this, the end result is a fair allocation in which the priority mechanism is implicitly eliminated, and no major harm is done. 11. References 11.1. Normative References [I-D.ietf-rmcat-nada] Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified Congestion Control Scheme for Real-Time Media", draft- ietf-rmcat-nada-03 (work in progress), September 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, DOI 10.17487/RFC3124, June 2001, . Islam, et al. Expires September 24, 2017 [Page 13] =0C Internet-Draft Coupled congestion control for RTP media March 2017 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . 11.2. Informative References [anrw2016] Islam, S. and M. Welzl, "Start Me Up:Determining and Sharing TCP's Initial Congestion Window", ACM, IRTF, ISOC Applied Networking Research Workshop 2016 (ANRW 2016) , 2016. [fse] Islam, S., Welzl, M., Gjessing, S., and N. Khademi, "Coupled Congestion Control for RTP Media", ACM SIGCOMM Capacity Sharing Workshop (CSWS 2014) and ACM SIGCOMM CCR 44(4) 2014; extended version available as a technical report from http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf , 2014. [fse-noms] Islam, S., Welzl, M., Hayes, D., and S. Gjessing, "Managing Real-Time Media Flows through a Flow State Exchange", IEEE NOMS 2016, Istanbul, Turkey , 2016. [I-D.ietf-rmcat-eval-test] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- eval-test-04 (work in progress), October 2016. [I-D.ietf-rmcat-gcc] Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real- Time Communication", draft-ietf-rmcat-gcc-02 (work in progress), July 2016. [I-D.ietf-rmcat-sbd] Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.", draft-ietf-rmcat-sbd-04 (work in progress), March 2016. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", Internet-draft draft-ietf-rtcweb-transports-17.txt, October 2016. Islam, et al. Expires September 24, 2017 [Page 14] =0C Internet-Draft Coupled congestion control for RTP media March 2017 [IETF-93] Islam, S., Welzl, M., and S. Gjessing, "Updates on Coupled Congestion Control for RTP Media", July 2015, . [IETF-94] Islam, S., Welzl, M., and S. Gjessing, "Updates on Coupled Congestion Control for RTP Media", November 2015, . [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", Internet-draft draft-ietf-rtcweb-rtp-usage-26.txt, March 2016. [transport-multiplex] Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a Single Lower-Layer Transport", Internet-draft draft- westerlund-avtcore-transport-multiplexing-07.txt, October 2013. Appendix A. Application to GCC Google Congestion Control (GCC) [I-D.ietf-rmcat-gcc] is another congestion control scheme for RTP flows that is under development. GCC is not yet finalised, but at the time of this writing, the rate control of GCC employs two parts: controlling the bandwidth estimate based on delay, and controlling the bandwidth estimate based on loss. Both are designed to estimate the available bandwidth, A_hat. When applying the FSE to GCC, the UPDATE function call described in Section 5.3 gives the FSE GCC's estimate of available bandwidth A_hat. The recommended algorithm for GCC is the Active FSE in Section 5.3.1. In step 3 (c), when the FSE_R(i) is "sent" to the flow i, this means updating A_hat of flow i with the value of FSE_R(i). Islam, et al. Expires September 24, 2017 [Page 15] =0C Internet-Draft Coupled congestion control for RTP media March 2017 Appendix B. Scheduling When connections originate from the same host, it would be possible to use only one single sender-side congestion controller which determines the overall allowed sending rate, and then use a local scheduler to assign a proportion of this rate to each RTP session. This way, priorities could also be implemented as a function of the scheduler. The Congestion Manager (CM) [RFC3124] also uses such a scheduling function. Appendix C. Example algorithm - Passive FSE Active algorithms calculate the rates for all the flows in the FG and actively distribute them. In a passive algorithm, UPDATE returns a rate that should be used instead of the rate that the congestion controller has determined. This can make a passive algorithm easier to implement; however, when round-trip times of flows are unequal, shorter-RTT flows may (depending on the congestion control algorithm) update and react to the overall FSE state more often than longer-RTT flows, which can produce unwanted side effects. This problem is more significant when the congestion control convergence depends on the RTT. While the passive algorithm works better for congestion controls with RTT-independent convergence, it can still produce oscillations on short time scales. The algorithm described below is therefore considered as highly experimental and not safe to deploy outside of testbed environments. Results of a simplified passive FSE algorithm with both NADA and GCC can be found in [fse-noms]. This passive version of the FSE stores the following information in addition to the variables described in Section 5.2: o The desired rate DR(f) of flow f. This can be smaller than the calculated rate if the application feeding into the flow has less data to send than the congestion controller would allow. In case of a bulk transfer, DR(f) must be set to CC_R(f) received from the congestion module of flow f. The passive version of the FSE contains one static variable per FG called TLO (Total Leftover Rate -- used to let a flow 'take' bandwidth from application-limited or terminated flows) which is initialized to 0. For the passive version, S_CR is limited to increase or decrease as conservatively as a flow's congestion controller decides in order to prohibit sudden rate jumps. (1) When a flow f starts, it registers itself with SBD and the FSE. FSE_R(f) and DR(f) are initialized with the congestion controller's initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, it adds its FSE_R(f) to S_CR. Islam, et al. Expires September 24, 2017 [Page 16] =0C Internet-Draft Coupled congestion control for RTP media March 2017 (2) When a flow f stops or pauses, it sets its DR(f) to 0 and sets P(f) to -1. (3) Every time the congestion controller of the flow f determines a new sending rate CC_R(f), assuming the flow's new desired rate new_DR(f) to be "infinity" in case of a bulk data transfer with an unknown maximum rate, the flow calls UPDATE, which carries out the tasks listed below to derive the flow's new sending rate, Rate(f). A flow's UPDATE function uses a few local (i.e. per-flow) temporary variables, which are all initialized to 0: DELTA, new_S_CR and S_P. (a) For all the flows in its FG (including itself), it calculates the sum of all the calculated rates, new_S_CR. Then it calculates DELTA: the difference between FSE_R(f) and CC_R(f). for all flows i in FG do new_S_CR =3D new_S_CR + FSE_R(i) end for DELTA =3D CC_R(f) - FSE_R(f) (b) It updates S_CR, FSE_R(f) and DR(f). FSE_R(f) =3D CC_R(f) if DELTA > 0 then // the flow's rate has increased S_CR =3D S_CR + DELTA else if DELTA < 0 then S_CR =3D new_S_CR + DELTA end if DR(f) =3D min(new_DR(f),FSE_R(f)) (c) It calculates the leftover rate TLO, removes the terminated flows from the FSE and calculates the sum of all the priorities, S_P. Islam, et al. Expires September 24, 2017 [Page 17] =0C Internet-Draft Coupled congestion control for RTP media March 2017 for all flows i in FG do if P(i)<0 then delete flow else S_P =3D S_P + P(i) end if end for if DR(f) < FSE_R(f) then TLO =3D TLO + (P(f)/S_P) * S_CR - DR(f)) end if (d) It calculates the sending rate, Rate(f). Rate(f) =3D min(new_DR(f), (P(f)*S_CR)/S_P + TLO) if Rate(f) !=3D new_DR(f) and TLO > 0 then TLO =3D 0 // f has 'taken' TLO end if (e) It updates DR(f) and FSE_R(f) with Rate(f). if Rate(f) > DR(f) then DR(f) =3D Rate(f) end if FSE_R(f) =3D Rate(f) The goals of the flow algorithm are to achieve prioritization, improve network utilization in the face of application-limited flows, and impose limits on the increase behavior such that the negative impact of multiple flows trying to increase their rate together is minimized. It does that by assigning a flow a sending rate that may not be what the flow's congestion controller expected. It therefore builds on the assumption that no significant inefficiencies arise from temporary application-limited behavior or from quickly jumping to a rate that is higher than the congestion controller intended. How problematic these issues really are depends on the controllers in use and requires careful per-controller experimentation. The coupled congestion control mechanism described here also does not require all controllers to be equal; effects of heterogeneous controllers, or homogeneous controllers being in different states, are also subject to experimentation. This algorithm gives all the leftover rate of application-limited flows to the first flow that updates its sending rate, provided that this flow needs it all (otherwise, its own leftover rate can be taken by the next flow that updates its rate). Other policies could be Islam, et al. Expires September 24, 2017 [Page 18] =0C Internet-Draft Coupled congestion control for RTP media March 2017 applied, e.g. to divide the leftover rate of a flow equally among all other flows in the FGI. C.1. Example operation (passive) In order to illustrate the operation of the passive coupled congestion control algorithm, this section presents a toy example of two flows that use it. Let us assume that both flows traverse a common 10 Mbit/s bottleneck and use a simplistic congestion controller that starts out with 1 Mbit/s, increases its rate by 1 Mbit/s in the absence of congestion and decreases it by 2 Mbit/s in the presence of congestion. For simplicity, flows are assumed to always operate in a round-robin fashion. Rate numbers below without units are assumed to be in Mbit/s. For illustration purposes, the actual sending rate is also shown for every flow in FSE diagrams even though it is not really stored in the FSE. Flow #1 begins. It is a bulk data transfer and considers itself to have top priority. This is the FSE after the flow algorithm's step 1: ---------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 1 | 1 | 1 | ---------------------------------------- S_CR =3D 1, TLO =3D 0 Its congestion controller gradually increases its rate. Eventually, at some point, the FSE should look like this: ----------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 10 | 10 | 10 | ----------------------------------------- S_CR =3D 10, TLO =3D 0 Now another flow joins. It is also a bulk data transfer, and has a lower priority (0.5): Islam, et al. Expires September 24, 2017 [Page 19] =0C Internet-Draft Coupled congestion control for RTP media March 2017 ------------------------------------------ | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 10 | 10 | 10 | | 2 | 1 | 0.5 | 1 | 1 | 1 | ------------------------------------------ S_CR =3D 11, TLO =3D 0 Now assume that the first flow updates its rate to 8, because the total sending rate of 11 exceeds the total capacity. Let us take a closer look at what happens in step 3 of the flow algorithm. CC_R(1) =3D 8. new_DR(1) =3D infinity. 3 a) new_S_CR =3D 11; DELTA =3D 8 - 10 =3D -2. 3 b) FSE_R(1) =3D 8. DELTA is negative, hence S_CR =3D 9; DR(1) =3D 8. 3 c) S_P =3D 1.5. 3 d) new sending rate Rate(1) =3D min(infinity, 1/1.5 * 9 + 0) =3D 6. 3 e) FSE_R(1) =3D 6. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 6 | 8 | 6 | | 2 | 1 | 0.5 | 1 | 1 | 1 | ------------------------------------------- S_CR =3D 9, TLO =3D 0 The effect is that flow #1 is sending with 6 Mbit/s instead of the 8 Mbit/s that the congestion controller derived. Let us now assume that flow #2 updates its rate. Its congestion controller detects that the network is not fully saturated (the actual total sending rate is 6+1=3D7) and increases its rate. Islam, et al. Expires September 24, 2017 [Page 20] =0C Internet-Draft Coupled congestion control for RTP media March 2017 CC_R(2) =3D 2. new_DR(2) =3D infinity. 3 a) new_S_CR =3D 7; DELTA =3D 2 - 1 =3D 1. 3 b) FSE_R(2) =3D 2. DELTA is positive, hence S_CR =3D 9 + 1 =3D 10; DR(2) =3D 2. 3 c) S_P =3D 1.5. 3 d) Rate(2) =3D min(infinity, 0.5/1.5 * 10 + 0) =3D 3.33. 3 e) DR(2) =3D FSE_R(2) =3D 3.33. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 6 | 8 | 6 | | 2 | 1 | 0.5 | 3.33 | 3.33 | 3.33 | ------------------------------------------- S_CR =3D 10, TLO =3D 0 The effect is that flow #2 is now sending with 3.33 Mbit/s, which is close to half of the rate of flow #1 and leads to a total utilization of 6(#1) + 3.33(#2) =3D 9.33 Mbit/s. Flow #2's congestion controller has increased its rate faster than the controller actually expected. Now, flow #1 updates its rate. Its congestion controller detects that the network is not fully saturated and increases its rate. Additionally, the application feeding into flow #1 limits the flow's sending rate to at most 2 Mbit/s. CC_R(1) =3D 7. new_DR(1) =3D 2. 3 a) new_S_CR =3D 9.33; DELTA =3D 1. 3 b) FSE_R(1) =3D 7, DELTA is positive, hence S_CR =3D 10 + 1 =3D 11; DR(1) =3D min(2, 7) =3D 2. 3 c) S_P =3D 1.5; DR(1) < FSE_R(1), hence TLO =3D 1/1.5 * 11 - 2 =3D = 5.33. 3 d) Rate(1) =3D min(2, 1/1.5 * 11 + 5.33) =3D 2. 3 e) FSE_R(1) =3D 2. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 2 | 2 | 2 | | 2 | 1 | 0.5 | 3.33 | 3.33 | 3.33 | ------------------------------------------- S_CR =3D 11, TLO =3D 5.33 Islam, et al. Expires September 24, 2017 [Page 21] =0C Internet-Draft Coupled congestion control for RTP media March 2017 Now, the total rate of the two flows is 2 + 3.33 =3D 5.33 Mbit/s, = i.e. the network is significantly underutilized due to the limitation of flow #1. Flow #2 updates its rate. Its congestion controller detects that the network is not fully saturated and increases its rate. CC_R(2) =3D 4.33. new_DR(2) =3D infinity. 3 a) new_S_CR =3D 5.33; DELTA =3D 1. 3 b) FSE_R(2) =3D 4.33. DELTA is positive, hence S_CR =3D 12; DR(2) =3D 4.33. 3 c) S_P =3D 1.5. 3 d) Rate(2) =3D min(infinity, 0.5/1.5 * 12 + 5.33 ) =3D 9.33. 3 e) FSE_R(2) =3D 9.33, DR(2) =3D 9.33. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 2 | 2 | 2 | | 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 | ------------------------------------------- S_CR =3D 12, TLO =3D 0 Now, the total rate of the two flows is 2 + 9.33 =3D 11.33 Mbit/s. Finally, flow #1 terminates. It sets P(1) to -1 and DR(1) to 0. Let us assume that it terminated late enough for flow #2 to still experience the network in a congested state, i.e. flow #2 decreases its rate in the next iteration. Islam, et al. Expires September 24, 2017 [Page 22] =0C Internet-Draft Coupled congestion control for RTP media March 2017 CC_R(2) =3D 7.33. new_DR(2) =3D infinity. 3 a) new_S_CR =3D 11.33; DELTA =3D -2. 3 b) FSE_R(2) =3D 7.33. DELTA is negative, hence S_CR =3D 9.33; DR(2) =3D 7.33. 3 c) Flow 1 has P(1) =3D -1, hence it is deleted from the FSE. S_P =3D 0.5. 3 d) Rate(2) =3D min(infinity, 0.5/0.5*9.33 + 0) =3D 9.33. 3 e) FSE_R(2) =3D DR(2) =3D 9.33. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 | ------------------------------------------- S_CR =3D 9.33, TLO =3D 0 Appendix D. Change log D.1. draft-welzl-rmcat-coupled-cc D.1.1. Changes from -00 to -01 o Added change log. o Updated the example algorithm and its operation. D.1.2. Changes from -01 to -02 o Included an active version of the algorithm which is simpler. o Replaced "greedy flow" with "bulk data transfer" and "non-greedy" with "application-limited". o Updated new_CR to CC_R, and CR to FSE_R for better understanding. D.1.3. Changes from -02 to -03 o Included an active conservative version of the algorithm which reduces queue growth and packet loss; added a reference to a technical report that shows these benefits with simulations. o Moved the passive variant of the algorithm to appendix. Islam, et al. Expires September 24, 2017 [Page 23] =0C Internet-Draft Coupled congestion control for RTP media March 2017 D.1.4. Changes from -03 to -04 o Extended SBD section. o Added a note about window-based controllers. D.1.5. Changes from -04 to -05 o Added a section about applying the FSE to specific congestion control algorithms, with a subsection specifying its use with NADA. D.2. draft-ietf-rmcat-coupled-cc D.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 o Moved scheduling section to the appendix. D.2.2. Changes from -00 to -01 o Included how to apply the algorithm to GCC. o Updated variable names of NADA to be in line with the latest version. o Added a reference to [I-D.ietf-rtcweb-transports] to make a connection to the prioritization text there. D.2.3. Changes from -01 to -02 o Minor changes. o Moved references of NADA and GCC from informative to normative. o Added a reference for the passive variant of the algorithm. D.2.4. Changes from -02 to -03 o Minor changes. o Added a section about expected feedback from experiments. D.2.5. Changes from -03 to -04 o Described the names of variables used in the algorithms. o Added a diagram to illustrate the interaction between flows and the FSE. Islam, et al. Expires September 24, 2017 [Page 24] =0C Internet-Draft Coupled congestion control for RTP media March 2017 o Added text on the trade-off of using the configuration based approach. o Minor changes to enhance the readability. D.2.6. Changes from -04 to -05 o Changed several occurrences of "NADA and GCC" to "NADA", including the abstract. o Moved the application to GCC to an appendix, and made the GCC reference informative. o Provided a few more general recommendations on applying the coupling algorithm. D.2.7. Changes from -05 to -06 o Incorporated comments by Colin Perkins. Authors' Addresses Safiqul Islam University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 84 08 37 Email: safiquli@ifi.uio.no Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 20 Email: michawe@ifi.uio.no Islam, et al. Expires September 24, 2017 [Page 25] =0C Internet-Draft Coupled congestion control for RTP media March 2017 Stein Gjessing University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 44 Email: steing@ifi.uio.no Islam, et al. Expires September 24, 2017 [Page 26] --Apple-Mail=_87383AA4-BFA4-45C1-9A7D-AD3DE4914708 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_87383AA4-BFA4-45C1-9A7D-AD3DE4914708-- From nobody Fri Mar 24 16:21:27 2017 Return-Path: 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 8C43C1293DB for ; Fri, 24 Mar 2017 16:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 cXz7QoO1lCdT for ; Fri, 24 Mar 2017 16:21:24 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D469B1292D0 for ; Fri, 24 Mar 2017 16:21:23 -0700 (PDT) Received: from [81.187.2.149] (port=33964 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1crYWH-0003PE-Op for rmcat@ietf.org; Fri, 24 Mar 2017 23:21:22 +0000 From: Colin Perkins Content-Type: multipart/alternative; boundary="Apple-Mail=_FF5AA5CE-3E2C-42A4-BE43-DB10938A98B4" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Fri, 24 Mar 2017 23:21:18 +0000 To: "rmcat WG (rmcat@ietf.org)" X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: [rmcat] Proposal for revised RMCAT milestones X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 23:21:27 -0000 --Apple-Mail=_FF5AA5CE-3E2C-42A4-BE43-DB10938A98B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 WG, The working group=E2=80=99s milestones are outdated, with several of = them being in the past. After reviewing the state of the work, the = chairs propose to revise the group=E2=80=99s milestones as follows: Submit congestion control to IESG for Proposed Standard (Oct 2016 =E2=86=92= Nov 2018) Submit techniques to detect, instrument or diagnose failing to meet RT = schedules to IESG as Informational (Jun 2016 =E2=86=92 Jul 2018) Publish first draft of techniques to detect, instrument or diagnose = failing to meet RT schedules (Feb 2016 =E2=86=92 Mar 2018) Publish first draft of Standards Track congestion control algorithm (Feb = 2016 =E2=86=92 Mar 2018) Publish first draft of evaluation results (Feb 2016 -> Mar 2018) Submit requirements and evaluation criteria to IESG as Informational = (Dec 2015 =E2=86=92 Aug 2017) =E2=80=93 this is = draft-ietf-rmcat-cc-requirements and draft-ietf-rmcat-eval-criteria Submit RTCP extension requirements for use with congestion control = algorithms to AVTCORE (if needed) (Dec 2015 =E2=86=92 Aug 2017) =E2=80=93 = this is the design team output Submit interactions between applications and RTP flows to IESG as = Informational (Dec 2015 =E2=86=92 Mar 2018) Submit first congestion control candidate to IESG for Experimental = publication (Dec 2015 =E2=86=92 Apr 2017) =E2=80=93 this is SCReAM, = shortly followed by NADA Submit identifying and controlling groups of flows to IESG for = Experimental publication (Dec 2015 =E2=86=92 Apr 2017) =E2=80=93 this is = draft-ietf-rmcat-coupled-cc and draft-ietf-rmcat-sbd Before we do this, we=E2=80=99d appreciate comments from the working = group on this proposal, and whether the suggested milestones seem = reasonable. Thanks, Colin (for the WG co-chairs) --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_FF5AA5CE-3E2C-42A4-BE43-DB10938A98B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 WG,

The working group=E2=80=99s milestones are outdated, with = several of them being in the past. After reviewing the state = of the work, the chairs propose to revise the group=E2=80=99s milestones = as follows:

  • Submit congestion control to IESG for Proposed Standard (Oct 2016 =E2=86=92 Nov 2018)
  • Submit = techniques to detect, instrument or diagnose failing to meet = RT schedules to IESG as Informational (Jun = 2016 =E2=86=92 Jul 2018)
  • Publish first draft of techniques to detect, instrument or = diagnose failing to meet RT schedules (Feb = 2016 =E2=86=92 Mar 2018)
  • Publish first draft of Standards Track = congestion control algorithm (Feb 2016 =E2=86=92 Mar 2018)
  • Publish = first draft of evaluation results (Feb 2016 -> Mar = 2018)
  • Submit requirements and evaluation criteria = to IESG as Informational  (Dec 2015 =E2=86=92 Aug 2017) =E2=80=93 this is = draft-ietf-rmcat-cc-requirements and = draft-ietf-rmcat-eval-criteria
  • Submit RTCP = extension requirements for use with congestion control algorithms = to AVTCORE (if needed) (Dec 2015 =E2=86=92 Aug 2017) =E2=80=93 this is the design = team output
  • Submit interactions between = applications and RTP flows to IESG as Informational (Dec 2015 =E2=86=92 Mar = 2018)
  • Submit first congestion control candidate = to IESG for Experimental publication (Dec = 2015 =E2=86=92 Apr 2017) =E2=80=93 this is = SCReAM, shortly followed by NADA
  • Submit = identifying and controlling groups of flows to IESG = for Experimental publication (Dec 2015 =E2=86=92 Apr 2017) =E2=80=93 this is = draft-ietf-rmcat-coupled-cc and draft-ietf-rmcat-sbd

Before we do this, we=E2=80=99d appreciate comments from the = working group on this proposal, and whether the suggested milestones = seem reasonable.

Thanks,
Colin (for the WG co-chairs)



-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_FF5AA5CE-3E2C-42A4-BE43-DB10938A98B4-- From nobody Fri Mar 24 16:30:04 2017 Return-Path: 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 694A31292D0; Fri, 24 Mar 2017 16:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 D6QhEJ4jYRws; Fri, 24 Mar 2017 16:29:59 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B67C12922E; Fri, 24 Mar 2017 16:29:59 -0700 (PDT) Received: from [81.187.2.149] (port=42285 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1crYea-00051w-Kb; Fri, 24 Mar 2017 23:29:57 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Colin Perkins In-Reply-To: <9DCBD472-DFFF-43CF-BBDC-6241BEA2C67A@ifi.uio.no> Date: Fri, 24 Mar 2017 23:29:52 +0000 Cc: rmcat WG , draft-ietf-rmcat-coupled-cc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <111EB839-EC1B-4DCA-AC85-5AE63C21E812@csperkins.org> References: <148111854325.13729.9946710085994858033.idtracker@ietfa.amsl.com> <66C087EE-823A-43C9-8E8B-A2364FD6511B@csperkins.org> <79DC47FB-2032-444C-9654-A0A87F93CC18@csperkins.org> <0A54D20B-45D0-41F6-AAAD-923A60F6C285@csperkins.org> <9DCBD472-DFFF-43CF-BBDC-6241BEA2C67A@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 23:30:01 -0000 Looks good, thanks! (although maybe call out explicitly that the = priority has to be greater than zero?) Cheers, Colin > On 23 Mar 2017, at 13:47, Michael Welzl wrote: >=20 > Dear Colin, >=20 > Thanks a lot, this was very helpful ! We incorporated your comments = and attach the updated draft to this email, as right now submission is = closed. > Some answers in line: >=20 >=20 >> On 23 Mar 2017, at 00:33, Colin Perkins wrote: >>=20 >> Authors, >>=20 >> I=E2=80=99ve reviewed this draft while preparing the IESG write-up = and request for publication. I have a number of minor questions and = comments: >>=20 >> - Section 2 defines a Flow and gives an example as =E2=80=9Can RTP = session, or a sub-session that is multiplexed onto a single RTP = session=E2=80=9D. I believe this example is incorrect, and what is = intended is =E2=80=9Can RTP Stream [RFC7656], or a group of RTP Streams = multiplexed onto a single RTP session=E2=80=9D (Section 2.1.10 of RFC = 7656 defines the term RTP Stream carefully, so I think a reference is = useful; it also defines the term RTP Session in Section 2.2.2). Can you = please check and update are necessary. >=20 > Thanks a lot - of course you're right! We changed the definition of a = flow as follows: > "A flow is the entity that congestion control is operating on. It = could, for example, be a transport layer connection, or an RTP stream = , whether or not this RTP stream is = multiplexed onto an RTP session with other RTP streams." >=20 >=20 >> - Section 3 discusses limitations of the proposed algorithms. Would = it be appropriate to add a brief applicability statement either here, or = in the Introduction, stating that the described mechanisms are believed = safe to use, but are experimental and are presented for wider review and = operational evaluation? >=20 > OK, done, at the end of the introduction. >=20 >=20 >> - Section 5.1, bullet 1, notes that flows share a bottleneck if = they=E2=80=99re sent on the same 5-tuple and have the same DSCP value. = Should this also note that they need the same ECT mark? With the = proposed L4S ECN experiments, we=E2=80=99re likely to see quite = different behaviour between flows with NotECT/ECT(0) and those with = ECT(1) marking.=20 >=20 > Good catch! Done >=20 >=20 >> - Section 5.2 defines the priority in the range 0.1 to 1. Assuming = 0.1 is correct, it might be worth adding a brief note to explain this = choice, since readers might think it a typo for the more typical range = of 0 to 1.=20 >>=20 >> - Section 5.2, in the paragraph following the bullet points, the = draft suggests mapping priority levels from RTCWEB using the values 1, = 2, 4, and 8 =E2=80=93 how do these relate to the 0.1 to 1 range? >=20 > Another good catch! The value range really doesn't matter for our = algorithm, but 0 is not allowed (it might lead to a division by 0). >=20 > To clarify all of this, we have removed the "0.1 to 1" example in the = priority definition, and changed the text talking about 1, 2, 4 and 8 = levels to the following: >=20 > *** > Note that the absolute range of priorities does not matter: the > algorithm works with a flow's priority portion of the sum of all > priority values. For example, if there are two flows, flow 1 with > priority 1 and flow 2 with priority 2, the sum of the priorities is > 3. Then, flow 1 will be assigned 1/3 of the aggregate sending rate > and flow 2 will be assigned 2/3 of the aggregate sending rate. > Priorities can be mapped to the "very-low", "low", "medium" or = "high" > priority levels described in [I-D.ietf-rtcweb-transports] by simply > using the values 1, 2, 4 and 8, respectively. > *** >=20 >=20 >> - Section 5.3 defines terminology and describes the two algorithms. = The terminology used is inconsistent, sometimes using FSE_R and = sometimes FSE_R(f). If the intent is that these are the same variable, = the terminology should be aligned (I assume to FSE_R(f) since they=E2=80=99= re per-flow values, but the important point is that it=E2=80=99s = consistent). If there=E2=80=99s intended to be a difference between the = overall and per-flow values, can you please check that they=E2=80=99re = used consistently, and add a sentence to clarify the meanings of the = terms.=20 >>=20 >> - Section 5.3 also uses P and P(i) in a manner that suggests = they=E2=80=99re referring to the same parameter. Similarly for CC_R =E2=80= =93 should it be CC_R(i)? >=20 > Fixed everywhere. >=20 >=20 >> - Appendix C: similar terminology comments apply. >=20 > Fixed everywhere (here it also applies to the variables DR, new_DR and = Rate). >=20 >=20 >> - Appendix C: =E2=80=9Chighly experimental=E2=80=9D =E2=80=93 It = might be useful to add a brief applicability statement for implementors = so they know whether this is safe to deploy outside of testbed = environments. >=20 > done (we added "and not safe to deploy outside of testbed = environments" after "highly experimental"). >=20 > Cheers, > Michael >=20 > >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Fri Mar 24 22:52:54 2017 Return-Path: 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 2EC4C1299DC for ; Fri, 24 Mar 2017 22:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 Ut_46mJGcJTG for ; Fri, 24 Mar 2017 22:52:49 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 9BF1B12942F for ; Fri, 24 Mar 2017 22:52:49 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cred5-0003tG-Rg; Sat, 25 Mar 2017 06:52:47 +0100 Received: from [81.92.27.192] (helo=[10.26.63.177]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cred4-0006Ff-R5; Sat, 25 Mar 2017 06:52:47 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: <111EB839-EC1B-4DCA-AC85-5AE63C21E812@csperkins.org> Date: Sat, 25 Mar 2017 06:53:33 +0100 Cc: rmcat WG , draft-ietf-rmcat-coupled-cc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5CD82FB1-C38E-475B-9C3A-C7C61EAEEE04@ifi.uio.no> References: <148111854325.13729.9946710085994858033.idtracker@ietfa.amsl.com> <66C087EE-823A-43C9-8E8B-A2364FD6511B@csperkins.org> <79DC47FB-2032-444C-9654-A0A87F93CC18@csperkins.org> <0A54D20B-45D0-41F6-AAAD-923A60F6C285@csperkins.org> <9DCBD472-DFFF-43CF-BBDC-6241BEA2C67A@ifi.uio.no> <111EB839-EC1B-4DCA-AC85-5AE63C21E812@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 81.92.27.192 is neither permitted nor denied by domain of ifi.uio.no) client-ip=81.92.27.192; envelope-from=michawe@ifi.uio.no; helo=[10.26.63.177]; X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 2 total rcpts 53165 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C9FB8DDAB98A1F1E885F961CC51DBC2A2F242C4C X-UiO-SPAM-Test: remote_host: 81.92.27.192 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 18 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 05:52:53 -0000 Thanks! This is actually there but too weakly qualified: *** a priority P(f), which here is assumed to be represented as a positive number within a fixed range. *** Suggest to change to: *** a priority P(f), which is a positive number within a fixed range. *** Cheers, Michael > On Mar 25, 2017, at 12:29 AM, Colin Perkins wrote: >=20 > Looks good, thanks! (although maybe call out explicitly that the = priority has to be greater than zero?) >=20 > Cheers, > Colin >=20 >=20 >=20 >=20 >> On 23 Mar 2017, at 13:47, Michael Welzl wrote: >>=20 >> Dear Colin, >>=20 >> Thanks a lot, this was very helpful ! We incorporated your = comments and attach the updated draft to this email, as right now = submission is closed. >> Some answers in line: >>=20 >>=20 >>> On 23 Mar 2017, at 00:33, Colin Perkins wrote: >>>=20 >>> Authors, >>>=20 >>> I=E2=80=99ve reviewed this draft while preparing the IESG write-up = and request for publication. I have a number of minor questions and = comments: >>>=20 >>> - Section 2 defines a Flow and gives an example as =E2=80=9Can RTP = session, or a sub-session that is multiplexed onto a single RTP = session=E2=80=9D. I believe this example is incorrect, and what is = intended is =E2=80=9Can RTP Stream [RFC7656], or a group of RTP Streams = multiplexed onto a single RTP session=E2=80=9D (Section 2.1.10 of RFC = 7656 defines the term RTP Stream carefully, so I think a reference is = useful; it also defines the term RTP Session in Section 2.2.2). Can you = please check and update are necessary. >>=20 >> Thanks a lot - of course you're right! We changed the definition of a = flow as follows: >> "A flow is the entity that congestion control is operating on. It = could, for example, be a transport layer connection, or an RTP stream = , whether or not this RTP stream is = multiplexed onto an RTP session with other RTP streams." >>=20 >>=20 >>> - Section 3 discusses limitations of the proposed algorithms. Would = it be appropriate to add a brief applicability statement either here, or = in the Introduction, stating that the described mechanisms are believed = safe to use, but are experimental and are presented for wider review and = operational evaluation? >>=20 >> OK, done, at the end of the introduction. >>=20 >>=20 >>> - Section 5.1, bullet 1, notes that flows share a bottleneck if = they=E2=80=99re sent on the same 5-tuple and have the same DSCP value. = Should this also note that they need the same ECT mark? With the = proposed L4S ECN experiments, we=E2=80=99re likely to see quite = different behaviour between flows with NotECT/ECT(0) and those with = ECT(1) marking.=20 >>=20 >> Good catch! Done >>=20 >>=20 >>> - Section 5.2 defines the priority in the range 0.1 to 1. Assuming = 0.1 is correct, it might be worth adding a brief note to explain this = choice, since readers might think it a typo for the more typical range = of 0 to 1.=20 >>>=20 >>> - Section 5.2, in the paragraph following the bullet points, the = draft suggests mapping priority levels from RTCWEB using the values 1, = 2, 4, and 8 =E2=80=93 how do these relate to the 0.1 to 1 range? >>=20 >> Another good catch! The value range really doesn't matter for our = algorithm, but 0 is not allowed (it might lead to a division by 0). >>=20 >> To clarify all of this, we have removed the "0.1 to 1" example in the = priority definition, and changed the text talking about 1, 2, 4 and 8 = levels to the following: >>=20 >> *** >> Note that the absolute range of priorities does not matter: the >> algorithm works with a flow's priority portion of the sum of all >> priority values. For example, if there are two flows, flow 1 with >> priority 1 and flow 2 with priority 2, the sum of the priorities is >> 3. Then, flow 1 will be assigned 1/3 of the aggregate sending rate >> and flow 2 will be assigned 2/3 of the aggregate sending rate. >> Priorities can be mapped to the "very-low", "low", "medium" or = "high" >> priority levels described in [I-D.ietf-rtcweb-transports] by simply >> using the values 1, 2, 4 and 8, respectively. >> *** >>=20 >>=20 >>> - Section 5.3 defines terminology and describes the two algorithms. = The terminology used is inconsistent, sometimes using FSE_R and = sometimes FSE_R(f). If the intent is that these are the same variable, = the terminology should be aligned (I assume to FSE_R(f) since they=E2=80=99= re per-flow values, but the important point is that it=E2=80=99s = consistent). If there=E2=80=99s intended to be a difference between the = overall and per-flow values, can you please check that they=E2=80=99re = used consistently, and add a sentence to clarify the meanings of the = terms.=20 >>>=20 >>> - Section 5.3 also uses P and P(i) in a manner that suggests = they=E2=80=99re referring to the same parameter. Similarly for CC_R =E2=80= =93 should it be CC_R(i)? >>=20 >> Fixed everywhere. >>=20 >>=20 >>> - Appendix C: similar terminology comments apply. >>=20 >> Fixed everywhere (here it also applies to the variables DR, new_DR = and Rate). >>=20 >>=20 >>> - Appendix C: =E2=80=9Chighly experimental=E2=80=9D =E2=80=93 It = might be useful to add a brief applicability statement for implementors = so they know whether this is safe to deploy outside of testbed = environments. >>=20 >> done (we added "and not safe to deploy outside of testbed = environments" after "highly experimental"). >>=20 >> Cheers, >> Michael >>=20 >> >>=20 >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 From nobody Sun Mar 26 03:50:37 2017 Return-Path: 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 49D4B12952D for ; Sun, 26 Mar 2017 03:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 YgNQWzrq4kSh for ; Sun, 26 Mar 2017 03:50:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5ED5C12952C for ; Sun, 26 Mar 2017 03:50:32 -0700 (PDT) X-AuditID: c1b4fb2d-275fe70000005be8-69-58d79cf63ed6 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id DD.B9.23528.6FC97D85; Sun, 26 Mar 2017 12:50:30 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.339.0; Sun, 26 Mar 2017 12:50:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jwmBfbOu6Q/ERDBTBHmk1RAHTcEn5fJ5pFIcD96Pl+k=; b=XkHWvu9YJfSkoX8U0VYxiDNr92YGD+i7xvtiwPYBHy8d5RLtoBFKHbkOEdg0jzLbqKdzpwLy0xew7ln+D1ih1ZzAJKN0SwimEIlxqG3wqVFzrXwIgtpvr20bB+Dk72fuLweaEuh20w0urmbH2A0z+H8y7l3fvxFp/c54IE12LWI= Received: from AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) by AM3PR07MB291.eurprd07.prod.outlook.com (10.242.108.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Sun, 26 Mar 2017 10:50:26 +0000 Received: from AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::512:738:8e77:e7e6]) by AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::512:738:8e77:e7e6%16]) with mapi id 15.01.1005.006; Sun, 26 Mar 2017 10:50:26 +0000 From: Zaheduzzaman Sarker To: Colin Perkins , "rmcat WG (rmcat@ietf.org)" Thread-Topic: [rmcat] Proposal for revised RMCAT milestones Thread-Index: AQHSpPVz6x3+yJHWzU20dc/QT5KzEaGnJdiA Date: Sun, 26 Mar 2017 10:50:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: csperkins.org; dkim=none (message not signed) header.d=none; csperkins.org; dmarc=none action=none header.from=ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [109.225.125.147] x-microsoft-exchange-diagnostics: 1; AM3PR07MB291; 7:aDoIc8HeBL90LQWIanvm7qc/lE8Smm64aCzXff9aLTVy4NWiQ4nP8F+K3Vl3PDKwPvS/SrXPtL/1KhDdz93SsGkqcn1MzzD26WdLD1ZczbusC5uJjHsn0a4JG7s1lFyhV6k41YI+uz+DRp9dTxAFCQq65INp+5GoseO4WFPiLCZLs/5JySPBCvFe23g+82OmD4rCnzRaTVobR8w4GkCbxgHiB+EbfTn1T6l82rXvETKp7c7cToV8ZWTP5jtf9ipgMpnUIB4XQTaRBhcNIjDp222l2CJSIAD+3zriu5HylxyWm6rzcq3ZG/7K8tRuF5mMw2EtTX3fVFxs+75Gvwg4Og== x-ms-office365-filtering-correlation-id: 0dd3ee46-4ece-43ab-c569-08d47435e9b4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM3PR07MB291; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278428928389397)(202460600054446); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(6072148); SRVR:AM3PR07MB291; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB291; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39410400002)(39450400003)(53936002)(7906003)(2950100002)(86362001)(7736002)(102836003)(25786009)(6116002)(3846002)(83506001)(6486002)(50986999)(6436002)(36756003)(6666003)(6506006)(189998001)(2906002)(3280700002)(66066001)(3660700001)(8676002)(5250100002)(76176999)(54356999)(561944003)(6246003)(81166006)(8936002)(38730400002)(53546009)(229853002)(6306002)(99286003)(606005)(6512007)(5660300001)(54896002)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB291; H:AM3PR07MB292.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4FD65F919C40zaheduzzamansarkerericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 10:50:11.6765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB291 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe+69u96tRo/L6UkLaiGk5DTrg6SWfpF96cWZtV7AZl5U0k12 TTNExAzKF1pv5ismCmpq5luairCpMDVRIZ2uxGqmmBCyQMlK8u4u8Nvv/M//nPOcw8OQsg6R N5OsS2cNOm2KgpZQZZpu/4D1SqsmqHbQJ6R+xYJCmubW6AhCVbKwQKvq6n4RF4irkrAENiU5 gzUEnr4hSWpq7SbS2i7fmZwfo3PRn4sFSMwAPgnFlrdUAZIwMtyKwNr93U0ILAi+2qZpPqBw MQnrXe9EfIkMlxBQ34QF1zyCuR9b2yUMQ+MwsNee4z0eOBY+Oz7SPO/Dp+Cp5ZFI0EPhm7WP FjgYWiwfKb6Uwr5QmufLy1IcDhObc6QwKgLae/nuYkaMI6GkZ8rJCHvCxmgzwTOJvcC2WE0I 22Co658gBZbDin3LOVaOlVC/3EzyT0b4OYLxMZubYDoG49ZFJPAR6BwqczUqJKHXIRX4LHya HHLp12Apv8/lT4bJpVmXfh2qiu3OMwIuJcBu76CFxAGYfvHTlZiioN26LBKu4g3zHx4iI/Ir 37GFwPGwUdMhKndewx1Gyhap8u0jkdgPWnsDBctheFb4xU3go3C/ssrFKjCuNVI7PS8R8wrJ OZbjUhODTyhZQ/JNjtPrlDo2vR1tfyVT5++AHtS0GmlGmEGKPdKggRmNTKTN4LJSzQgYUuEh ncralqQJ2qy7rEEfZ7idwnJm5MNQCi9pxMCkRoYTtensLZZNYw3/swQj9s5F/hXauPiEYaN7 tel9j7G6I18962gPGYzy6qyPDizKTM3O7DpDRHe92XToxBNLNQ3ZEWM+prqDh3KKKqQzjSNX 1C1V9x6bZva/VurPRw2Hm9WxeU98NZ2OgQd/HSJ6V0x4f6AqxdN7d2lDQKi+MWfUZ7htM2bI tlcdJ19dv+RoU1Bckva4P2ngtP8AsObuQEYDAAA= Archived-At: Subject: Re: [rmcat] Proposal for revised RMCAT milestones X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 10:50:35 -0000 --_000_D4FD65F919C40zaheduzzamansarkerericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkxvb2tzIHJlYXNvbmFibGUgdG8gbWUuDQoNCkJSDQoNClphaGVkDQoNClpBSEVEVVpa QU1BTiBTQVJLRVINCg0KRWlyY3Nzb24gUmVzZWFyY2gNCg0KRXJpY3Nzb24NCkxhYm9yYXRvcmll Z3LDpG5kIDExDQo5NzEyOCBMdWxlw6UsIFN3ZWRlbg0KUGhvbmUgKzQ2IDEwIDcxNyAzNyA0Mw0K TW9iaWxlICs0NiA3NiAxMTUgMzcgNDMNCk9mZmljZSArNDYgNzYgMTE1IDM3IDQzDQpGYXggKzQ2 IDkyMCA5OTYgMjENCnphaGVkdXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tPG1haWx0bzp6YWhl ZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbT4NCnd3dy5lcmljc3Nvbi5jb208aHR0cDovL3d3 dy5lcmljc3Nvbi5jb20vPg0KDQoNCkZyb206IHJtY2F0IDxybWNhdC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpybWNhdC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIENvbGluIFBhcmtp bnMgPGNzcEBjc3BlcmtpbnMub3JnPG1haWx0bzpjc3BAY3NwZXJraW5zLm9yZz4+DQpEYXRlOiBT YXR1cmRheSwgMjUgTWFyY2ggMjAxNyBhdCAwMDoyMQ0KVG86ICJybWNhdCBXRyAocm1jYXRAaWV0 Zi5vcmc8bWFpbHRvOnJtY2F0QGlldGYub3JnPikiIDxybWNhdEBpZXRmLm9yZzxtYWlsdG86cm1j YXRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3JtY2F0XSBQcm9wb3NhbCBmb3IgcmV2aXNlZCBSTUNB VCBtaWxlc3RvbmVzDQoNCldHLA0KDQpUaGUgd29ya2luZyBncm91cOKAmXMgbWlsZXN0b25lcyBh cmUgb3V0ZGF0ZWQsIHdpdGggc2V2ZXJhbCBvZiB0aGVtIGJlaW5nIGluIHRoZSBwYXN0LiBBZnRl ciByZXZpZXdpbmcgdGhlIHN0YXRlIG9mIHRoZSB3b3JrLCB0aGUgY2hhaXJzIHByb3Bvc2UgdG8g cmV2aXNlIHRoZSBncm91cOKAmXMgbWlsZXN0b25lcyBhcyBmb2xsb3dzOg0KDQoNCiAgKiAgIFN1 Ym1pdCBjb25nZXN0aW9uIGNvbnRyb2wgdG8gSUVTRyBmb3IgUHJvcG9zZWQgU3RhbmRhcmQgKE9j dCAyMDE2IOKGkiBOb3YgMjAxOCkNCiAgKiAgIFN1Ym1pdCB0ZWNobmlxdWVzIHRvIGRldGVjdCwg aW5zdHJ1bWVudCBvciBkaWFnbm9zZSBmYWlsaW5nIHRvIG1lZXQgUlQgc2NoZWR1bGVzIHRvIElF U0cgYXMgSW5mb3JtYXRpb25hbCAoSnVuIDIwMTYg4oaSIEp1bCAyMDE4KQ0KICAqICAgUHVibGlz aCBmaXJzdCBkcmFmdCBvZiB0ZWNobmlxdWVzIHRvIGRldGVjdCwgaW5zdHJ1bWVudCBvciBkaWFn bm9zZSBmYWlsaW5nIHRvIG1lZXQgUlQgc2NoZWR1bGVzIChGZWIgMjAxNiDihpIgTWFyIDIwMTgp DQogICogICBQdWJsaXNoIGZpcnN0IGRyYWZ0IG9mIFN0YW5kYXJkcyBUcmFjayBjb25nZXN0aW9u IGNvbnRyb2wgYWxnb3JpdGhtIChGZWIgMjAxNiDihpIgTWFyIDIwMTgpDQogICogICBQdWJsaXNo IGZpcnN0IGRyYWZ0IG9mIGV2YWx1YXRpb24gcmVzdWx0cyAoRmViIDIwMTYgLT4gTWFyIDIwMTgp DQogICogICBTdWJtaXQgcmVxdWlyZW1lbnRzIGFuZCBldmFsdWF0aW9uIGNyaXRlcmlhIHRvIElF U0cgYXMgSW5mb3JtYXRpb25hbCAgKERlYyAyMDE1IOKGkiBBdWcgMjAxNykg4oCTIHRoaXMgaXMg ZHJhZnQtaWV0Zi1ybWNhdC1jYy1yZXF1aXJlbWVudHMgYW5kIGRyYWZ0LWlldGYtcm1jYXQtZXZh bC1jcml0ZXJpYQ0KICAqICAgU3VibWl0IFJUQ1AgZXh0ZW5zaW9uIHJlcXVpcmVtZW50cyBmb3Ig dXNlIHdpdGggY29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobXMgdG8gQVZUQ09SRSAoaWYgbmVl ZGVkKSAoRGVjIDIwMTUg4oaSIEF1ZyAyMDE3KSDigJMgdGhpcyBpcyB0aGUgZGVzaWduIHRlYW0g b3V0cHV0DQogICogICBTdWJtaXQgaW50ZXJhY3Rpb25zIGJldHdlZW4gYXBwbGljYXRpb25zIGFu ZCBSVFAgZmxvd3MgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIChEZWMgMjAxNSDihpIgTWFyIDIw MTgpDQogICogICBTdWJtaXQgZmlyc3QgY29uZ2VzdGlvbiBjb250cm9sIGNhbmRpZGF0ZSB0byBJ RVNHIGZvciBFeHBlcmltZW50YWwgcHVibGljYXRpb24gKERlYyAyMDE1IOKGkiBBcHIgMjAxNykg 4oCTIHRoaXMgaXMgU0NSZUFNLCBzaG9ydGx5IGZvbGxvd2VkIGJ5IE5BREENCiAgKiAgIFN1Ym1p dCBpZGVudGlmeWluZyBhbmQgY29udHJvbGxpbmcgZ3JvdXBzIG9mIGZsb3dzIHRvIElFU0cgZm9y IEV4cGVyaW1lbnRhbCBwdWJsaWNhdGlvbiAoRGVjIDIwMTUg4oaSIEFwciAyMDE3KSDigJMgdGhp cyBpcyBkcmFmdC1pZXRmLXJtY2F0LWNvdXBsZWQtY2MgYW5kIGRyYWZ0LWlldGYtcm1jYXQtc2Jk DQoNCkJlZm9yZSB3ZSBkbyB0aGlzLCB3ZeKAmWQgYXBwcmVjaWF0ZSBjb21tZW50cyBmcm9tIHRo ZSB3b3JraW5nIGdyb3VwIG9uIHRoaXMgcHJvcG9zYWwsIGFuZCB3aGV0aGVyIHRoZSBzdWdnZXN0 ZWQgbWlsZXN0b25lcyBzZWVtIHJlYXNvbmFibGUuDQoNClRoYW5rcywNCkNvbGluIChmb3IgdGhl IFdHIGNvLWNoYWlycykNCg0KDQoNCi0tDQpDb2xpbiBQZXJraW5zDQpodHRwczovL2NzcGVya2lu cy5vcmcvDQoNCg0KDQoNCg== --_000_D4FD65F919C40zaheduzzamansarkerericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+SGks PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Mb29rcyByZWFzb25hYmxlIHRvIG1lLjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QlI8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlphaGVkPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGIgc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6 IEFyaWFsOyI+WkFIRURVWlpBTUFOIFNBUktFUiZuYnNwOzwvYj48L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgZm9udC1zaXplOiAxNXB4OyI+PGZvbnQgZmFj ZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyI+PGI+PGJyPg0KPC9iPjwvc3Bhbj48L2ZvbnQ+PHNwYW4gc3R5bGU9ImNvbG9yOiBy Z2IoNTEsIDUxLCA1MSk7Ij5FaXJjc3NvbiBSZXNlYXJjaDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyBmb250LXNpemU6IDE1cHg7Ij48Zm9udCBjb2xvcj0i IzMzMzMzMyI+PGJyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7Ij48Yj5Fcmljc3Nvbjxicj4NCjwvYj48L3NwYW4+PC9mb250Pjxmb250 IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+TGFi b3JhdG9yaWVncsOkbmQgMTE8YnI+DQo5NzEyOCBMdWxlw6UsIFN3ZWRlbjxicj4NClBob25lICYj NDM7NDYgMTAgNzE3IDM3IDQzPGJyPg0KTW9iaWxlICYjNDM7NDYgNzYgMTE1IDM3IDQzPGJyPg0K T2ZmaWNlICYjNDM7NDYgNzYgMTE1IDM3IDQzPGJyPg0KRmF4ICYjNDM7NDYgOTIwIDk5NiAyMTxi cj4NCjxhIGhyZWY9Im1haWx0bzp6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbSI+emFo ZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb208L2E+PGJyPg0KPC9zcGFuPjwvZm9udD48YSBo cmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8iPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIy IiBjb2xvcj0iYmx1ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPjx1Pnd3dy5lcmlj c3Nvbi5jb208L3U+PC9zcGFuPjwvZm9udD48L2E+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTVweDsiPjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp emU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5ybWNhdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJtY2F0LWJvdW5jZXNAaWV0Zi5vcmciPnJtY2F0LWJvdW5jZXNAaWV0 Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQ29saW4gUGFya2lucyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNzcEBjc3BlcmtpbnMub3JnIj5jc3BAY3NwZXJraW5zLm9yZzwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5TYXR1cmRheSwgMjUgTWFy Y2ggMjAxNyBhdCAwMDoyMTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzog PC9zcGFuPiZxdW90O3JtY2F0IFdHICg8YSBocmVmPSJtYWlsdG86cm1jYXRAaWV0Zi5vcmciPnJt Y2F0QGlldGYub3JnPC9hPikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpybWNhdEBpZXRmLm9y ZyI+cm1jYXRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0OiA8L3NwYW4+W3JtY2F0XSBQcm9wb3NhbCBmb3IgcmV2aXNlZCBSTUNBVCBt aWxlc3RvbmVzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpXRyw8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgd29ya2luZyBncm91cOKAmXMgbWlsZXN0b25lcyBh cmUgb3V0ZGF0ZWQsIHdpdGggc2V2ZXJhbCBvZiB0aGVtJm5ic3A7YmVpbmcgaW4gdGhlIHBhc3Qu Jm5ic3A7QWZ0ZXIgcmV2aWV3aW5nIHRoZSBzdGF0ZSBvZiB0aGUgd29yaywgdGhlIGNoYWlycyBw cm9wb3NlIHRvIHJldmlzZSB0aGUgZ3JvdXDigJlzIG1pbGVzdG9uZXMgYXMgZm9sbG93czo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8dWwgY2xhc3M9Ik1haWxPdXRsaW5lIj4NCjxsaSBj bGFzcz0iIj5TdWJtaXQgY29uZ2VzdGlvbiBjb250cm9sIHRvIElFU0cgZm9yIFByb3Bvc2VkIFN0 YW5kYXJkIDxpIGNsYXNzPSIiPg0KKE9jdCAyMDE2IOKGkiBOb3YgMjAxOCk8L2k+PC9saT48bGkg Y2xhc3M9IiI+U3VibWl0IHRlY2huaXF1ZXMgdG8gZGV0ZWN0LCBpbnN0cnVtZW50IG9yIGRpYWdu b3NlIGZhaWxpbmcgdG8gbWVldCBSVCZuYnNwO3NjaGVkdWxlcyB0byBJRVNHIGFzIEluZm9ybWF0 aW9uYWwNCjxpIGNsYXNzPSIiPihKdW4gMjAxNiZuYnNwOzxpIGNsYXNzPSIiPuKGkjwvaT4mbmJz cDtKdWwgMjAxOCk8L2k+PC9saT48bGkgY2xhc3M9IiI+UHVibGlzaCBmaXJzdCBkcmFmdCBvZiB0 ZWNobmlxdWVzIHRvIGRldGVjdCwgaW5zdHJ1bWVudCBvciBkaWFnbm9zZSZuYnNwO2ZhaWxpbmcg dG8gbWVldCBSVCBzY2hlZHVsZXMNCjxpIGNsYXNzPSIiPihGZWIgMjAxNiZuYnNwOzxpIGNsYXNz PSIiPuKGkjwvaT4mbmJzcDtNYXIgMjAxOCk8L2k+PC9saT48bGkgY2xhc3M9IiI+UHVibGlzaCBm aXJzdCBkcmFmdCBvZiBTdGFuZGFyZHMgVHJhY2sgY29uZ2VzdGlvbiZuYnNwO2NvbnRyb2wgYWxn b3JpdGhtIDxpIGNsYXNzPSIiPg0KKEZlYiAyMDE2Jm5ic3A7PGkgY2xhc3M9IiI+4oaSPC9pPiZu YnNwO01hciAyMDE4KTwvaT48L2xpPjxsaSBjbGFzcz0iIj5QdWJsaXNoIGZpcnN0IGRyYWZ0IG9m IGV2YWx1YXRpb24gcmVzdWx0cyA8aSBjbGFzcz0iIj4oRmViIDIwMTYgLSZndDsgTWFyIDIwMTgp PC9pPjwvbGk+PGxpIGNsYXNzPSIiPlN1Ym1pdCByZXF1aXJlbWVudHMgYW5kIGV2YWx1YXRpb24g Y3JpdGVyaWEgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsICZuYnNwOzxpIGNsYXNzPSIiPihEZWMg MjAxNSZuYnNwOzxpIGNsYXNzPSIiPuKGkjwvaT4mbmJzcDtBdWcgMjAxNykg4oCTIHRoaXMgaXMg ZHJhZnQtaWV0Zi1ybWNhdC1jYy1yZXF1aXJlbWVudHMgYW5kIGRyYWZ0LWlldGYtcm1jYXQtZXZh bC1jcml0ZXJpYTwvaT48L2xpPjxsaSBjbGFzcz0iIj5TdWJtaXQgUlRDUCBleHRlbnNpb24gcmVx dWlyZW1lbnRzIGZvciB1c2Ugd2l0aCBjb25nZXN0aW9uIGNvbnRyb2wmbmJzcDthbGdvcml0aG1z IHRvIEFWVENPUkUgKGlmIG5lZWRlZCkNCjxpIGNsYXNzPSIiPihEZWMgMjAxNSZuYnNwOzxpIGNs YXNzPSIiPuKGkjwvaT4mbmJzcDtBdWcgMjAxNykg4oCTIHRoaXMgaXMgdGhlIGRlc2lnbiB0ZWFt IG91dHB1dDwvaT48L2xpPjxsaSBjbGFzcz0iIj5TdWJtaXQgaW50ZXJhY3Rpb25zIGJldHdlZW4g YXBwbGljYXRpb25zIGFuZCBSVFAgZmxvd3MgdG8gSUVTRyBhcyZuYnNwO0luZm9ybWF0aW9uYWwN CjxpIGNsYXNzPSIiPihEZWMgMjAxNSZuYnNwOzxpIGNsYXNzPSIiPuKGkjwvaT4mbmJzcDtNYXIg MjAxOCk8L2k+PC9saT48bGkgY2xhc3M9IiI+U3VibWl0IGZpcnN0IGNvbmdlc3Rpb24gY29udHJv bCBjYW5kaWRhdGUgdG8gSUVTRyBmb3IgRXhwZXJpbWVudGFsJm5ic3A7cHVibGljYXRpb24mbmJz cDs8aSBjbGFzcz0iIj4oRGVjIDIwMTUmbmJzcDs8aSBjbGFzcz0iIj7ihpI8L2k+Jm5ic3A7QXBy IDIwMTcpIOKAkyB0aGlzIGlzIFNDUmVBTSwgc2hvcnRseSBmb2xsb3dlZCBieSBOQURBPC9pPjwv bGk+PGxpIGNsYXNzPSIiPlN1Ym1pdCBpZGVudGlmeWluZyBhbmQgY29udHJvbGxpbmcgZ3JvdXBz IG9mIGZsb3dzIHRvIElFU0cgZm9yJm5ic3A7RXhwZXJpbWVudGFsIHB1YmxpY2F0aW9uDQo8aSBj bGFzcz0iIj4oRGVjIDIwMTUmbmJzcDs8aSBjbGFzcz0iIj7ihpI8L2k+Jm5ic3A7QXByIDIwMTcp IOKAkyB0aGlzIGlzIGRyYWZ0LWlldGYtcm1jYXQtY291cGxlZC1jYyBhbmQgZHJhZnQtaWV0Zi1y bWNhdC1zYmQ8L2k+PC9saT48L3VsPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IndlYmtpdC1i bG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QmVmb3JlIHdlIGRvIHRo aXMsIHdl4oCZZCBhcHByZWNpYXRlIGNvbW1lbnRzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgb24g dGhpcyBwcm9wb3NhbCwgYW5kIHdoZXRoZXIgdGhlIHN1Z2dlc3RlZCBtaWxlc3RvbmVzIHNlZW0g cmVhc29uYWJsZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MsPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkNvbGluIChmb3IgdGhlIFdHIGNvLWNoYWlycyk8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQotLSZuYnNwOzxiciBjbGFzcz0i Ij4NCkNvbGluIFBlcmtpbnM8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2NzcGVya2lu cy5vcmcvIiBjbGFzcz0iIj5odHRwczovL2NzcGVya2lucy5vcmcvPC9hPjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D4FD65F919C40zaheduzzamansarkerericssoncom_-- From nobody Sun Mar 26 04:24:43 2017 Return-Path: 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 2F2D4129531 for ; Sun, 26 Mar 2017 04:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 PSwBvpir3bvV for ; Sun, 26 Mar 2017 04:24:40 -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 485C81243FE for ; Sun, 26 Mar 2017 04:24:40 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cs6Hm-0005qa-M7 for rmcat@ietf.org; Sun, 26 Mar 2017 13:24:38 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cs6Hl-000Al3-Q0; Sun, 26 Mar 2017 13:24:38 +0200 From: Michael Welzl Message-Id: <0AFACAAE-DC18-4D7A-B222-F65FCE5DE093@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_FB2D7FCB-8C9C-49A7-9C3B-97F0E0027B7B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 26 Mar 2017 06:24:36 -0500 In-Reply-To: Cc: "rmcat WG (rmcat@ietf.org)" To: Colin Perkins References: X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 3 sum rcpts/h 14 sum msgs/h 5 total rcpts 53198 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.001, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B6B16DB38DE7D4C734ACF3534F5079AFF4B65C11 X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 16 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [rmcat] Proposal for revised RMCAT milestones X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 11:24:42 -0000 --Apple-Mail=_FB2D7FCB-8C9C-49A7-9C3B-97F0E0027B7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The update looks reasonable to me. However, I just noticed a discrepancy = between the milestones and the charter. The charter says, under = Deliverables: "- Identifying and controlling groups of flows as a = Proposed Standard RFC=E2=80=9D but there doesn=E2=80=99t seem to be a = milestone matching this deliverable. Cheers, Michael > On Mar 24, 2017, at 6:21 PM, Colin Perkins wrote: >=20 > WG, >=20 > The working group=E2=80=99s milestones are outdated, with several of = them being in the past. After reviewing the state of the work, the = chairs propose to revise the group=E2=80=99s milestones as follows: >=20 > Submit congestion control to IESG for Proposed Standard (Oct 2016 =E2=86= =92 Nov 2018) > Submit techniques to detect, instrument or diagnose failing to meet RT = schedules to IESG as Informational (Jun 2016 =E2=86=92 Jul 2018) > Publish first draft of techniques to detect, instrument or diagnose = failing to meet RT schedules (Feb 2016 =E2=86=92 Mar 2018) > Publish first draft of Standards Track congestion control algorithm = (Feb 2016 =E2=86=92 Mar 2018) > Publish first draft of evaluation results (Feb 2016 -> Mar 2018) > Submit requirements and evaluation criteria to IESG as Informational = (Dec 2015 =E2=86=92 Aug 2017) =E2=80=93 this is = draft-ietf-rmcat-cc-requirements and draft-ietf-rmcat-eval-criteria > Submit RTCP extension requirements for use with congestion control = algorithms to AVTCORE (if needed) (Dec 2015 =E2=86=92 Aug 2017) =E2=80=93 = this is the design team output > Submit interactions between applications and RTP flows to IESG as = Informational (Dec 2015 =E2=86=92 Mar 2018) > Submit first congestion control candidate to IESG for Experimental = publication (Dec 2015 =E2=86=92 Apr 2017) =E2=80=93 this is SCReAM, = shortly followed by NADA > Submit identifying and controlling groups of flows to IESG for = Experimental publication (Dec 2015 =E2=86=92 Apr 2017) =E2=80=93 this is = draft-ietf-rmcat-coupled-cc and draft-ietf-rmcat-sbd >=20 > Before we do this, we=E2=80=99d appreciate comments from the working = group on this proposal, and whether the suggested milestones seem = reasonable. >=20 > Thanks, > Colin (for the WG co-chairs) >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 --Apple-Mail=_FB2D7FCB-8C9C-49A7-9C3B-97F0E0027B7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

The = update looks reasonable to me. However, I just noticed a discrepancy = between the milestones and the charter. The charter says, under = Deliverables: "- Identifying and controlling groups of flows as a = Proposed Standard RFC=E2=80=9D  but there doesn=E2=80=99t seem to = be a milestone matching this deliverable.

Cheers,
Michael


On Mar 24, 2017, at 6:21 PM, Colin Perkins <csp@csperkins.org> = wrote:

WG,

The working group=E2=80=99s milestones are outdated, with = several of them being in the past. After reviewing the state = of the work, the chairs propose to revise the group=E2=80=99s milestones = as follows:

  • Submit congestion control to IESG for Proposed Standard (Oct 2016 =E2=86=92 Nov 2018)
  • Submit = techniques to detect, instrument or diagnose failing to meet = RT schedules to IESG as Informational (Jun = 2016 =E2=86=92 Jul 2018)
  • Publish first draft of techniques to detect, instrument or = diagnose failing to meet RT schedules (Feb = 2016 =E2=86=92 Mar 2018)
  • Publish first draft of Standards Track = congestion control algorithm (Feb 2016 =E2=86=92 Mar 2018)
  • Publish = first draft of evaluation results (Feb 2016 -> Mar = 2018)
  • Submit requirements and evaluation criteria = to IESG as Informational  (Dec 2015 =E2=86=92 Aug 2017) =E2=80=93 this is = draft-ietf-rmcat-cc-requirements and = draft-ietf-rmcat-eval-criteria
  • Submit RTCP = extension requirements for use with congestion control algorithms = to AVTCORE (if needed) (Dec 2015 =E2=86=92 Aug 2017) =E2=80=93 this is the design = team output
  • Submit interactions between = applications and RTP flows to IESG as Informational (Dec 2015 =E2=86=92 Mar = 2018)
  • Submit first congestion control candidate = to IESG for Experimental publication (Dec = 2015 =E2=86=92 Apr 2017) =E2=80=93 this is = SCReAM, shortly followed by NADA
  • Submit = identifying and controlling groups of flows to IESG = for Experimental publication (Dec 2015 =E2=86=92 Apr 2017) =E2=80=93 this is = draft-ietf-rmcat-coupled-cc and draft-ietf-rmcat-sbd

Before we do this, we=E2=80=99d appreciate comments from the = working group on this proposal, and whether the suggested milestones = seem reasonable.

Thanks,
Colin (for the WG co-chairs)



-- 
Colin Perkins
https://csperkins.org/





= --Apple-Mail=_FB2D7FCB-8C9C-49A7-9C3B-97F0E0027B7B-- From nobody Sun Mar 26 10:59:58 2017 Return-Path: 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 895A512966F; Sun, 26 Mar 2017 10:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 ihvSYVN3Nmif; Sun, 26 Mar 2017 10:59:54 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6887129650; Sun, 26 Mar 2017 10:59:54 -0700 (PDT) Received: from [81.187.2.149] (port=44959 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1csCSG-0002hs-Q1; Sun, 26 Mar 2017 18:59:53 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Colin Perkins In-Reply-To: <5CD82FB1-C38E-475B-9C3A-C7C61EAEEE04@ifi.uio.no> Date: Sun, 26 Mar 2017 18:59:48 +0100 Cc: rmcat WG , draft-ietf-rmcat-coupled-cc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <148111854325.13729.9946710085994858033.idtracker@ietfa.amsl.com> <66C087EE-823A-43C9-8E8B-A2364FD6511B@csperkins.org> <79DC47FB-2032-444C-9654-A0A87F93CC18@csperkins.org> <0A54D20B-45D0-41F6-AAAD-923A60F6C285@csperkins.org> <9DCBD472-DFFF-43CF-BBDC-6241BEA2C67A@ifi.uio.no> <111EB839-EC1B-4DCA-AC85-5AE63C21E812@csperkins.org> <5CD82FB1-C38E-475B-9C3A-C7C61EAEEE04@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 17:59:56 -0000 > On 25 Mar 2017, at 05:53, Michael Welzl wrote: >=20 > Thanks! >=20 > This is actually there but too weakly qualified: >=20 > *** > a priority P(f), which here is assumed to be represented as a > positive number within a fixed range. > *** >=20 > Suggest to change to: >=20 > *** > a priority P(f), which is a positive number within a fixed range. > *** I=E2=80=99d suggest =E2=80=9Cwhich is a positive number, greater than = zero=E2=80=9D to be clear zero is excluded.=20 Also =E2=80=9Cwithin a fixed range=E2=80=9D - what=E2=80=99s the range? = It might be okay to remove this part. Cheers, Colin --=20 Colin Perkins https://csperkins.org/ From nobody Sun Mar 26 11:56:16 2017 Return-Path: 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 92EF112949A for ; Sun, 26 Mar 2017 11:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 OT4q9iuMCiXj for ; Sun, 26 Mar 2017 11:56:13 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 7DBE4129497 for ; Sun, 26 Mar 2017 11:56:13 -0700 (PDT) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1csDKl-000Gx2-6Z for rmcat@ietf.org; Sun, 26 Mar 2017 20:56:11 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1csDKk-0000Jd-7d; Sun, 26 Mar 2017 20:56:11 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: Date: Sun, 26 Mar 2017 13:56:07 -0500 Cc: rmcat WG , draft-ietf-rmcat-coupled-cc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <148111854325.13729.9946710085994858033.idtracker@ietfa.amsl.com> <66C087EE-823A-43C9-8E8B-A2364FD6511B@csperkins.org> <79DC47FB-2032-444C-9654-A0A87F93CC18@csperkins.org> <0A54D20B-45D0-41F6-AAAD-923A60F6C285@csperkins.org> <9DCBD472-DFFF-43CF-BBDC-6241BEA2C67A@ifi.uio.no> <111EB839-EC1B-4DCA-AC85-5AE63C21E812@csperkins.org> <5CD82FB1-C38E-475B-9C3A-C7C61EAEEE04@ifi.uio.no> To: Colin Perkins X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 7 sum msgs/h 4 total rcpts 53213 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.1, required=5.0, autolearn=disabled, AWL=-0.118, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1EAD528EAD709A40F943139101841AEE3911F4A8 X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -50 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 31 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 18:56:15 -0000 > On Mar 26, 2017, at 12:59 PM, Colin Perkins wrote: >=20 >=20 >> On 25 Mar 2017, at 05:53, Michael Welzl wrote: >>=20 >> Thanks! >>=20 >> This is actually there but too weakly qualified: >>=20 >> *** >> a priority P(f), which here is assumed to be represented as a >> positive number within a fixed range. >> *** >>=20 >> Suggest to change to: >>=20 >> *** >> a priority P(f), which is a positive number within a fixed range. >> *** >=20 >=20 > I=E2=80=99d suggest =E2=80=9Cwhich is a positive number, greater than = zero=E2=80=9D to be clear zero is excluded.=20 Ok with me. > Also =E2=80=9Cwithin a fixed range=E2=80=9D - what=E2=80=99s the = range? It might be okay to remove this part. Ok Cheers, Michael From nobody Sun Mar 26 23:03:46 2017 Return-Path: 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 0DE841274D0; Sun, 26 Mar 2017 23:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 s4SOhL7Epvpd; Sun, 26 Mar 2017 23:03:43 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191861293DA; Sun, 26 Mar 2017 22:58:38 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id u1so39196744wra.2; Sun, 26 Mar 2017 22:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Oa0Y80SEED3mTQM5Sb7JywoLH7IlqxATtZJCnRq8Ziw=; b=CifFROX0BKh9w8dGmD98hA8pR1E6392QrMIh92uDymjluJIGWQ6fYyuhdEPtaiN7yj auaHpSQH13QtAiTOutEC3asdIFaWtozUlfXR29BEa5z8e68Ud5OKL3bXze9F3UHFQkbt gwuBKS4N/KlMZrbCNfySXKvDV1I6cAr0AK9DSVzAZSEyrj+Lm3+Ua1Z10wJnqvef16V3 tDE8gfQWwnxb1pzFmZkxQahKiqVhjdh12cUT93YQ6cZbwb5R78RX+M8oNaXnxbqi8Mv7 sOS5WijZXljcfIJsd2t4KkbTWMDIrpfvl33JILUbdIaVg/n8wPH4MUlWEeRZFI8M6U01 CGWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Oa0Y80SEED3mTQM5Sb7JywoLH7IlqxATtZJCnRq8Ziw=; b=cF0/Rw7DHp4J5f+S2iGDSYF+b9Ln08I5J3cURbF/pI7YpvmNT88+Q45J28SPNo9SJF yGnG9Wikd2tinXszyRSf5T5H3ukWEOmSN7YTZldaCFlZmP6RNf4JxrFFYZoTM5oYXgok gavncN+1egWWapKrrQFniGVXpNxbZN2aTXATAOIT7b/t25muselLbD366E2C40QtsucL P6KCts2LQEo6z8+F9u324vM9JxRxNLAkMZlnqAJUs/EH8309v+oGuqZWxqGkMnkEZaam lmz+Juwdf9jaCel8IpshqvADQkjcHklwrm636Pt38NzdgrycEjrFGhkGJrC+HK/DKCIa 8sjg== X-Gm-Message-State: AFeK/H19iIY4oN1FDSg99WMwcIoD7DbHGgBf/AfXYIfgHhB4Hv8FVIhqGL08ugIWx2RObQ== X-Received: by 10.223.160.183 with SMTP id m52mr1498539wrm.201.1490594316362; Sun, 26 Mar 2017 22:58:36 -0700 (PDT) Received: from mn-mn0F-2.local ([2a01:598:89c3:9fc3:690f:2515:3d51:4bee]) by smtp.googlemail.com with ESMTPSA id l70sm7227705wrc.40.2017.03.26.22.58.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 22:58:35 -0700 (PDT) To: Ingemar Johansson S , "rmcat WG (rmcat@ietf.org)" References: <6adc065d-49a6-37f3-4dea-407d2a81b6d1@gmail.com> Cc: "draft-ietf-rmcat-scream-cc@ietf.org" From: Martin Stiemerling Message-ID: Date: Mon, 27 Mar 2017 07:58:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 06:03:45 -0000 Hi Ingemar, all, Am 16.03.17 um 15:36 schrieb Ingemar Johansson S: > Hi > > Thanks for the review, comments inline. > > /Ingemar > >> -----Original Message----- From: Martin Stiemerling >> [mailto:mls.ietf@gmail.com] Sent: den 15 mars 2017 10:18 To: rmcat >> WG (rmcat@ietf.org) Subject: [rmcat] Shepherd >> review of draft-ietf-rmcat-scream-cc-07 [...] >> >> b) This is a bigger issue: The draft specifies a number of protocol >> behaviors, but is never using any of the RFC 2119 keywords. While >> not using the RFC 2119 keywords is acceptable for an experimental >> draft it is troublesome on the long run. The intention is for sure >> to move this draft to standards track, once the experimental phase >> is over. However, at this later stage RFC 2119 key words will be >> required. > [IJ] OK, yes. This can take a few hours to fix, should not be too > troublesome, I hope. I had worse issues with rfc6236 as the RFC2119 > keywords had to be chosen carefully in light of existing SDP and SIP > specs. This one should be more simple, I hope. Ok, I will wait for the updated version. > >> >> c) a bit of work, but easily fixable. > [IJ] OK > >> >> Other comments beyond idnits: >> >> - Section 4.1.1.1: It says that the constantns are deduced from >> experiments. In what context have these experiments been specified, >> carried out and documented? Is this something you can refer you? >> The current text is a bit underspecified in that respect. > [IJ] There are experiments results presented at the RMCAT meetings, > last time was in Berlin > (https://www.ietf.org/proceedings/96/slides/slides-96-rmcat-0.pdf ), > It is possible that I can present new results soon. Question is in > which form should the results be presented ?. Is material presented > at RMCAT sufficient. A reference to this would be just good! > >> >> - Section 4.1.1.1, page 10, bottom: " TARGET_BITRATE_MIN Min target >> bitrate [bps]. >> >> TARGET_BITRATE_MAX Max target bitrate [bps]. " >> >> I assume that the notion [bps] shall introduce the unit of this >> constant. Please specify that this is the notion you are using for >> specifying the unit. > [IJ] If I understand it correct you mean that I should specify that > [bps] indicate the unit "bits per second", right ? Yes, and also introducing that the notation of "[]" in this case means a statement of the unit to be used. > >> >> >> - Section 9. IANA Considerations: This is not section for IANA but >> more a question for the WG. Please remove the text from this >> section and place it in a new section "Open Issues" or similar. >> There is currently no request to IANA. Please state just this and >> the request to remove the section before publication as RFC. > [IJ] OK > >> >> - Appendix A.4 looks like a regular section, with the note that >> this is an experimental version and needs further vetting during >> the experimentation period, isn't it? > [IJ] Yes. The proposed feedback while waiting for some kind of > generic feedback, this is the best one can do with existing > standardized feedback. The feedback intensity is verified in > simulator over a large range of bitrates, and also verified in an > experimental testbed for a high quality video solution over LTE/5G. > The objective has been to ensure a feedback rate that is not overly > high and that at the same time does not limit throughput. It is not > ruled out that the equations in section A.4.2 may change during the > experimentation period. How about adding at the top of A.4 what you replied to me, at least roughly? This will help to get other reviews a better understanding. Thank you, Martin From nobody Mon Mar 27 08:01:57 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59519120725; Mon, 27 Mar 2017 08:01:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149062691533.30533.9787224454293771176@ietfa.amsl.com> Date: Mon, 27 Mar 2017 08:01:55 -0700 Archived-At: Subject: [rmcat] I-D Action: draft-ietf-rmcat-nada-04.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 15:01:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques of the IETF. Title : NADA: A Unified Congestion Control Scheme for Real-Time Media Authors : Xiaoqing Zhu Rong Pan Michael A. Ramalho Sergio Mena de la Cruz Paul E. Jones Jiantao Fu Stefano D'Aronco Filename : draft-ietf-rmcat-nada-04.txt Pages : 25 Date : 2017-03-27 Abstract: This document describes NADA (network-assisted dynamic adaptation), a novel congestion control scheme for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays and packet losses instead. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rmcat-nada-04 https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-nada-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-nada-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 08:06:46 2017 Return-Path: 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 4772F12975C for ; Mon, 27 Mar 2017 08:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Or-8EK9sWgvC for ; Mon, 27 Mar 2017 08:06:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC7912971E for ; Mon, 27 Mar 2017 08:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3150; q=dns/txt; s=iport; t=1490627179; x=1491836779; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SB3134yIjpolwERWT9zOMiwO75eGQ0sch8cXQO5Ed9o=; b=kniKpToAE4sqAlyafNn7IKHBnKa0HxRv0FbI1nGUDklm6EmbqTzWadKi eDlPDfAe5Q00kAGWgjZHmqaXXoyup3oc790Jk2upocuAx69tFWj2topNO FmHlC1K96HoJ9vltMdHUo8qAGdetkPnk5oRiKKiBxfnUO6DIC9BPs4bKk k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAQB+KdlY/4QNJK1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1RhgQsHhieHQ5FNhAEBA5FGgg4qhXgCgxU/GAECAQEBAQEBAWsdC4UVAQE?= =?us-ascii?q?BAQNuGwIBCBEEAQEKJQ8jGwIIAgQTigcOrgKKPgEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAR2GToRvgxeHIgWQIYw6AYZ6hlGFAIF8GDyEVooLk2QBHziBBFkVGCmGWHW?= =?us-ascii?q?IKIENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,232,1486425600"; d="scan'208";a="223534812" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Mar 2017 15:06:18 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v2RF6IJw007281 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Mar 2017 15:06:18 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 10:06:18 -0500 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1210.000; Mon, 27 Mar 2017 10:06:17 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "rmcat@ietf.org" Thread-Topic: [rmcat] I-D Action: draft-ietf-rmcat-nada-04.txt Thread-Index: AQHSpwseahGbhWICBUiEuh8ac5UCtaGoyKsl Date: Mon, 27 Mar 2017 15:06:17 +0000 Message-ID: <1490627177948.50532@cisco.com> References: <149062691533.30533.9787224454293771176@ietfa.amsl.com> In-Reply-To: <149062691533.30533.9787224454293771176@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.152.244.94] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [rmcat] Fw: I-D Action: draft-ietf-rmcat-nada-04.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 15:06:27 -0000 Hi, =0A= =0A= The draft of NADA has been updated to version -04. Please see link below. = =0A= =0A= The content changes are fairly minor, including: =0A= * Cleaned up notational confusion for the non-linear warping operation in S= ec. 4.2=0A= * Removed the editor's notice regarding whether to discuss the start value = of the rate in Sec. 6.3 (will ask that question on the mailing list instead= ).=0A= * Added one more experiment scenario (over WAN connections) in Sec. 8=0A= =0A= We have also moved one of the earlier contributors to this work from co-aut= hor to our list of acknowledgement. =0A= =0A= With this, the draft is ready for WGLC. =0A= =0A= Thanks,=0A= Xiaoqing=0A= =0A= ________________________________________=0A= From: rmcat on behalf of internet-drafts@ietf.org = =0A= Sent: Monday, March 27, 2017 10:01 AM=0A= To: i-d-announce@ietf.org=0A= Cc: rmcat@ietf.org=0A= Subject: [rmcat] I-D Action: draft-ietf-rmcat-nada-04.txt=0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= This draft is a work item of the RTP Media Congestion Avoidance Techniques = of the IETF.=0A= =0A= Title : NADA: A Unified Congestion Control Scheme for Rea= l-Time Media=0A= Authors : Xiaoqing Zhu=0A= Rong Pan=0A= Michael A. Ramalho=0A= Sergio Mena de la Cruz=0A= Paul E. Jones=0A= Jiantao Fu=0A= Stefano D'Aronco=0A= Filename : draft-ietf-rmcat-nada-04.txt=0A= Pages : 25=0A= Date : 2017-03-27=0A= =0A= Abstract:=0A= This document describes NADA (network-assisted dynamic adaptation), a=0A= novel congestion control scheme for interactive real-time media=0A= applications, such as video conferencing. In the proposed scheme,=0A= the sender regulates its sending rate based on either implicit or=0A= explicit congestion signaling, in a unified approach. The scheme can=0A= benefit from explicit congestion notification (ECN) markings from=0A= network nodes. It also maintains consistent sender behavior in the=0A= absence of such markings, by reacting to queuing delays and packet=0A= losses instead.=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/=0A= =0A= There are also htmlized versions available at:=0A= https://tools.ietf.org/html/draft-ietf-rmcat-nada-04=0A= https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-nada-04=0A= =0A= A diff from the previous version is available at:=0A= https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-nada-04=0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= From nobody Tue Mar 28 06:02:50 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A82F11299BC; Tue, 28 Mar 2017 06:02:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149070616465.30521.13205282250119884347@ietfa.amsl.com> Date: Tue, 28 Mar 2017 06:02:44 -0700 Archived-At: Subject: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-06.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 13:02:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques of the IETF. Title : Coupled congestion control for RTP media Authors : Safiqul Islam Michael Welzl Stein Gjessing Filename : draft-ietf-rmcat-coupled-cc-06.txt Pages : 26 Date : 2017-03-28 Abstract: When multiple congestion controlled RTP sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. It specifies how to apply the method for the NADA congestion control algorithm, and provides suggestions on how to apply it to other congestion control algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rmcat-coupled-cc-06 https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-coupled-cc-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-coupled-cc-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 28 06:14:51 2017 Return-Path: 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 5C0BB1299D3 for ; Tue, 28 Mar 2017 06:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 foHQ6vW-q-Vg for ; Tue, 28 Mar 2017 06:14:47 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 F3EAE129983 for ; Tue, 28 Mar 2017 06:14:46 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1csqxR-0003VQ-CR for rmcat@ietf.org; Tue, 28 Mar 2017 15:14:45 +0200 Received: from mail-ex01.exprod.uio.no ([129.240.52.4]) by mail-mx04.uio.no with esmtps (TLSv1.2:AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1csqxQ-0008JK-3H for rmcat@ietf.org; Tue, 28 Mar 2017 15:14:45 +0200 Received: from mail-ex04.exprod.uio.no (2001:700:100:52::7) by mail-ex01.exprod.uio.no (2001:700:100:52::4) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 28 Mar 2017 15:14:43 +0200 Received: from mail-ex04.exprod.uio.no ([fe80::5da2:f347:6a4b:effc]) by mail-ex04.exprod.uio.no ([fe80::5da2:f347:6a4b:effc%19]) with mapi id 15.00.1236.000; Tue, 28 Mar 2017 15:14:43 +0200 From: Safiqul Islam To: "rmcat@ietf.org WG" CC: Michael Welzl , Stein Gjessing Thread-Topic: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-06.txt Thread-Index: AQHSp8OqgM9j1N+r1EqUxiYfZDJUWg== Date: Tue, 28 Mar 2017 13:14:42 +0000 Message-ID: <76E12E4D-9E0C-43B3-B30A-C4E7C6A69909@ifi.uio.no> References: <149070616465.30521.13205282250119884347@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: multipart/alternative; boundary="_000_76E12E4D9E0C43B3B30AC4E7C6A69909ifiuiono_" MIME-Version: 1.0 X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 129.240.52.4 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.52.4; envelope-from=safiquli@ifi.uio.no; helo=mail-ex01.exprod.uio.no; X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 1 sum msgs/h 1 total rcpts 2903 max rcpts/h 24 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-1.6, required=5.0, autolearn=disabled, AWL=0.083, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.652, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6D0CEE87FAC301DCBAA640BD17AA28D002B6C977 X-UiO-SPAM-Test: remote_host: 129.240.52.4 spam_score: -15 maxlevel 80 minaction 2 bait 0 mail/h: 101 total 2252657 max/h 2487 blacklist 0 greylist 0 ratelimit 0 X-UiOonly: 8F8C88A0982CEDEBFCD7D494018F78669BE27914 Archived-At: Subject: [rmcat] Fwd: I-D Action: draft-ietf-rmcat-coupled-cc-06.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 13:14:50 -0000 --_000_76E12E4D9E0C43B3B30AC4E7C6A69909ifiuiono_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpKRllJOiB3ZSBoYXZlIG5vdyBpbmNvcnBvcmF0ZWQgQ29saW7igJlzIGNvbW1l bnRzLg0KDQpSZWdhcmRzLA0KU2FmaXF1bA0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0K DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFtybWNhdF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ybWNhdC1j b3VwbGVkLWNjLTA2LnR4dA0KRGF0ZTogMjggTWFyY2ggMjAxNyBhdCAxNTowMjo0NCBHTVQrMg0K VG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4+ DQpDYzogcm1jYXRAaWV0Zi5vcmc8bWFpbHRvOnJtY2F0QGlldGYub3JnPg0KDQoNCkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFJUUCBNZWRp YSBDb25nZXN0aW9uIEF2b2lkYW5jZSBUZWNobmlxdWVzIG9mIHRoZSBJRVRGLg0KDQogICAgICAg VGl0bGUgICAgICAgICAgIDogQ291cGxlZCBjb25nZXN0aW9uIGNvbnRyb2wgZm9yIFJUUCBtZWRp YQ0KICAgICAgIEF1dGhvcnMgICAgICAgICA6IFNhZmlxdWwgSXNsYW0NCiAgICAgICAgICAgICAg ICAgICAgICAgICBNaWNoYWVsIFdlbHpsDQogICAgICAgICAgICAgICAgICAgICAgICAgU3RlaW4g R2plc3NpbmcNCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtcm1jYXQtY291cGxlZC1jYy0w Ni50eHQNClBhZ2VzICAgICAgICAgICA6IDI2DQpEYXRlICAgICAgICAgICAgOiAyMDE3LTAzLTI4 DQoNCkFic3RyYWN0Og0KICBXaGVuIG11bHRpcGxlIGNvbmdlc3Rpb24gY29udHJvbGxlZCBSVFAg c2Vzc2lvbnMgdHJhdmVyc2UgdGhlIHNhbWUNCiAgbmV0d29yayBib3R0bGVuZWNrLCBjb21iaW5p bmcgdGhlaXIgY29udHJvbHMgY2FuIGltcHJvdmUgdGhlIHRvdGFsDQogIG9uLXRoZS13aXJlIGJl aGF2aW9yIGluIHRlcm1zIG9mIGRlbGF5LCBsb3NzIGFuZCBmYWlybmVzcy4gIFRoaXMNCiAgZG9j dW1lbnQgZGVzY3JpYmVzIHN1Y2ggYSBtZXRob2QgZm9yIGZsb3dzIHRoYXQgaGF2ZSB0aGUgc2Ft ZSBzZW5kZXIsDQogIGluIGEgd2F5IHRoYXQgaXMgYXMgZmxleGlibGUgYW5kIHNpbXBsZSBhcyBw b3NzaWJsZSB3aGlsZSBtaW5pbWl6aW5nDQogIHRoZSBhbW91bnQgb2YgY2hhbmdlcyBuZWVkZWQg dG8gZXhpc3RpbmcgUlRQIGFwcGxpY2F0aW9ucy4gIEl0DQogIHNwZWNpZmllcyBob3cgdG8gYXBw bHkgdGhlIG1ldGhvZCBmb3IgdGhlIE5BREEgY29uZ2VzdGlvbiBjb250cm9sDQogIGFsZ29yaXRo bSwgYW5kIHByb3ZpZGVzIHN1Z2dlc3Rpb25zIG9uIGhvdyB0byBhcHBseSBpdCB0byBvdGhlcg0K ICBjb25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtcy4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm1jYXQtY291cGxlZC1jYy8NCg0KVGhlcmUgYXJlIGFsc28g aHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtcm1jYXQtY291cGxlZC1jYy0wNg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXJtY2F0LWNvdXBsZWQtY2MtMDYNCg0KQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcm1jYXQtY291cGxlZC1jYy0wNg0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQoNCg0K --_000_76E12E4D9E0C43B3B30AC4E7C6A69909ifiuiono_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLA0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SkZZSTogd2UgaGF2ZSBub3cg aW5jb3Jwb3JhdGVkIENvbGlu4oCZcyBjb21tZW50cy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+UmVnYXJkcyw8YnIgY2xhc3M9IiI+DQpTYWZpcXVsPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+QmVnaW4gZm9yd2Fy ZGVkIG1lc3NhZ2U6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2lu LWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNs YXNzPSIiPkZyb206DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtp dC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIGNsYXNzPSIi PmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4t Ym90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgY29sb3I6cmdiYSgwLCAwLCAwLCAxLjApOyIgY2xhc3M9IiI+PGIgY2xh c3M9IiI+U3ViamVjdDoNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+PGIgY2xhc3M9IiI+W3JtY2F0XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJtY2F0 LWNvdXBsZWQtY2MtMDYudHh0PC9iPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206 IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5E YXRlOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVt LWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4y OCBNYXJjaCAyMDE3IGF0IDE1OjAyOjQ0IEdNVCYjNDM7MjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1h cmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48 YiBjbGFzcz0iIj5UbzoNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIGNsYXNz PSIiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxi IGNsYXNzPSIiPkNjOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJr aXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj48YSBocmVmPSJtYWlsdG86cm1jYXRAaWV0Zi5vcmciIGNsYXNzPSIiPnJtY2F0QGll dGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy48YnIgY2xhc3M9IiI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBS VFAgTWVkaWEgQ29uZ2VzdGlvbiBBdm9pZGFuY2UgVGVjaG5pcXVlcyBvZiB0aGUgSUVURi48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtUaXRsZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs6IENvdXBsZWQgY29uZ2VzdGlvbiBjb250cm9sIGZvciBSVFAg bWVkaWE8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtBdXRob3JzICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzogU2FmaXF1bCBJc2xhbTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO01pY2hhZWwgV2Vsemw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtTdGVpbiBHamVzc2luZzxiciBjbGFzcz0iIj4NCjxzcGFuIGNs YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkZpbGVu YW1lICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogZHJhZnQtaWV0 Zi1ybWNhdC1jb3VwbGVkLWNjLTA2LnR4dDxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBs ZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPlBhZ2VzICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjY8 YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1z cGFjZTpwcmUiPjwvc3Bhbj5EYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjAxNy0wMy0yODxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1doZW4g bXVsdGlwbGUgY29uZ2VzdGlvbiBjb250cm9sbGVkIFJUUCBzZXNzaW9ucyB0cmF2ZXJzZSB0aGUg c2FtZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO25ldHdvcmsgYm90dGxlbmVjaywgY29tYmlu aW5nIHRoZWlyIGNvbnRyb2xzIGNhbiBpbXByb3ZlIHRoZSB0b3RhbDxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwO29uLXRoZS13aXJlIGJlaGF2aW9yIGluIHRlcm1zIG9mIGRlbGF5LCBsb3NzIGFu ZCBmYWlybmVzcy4gJm5ic3A7VGhpczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2RvY3VtZW50 IGRlc2NyaWJlcyBzdWNoIGEgbWV0aG9kIGZvciBmbG93cyB0aGF0IGhhdmUgdGhlIHNhbWUgc2Vu ZGVyLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2luIGEgd2F5IHRoYXQgaXMgYXMgZmxleGli bGUgYW5kIHNpbXBsZSBhcyBwb3NzaWJsZSB3aGlsZSBtaW5pbWl6aW5nPGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7dGhlIGFtb3VudCBvZiBjaGFuZ2VzIG5lZWRlZCB0byBleGlzdGluZyBSVFAg YXBwbGljYXRpb25zLiAmbmJzcDtJdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3NwZWNpZmll cyBob3cgdG8gYXBwbHkgdGhlIG1ldGhvZCBmb3IgdGhlIE5BREEgY29uZ2VzdGlvbiBjb250cm9s PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YWxnb3JpdGhtLCBhbmQgcHJvdmlkZXMgc3VnZ2Vz dGlvbnMgb24gaG93IHRvIGFwcGx5IGl0IHRvIG90aGVyPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Y29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ybWNhdC1jb3VwbGVkLWNjLyIgY2xhc3M9IiI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ybWNhdC1jb3VwbGVkLWNj LzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXpl ZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcm1jYXQtY291cGxlZC1jYy0wNjxiciBjbGFzcz0iIj4NCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1ybWNhdC1jb3Vw bGVkLWNjLTA2PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0OjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJtY2F0LWNvdXBsZWQtY2MtMDY8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uPGJyIGNsYXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 PGJyIGNsYXNzPSIiPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_76E12E4D9E0C43B3B30AC4E7C6A69909ifiuiono_-- From nobody Wed Mar 29 10:25:58 2017 Return-Path: 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 B1D471294FF for ; Wed, 29 Mar 2017 10:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 r30Y75gBxlek for ; Wed, 29 Mar 2017 10:25:54 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DDD1272E1 for ; Wed, 29 Mar 2017 10:25:54 -0700 (PDT) Received: from [130.209.157.46] (port=9751 helo=glaroam2-177-18.wireless.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ctHM0-0003ac-8P; Wed, 29 Mar 2017 18:25:53 +0100 From: Colin Perkins Message-Id: <5FEE432C-6F1A-48BF-8E9E-BAE20EFF28B7@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_A881E23F-ED74-4E26-881E-5FEA7D1B6579" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 29 Mar 2017 18:25:48 +0100 In-Reply-To: <76E12E4D-9E0C-43B3-B30A-C4E7C6A69909@ifi.uio.no> Cc: "rmcat@ietf.org WG" , Michael Welzl , Stein Gjessing To: Safiqul Islam References: <149070616465.30521.13205282250119884347@ietfa.amsl.com> <76E12E4D-9E0C-43B3-B30A-C4E7C6A69909@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-06.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 17:25:56 -0000 --Apple-Mail=_A881E23F-ED74-4E26-881E-5FEA7D1B6579 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks. I=E2=80=99ll now proceed with the IESG write-up and publication request = (most likely next week). Colin > On 28 Mar 2017, at 14:14, Safiqul Islam wrote: >=20 > Hi all, >=20 > JFYI: we have now incorporated Colin=E2=80=99s comments.=20 >=20 > Regards, > Safiqul >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-06.txt >> Date: 28 March 2017 at 15:02:44 GMT+2 >> To: > >> Cc: rmcat@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the RTP Media Congestion Avoidance = Techniques of the IETF. >>=20 >> Title : Coupled congestion control for RTP media >> Authors : Safiqul Islam >> Michael Welzl >> Stein Gjessing >> Filename : draft-ietf-rmcat-coupled-cc-06.txt >> Pages : 26 >> Date : 2017-03-28 >>=20 >> Abstract: >> When multiple congestion controlled RTP sessions traverse the same >> network bottleneck, combining their controls can improve the total >> on-the-wire behavior in terms of delay, loss and fairness. This >> document describes such a method for flows that have the same = sender, >> in a way that is as flexible and simple as possible while = minimizing >> the amount of changes needed to existing RTP applications. It >> specifies how to apply the method for the NADA congestion control >> algorithm, and provides suggestions on how to apply it to other >> congestion control algorithms. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-rmcat-coupled-cc-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-coupled-cc-06 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-coupled-cc-06 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_A881E23F-ED74-4E26-881E-5FEA7D1B6579 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks.

I=E2=80=99ll now proceed with the IESG write-up and = publication request (most likely next week).

Colin



On 28 Mar 2017, at 14:14, Safiqul Islam <safiquli@ifi.uio.no>= wrote:

Hi all,

JFYI: we have now incorporated Colin=E2=80=99s = comments. 

Regards,
Safiqul


Begin forwarded message:

From: internet-drafts@ietf.org
Subject: [rmcat] I-D = Action: draft-ietf-rmcat-coupled-cc-06.txt
Date: 28 March 2017 at 15:02:44 = GMT+2
To: <i-d-announce@ietf.org>
Cc: rmcat@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the RTP Media Congestion Avoidance = Techniques of the IETF.

       Title =           : Coupled = congestion control for RTP media
       Authors =         : Safiqul Islam
=             &n= bsp;           &nbs= p;Michael Welzl
=             &n= bsp;           &nbs= p;Stein Gjessing
Filename =        : = draft-ietf-rmcat-coupled-cc-06.txt
Pages =           : 26
Date =            : = 2017-03-28

Abstract:
  When multiple congestion controlled RTP sessions traverse = the same
  network bottleneck, combining their controls can improve the = total
  on-the-wire behavior in terms of delay, loss and fairness. =  This
  document describes such a method for flows that have the = same sender,
  in a way that is as flexible and simple as possible while = minimizing
  the amount of changes needed to existing RTP applications. =  It
  specifies how to apply the method for the NADA congestion = control
  algorithm, and provides suggestions on how to apply it to = other
  congestion control algorithms.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rmcat-coupled-cc-06<= br class=3D""> https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-coupled-= cc-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-coupled-cc= -06


Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

-- 
Colin = Perkins
https://csperkins.org/




= --Apple-Mail=_A881E23F-ED74-4E26-881E-5FEA7D1B6579-- From nobody Fri Mar 31 05:01:26 2017 Return-Path: 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 AF7BA129457 for ; Fri, 31 Mar 2017 05:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=simula-no.20150623.gappssmtp.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 ygNYDidSAizM for ; Fri, 31 Mar 2017 05:01:21 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE0E1276AF for ; Fri, 31 Mar 2017 05:01:21 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id h125so42452713lfe.0 for ; Fri, 31 Mar 2017 05:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=simula-no.20150623.gappssmtp.com; s=20150623; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version:content-transfer-encoding; bh=348yVwxXjw7pYbtGsuMrUYBRtQsb/RZdt3o+uXHuI/E=; b=VsEmRQkfVnQbN/evfz/veplFZVRNzAGki1qdSeLf/SWImZTmdXK+hlOCfyxRe3ss4J 8QILsQ6bdEZFZhAVSzxikkbksBT5UZRsFYyLjivwWc6hrBfMffXCkdlMO3PeCGQpI2bt vuGll1dqxIcBwUR/405e8+AH24kLeeoM62oZtEo/NxG7fENBr70096C5PbpmxHfTJoTW tQTLPgfIIJCUmmTCXh8QfzUfuybk7vYM7Q3L3b8yCzLGRlVnlOJ0JloLhkteLdNWcJmS FW9U2cEQSRWUK0C59e7V9XU+dyn0AZDoj2Dm58R2Ka3JNSUbzKW1QNGEGee369qGGdrV 77Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version:content-transfer-encoding; bh=348yVwxXjw7pYbtGsuMrUYBRtQsb/RZdt3o+uXHuI/E=; b=GTDoNgFChELIixe7rjIClJc0D8Ep1gaIwXaACHpsq7X98/7EOAN/gI5Rwjv2ko5u5R uWIi1rOKhUTxQ1UPEtvCdCDaGTT6/FcHgUFXBOJEQVm7u+I4BvIreJzGQtpkr88uVGG6 gXZyc38p83cxdTVOPjH8lUCe/L2cVawsbd6VuSkrLErGXZKJae1f1GL42rrIirJsvNW0 qPSQnespTGaGjfELL7zDhdYc6M/xs88tSnpe+s/5aAatVzntmRLEpidZhIkdCMVRDDi9 YdKlB2utEFAfH5bQvEHoSPmmwuqyUGM2Bjvgy2ZOaOM7+klqY1ZJpHzoqZha5Q49FE2Z u+/w== X-Gm-Message-State: AFeK/H3jPCWKCuBoartY9HXeiJ1TzrC7U0kO4dC2dGa7Q1e7BaN/XBUQDVnjZBqfoeZQnbbL X-Received: by 10.25.38.83 with SMTP id m80mr896711lfm.166.1490961679296; Fri, 31 Mar 2017 05:01:19 -0700 (PDT) Received: from localhost ([77.88.71.158]) by smtp.gmail.com with ESMTPSA id p8sm891834lfp.21.2017.03.31.05.01.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 05:01:18 -0700 (PDT) References: <01258ecf-6a8a-1e8f-20f9-8d105ccb889e@kau.se> <3D88BE15-2E05-490A-A5BB-98993D892A52@csperkins.org> <43BFB16D-4D42-420F-AE4E-FAEC71E2339B@csperkins.org> User-agent: mu4e 0.9.18; emacs 24.5.1 From: David Hayes To: Colin Perkins Cc: Anna Brunstrom , "rmcat\@ietf.org" In-reply-to: <43BFB16D-4D42-420F-AE4E-FAEC71E2339B@csperkins.org> Date: Fri, 31 Mar 2017 14:01:13 +0200 Message-ID: <87pogx4pva.fsf@simula.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rmcat] RMCAT WGLC: draft-ietf-rmcat-sbd-05 - ends Dec 4 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 12:01:25 -0000 Hi Colin, We really appreciate you going through this again. Thank you!. We will work on clarifying the text you have highlighted and submit a revision of the draft. With the change to sender based congestion control, the SBD mechanism is also meant to be a user of the RTP Control Protocol (RTCP) Feedback for Congestion Control under development (though I have been unable to attend the last few design meetings). The feedback message still seems to contain all the per-packet information required by the SBD mechanism with the logic placed at the sender. Kind regards, David On Wed, Mar 22 2017 at 18:39, Colin Perkins wrote: > Hi, > > (Posting as an individual participant, not as WG co-chair) > > I reviewed the changes in version -06 of this draft. Comments below. > >> On 6 Dec 2016, at 18:35, Colin Perkins wrote: >> >>> On 13 Nov 2016, at 15:06, Anna Brunstrom > wrote: >>> This email announces a RMCAT Working Group Last Call (WGLC) on: >>> >>> Shared Bottleneck Detection for Coupled Congestion Control for RTP Media >>> draft-ietf-rmcat-sbd-05 >>> Due to the IETF week, this WGLC will run for 3 weeks, ending at midnight US Eastern Time on Sunday, December 4. Comments should preferably be sent to the rmcat@ietf.org list, although purely editorial comments may be sent directly to the authors at draft-ietf-rmcat-sbd@ietf.org - if doing so, please cc: the WG chairs at rmcat-chairs@tools.ietf.org . >>> >>> We are looking for at least a couple of reviews during WGLC, so please help review the document. >> >> >> (Posting as an individual participant, not as WG co-chair) >> >> I’ve reviewed this draft. In general, I think it’s in very good shape, and suitable for publication as an experimental RFC. I do, however, have some comments: >> >> - If I understand correctly, the draft replies on feedback sent every T seconds, where T=350ms by default. Such feedback is, presumably, to be sent by RTCP, since that is the standard back-channel for RTP flows. The RTCP reporting interval depends on the allocated RTCP bandwidth, the number of participants, and the size of the RTCP packets, and can vary between tens of milliseconds and tens of seconds. It’s unlikely to be exactly 350ms, although values of that order are not unreasonable. To what extent does the proposed mechanism depend on the precise timing of the feedback, and what are the acceptable upper- and lower-bounds on the feedback interval if the mechanism is to work? It would be useful if the draft could include some discussion of this, to aid both implementors and those looking to design congestion control and feedback mechanisms. > > A note has been added in -06 saying: > > Note that the mechanism bases its calculations on the interval T. It > does not require T to be the feedback interval, only that > calculations can be performed over measurements made in that > interval. > > I don’t think this is sufficient. How are the measurements made? The draft suggests using draft-ietf-rmcat-feedback-message but that doesn’t provide measurements over the same timescale. It might be reasonable to use this, or some other XR block, with aggregation across multiple reports, but the draft should explain – or at least, outline – what aggregation needs to be done, and how. > >> - Section 3.3.1 has a sequence of steps that start “group flows whose…”. I find this a little hard to follow, in particular it’s not clear what flows are left ungrouped after each stage. Would changing these steps to start “From the remaining set of ungrouped flows, group those flows whose…” reflect the intent and be clearer? > > The revised text is still not clear. It says, for example, “Subdivide freq_est groups”, but doesn’t say what a “freq_est group” is. Similarly for the other steps. If the goal is that step 3 sub-divides the groups identified in step 2, for example, then say that. > >> - Are the mechanisms in sections 3.4 and 3.5 required to be implemented, or are the optional? Some normative language might help to make it clearer what an implementation should do with these. It’s not clear if they’re essential parts of the algorithm, or enhancements for some situations. >> >> - In general, for a protocol specification, I think the draft would benefit from a more prescriptive (“when this happens, do this”) style of writing. I don’t think that’s a blocker for Experimental, but something to consider if it’s later revised for standards track. >> >> - Section 4.1, 2nd paragraph: I assume the suggestion is that each flow should use its media clock? Do any issues that arise when trying to group flows that use RTP different clock rates (e.g., the case where the audio flow has an 8kHz clock and the video flow has a 90kHz clock)? > > Perhaps I missed it, but this doesn’t appear to have been addressed. > >> - The draft says little about how feedback is to be conveyed. Is the expectation that the information can be extracted from the standard RTCP reception reports, or maybe XR blocks? It would be helpful if the draft could either point to existing feedback mechanisms that are suitable, or state that RTCP extensions will be needed. >> > > Thanks, > Colin -- David Hayes