From nobody Thu Oct 6 16:26:46 2016 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 CB3291294CD for ; Thu, 6 Oct 2016 16:26:44 -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] 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 YTbXaiNuztAx for ; Thu, 6 Oct 2016 16:26:43 -0700 (PDT) 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 02E541294CB for ; Thu, 6 Oct 2016 16:26:42 -0700 (PDT) X-Spam-Processed: mail.kau.se, Fri, 07 Oct 2016 01:26:35 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 213.113.180.232 X-MDArrival-Date: Fri, 07 Oct 2016 01:26:35 +0200 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 From: Anna Brunstrom To: "rmcat@ietf.org" Message-ID: <87f61c86-b04e-f205-08d2-e601a7514065@kau.se> Date: Fri, 7 Oct 2016 01:26:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A06CD51998EE23F723DD1290" Archived-At: Subject: [rmcat] RMCAT WGLC: draft-ietf-rmcat-scream-cc-06 - ends Oct 20 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: Thu, 06 Oct 2016 23:26:45 -0000 This is a multi-part message in MIME format. --------------A06CD51998EE23F723DD1290 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit This email announces a RMCAT Working Group Last Call (WGLC) on: Self-Clocked Rate Adaptation for Multimedia draft-ietf-rmcat-scream-cc-06 This WGLC will run for 2 weeks, ending at midnight US Eastern Time on Thursday, October 20. Comments should be sent to the rmcat@ietf.org list, although purely editorial comments may be sent directly to the authors at draft-ietf-rmcat-scream-cc@ietf.org - if doing so, please cc: the WG chairs at rmcat-chairs@tools.ietf.org. Please help review the document. Thanks, Anna & Martin --------------A06CD51998EE23F723DD1290 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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

Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-06

This WGLC will run for 2 weeks, ending at midnight US Eastern Time on Thursday, October 20.  Comments should be sent to the rmcat@ietf.org list, although purely editorial comments may be sent directly to the authors at draft-ietf-rmcat-scream-cc@ietf.org - if doing so, please cc: the WG chairs at rmcat-chairs@tools.ietf.org.

Please help review the document.

Thanks,
Anna & Martin


--------------A06CD51998EE23F723DD1290-- From nobody Mon Oct 10 08:17:58 2016 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 DCB73129479; Mon, 10 Oct 2016 08:17:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147611267189.31453.14962091509437710057.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 08:17:51 -0700 Archived-At: Cc: rmcat@ietf.org, ipr-announce@ietf.org Subject: [rmcat] IPR Disclosure Microsoft Technology Licensing, LLC. 's Statement about IPR related to draft-ietf-rmcat-scream-cc and draft-ietf-rmcat-nada X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 15:17:52 -0000 Dear Ingemar Johansson, Zaheduzzaman Sarker: An IPR disclosure that pertains to your Internet-Draft entitled "Self-Clocked Rate Adaptation for Multimedia" (draft-ietf-rmcat-scream-cc) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2890/). The title of the IPR disclosure is "Microsoft Technology Licensing, LLC. 's Statement about IPR related to draft-ietf-rmcat-scream-cc and draft-ietf-rmcat-nada" Thank you IETF Secretariat From nobody Mon Oct 10 08:18:06 2016 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 EE27A1295C1; Mon, 10 Oct 2016 08:17:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147611267197.31453.3770113116277627744.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 08:17:51 -0700 Archived-At: Cc: rmcat@ietf.org, ipr-announce@ietf.org Subject: [rmcat] IPR Disclosure Microsoft Technology Licensing, LLC. 's Statement about IPR related to draft-ietf-rmcat-scream-cc and draft-ietf-rmcat-nada X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 15:17:52 -0000 Dear Xiaoqing Zhu, Rong Pan, Dr. Michael A. Ramalho, Sergio Mena de la Cruz, Charles Ganzhorn, Paul Jones, Stefano D'Aronco, Jian Fu: An IPR disclosure that pertains to your Internet-Draft entitled "NADA: A Unified Congestion Control Scheme for Real-Time Media " (draft-ietf-rmcat-nada) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2890/). The title of the IPR disclosure is "Microsoft Technology Licensing, LLC. 's Statement about IPR related to draft-ietf-rmcat-scream-cc and draft-ietf-rmcat-nada" Thank you IETF Secretariat From nobody Thu Oct 20 09:34:44 2016 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 AFAD812968E for ; Thu, 20 Oct 2016 09:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 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] 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 WOorqtXoft6i for ; Thu, 20 Oct 2016 09:34:39 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 BB4D11294BD for ; Thu, 20 Oct 2016 09:34:38 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id b75so90216557lfg.3 for ; Thu, 20 Oct 2016 09:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=simula-no.20150623.gappssmtp.com; s=20150623; h=user-agent:from:to:subject:date:message-id:mime-version; bh=lY+aRnYqpz/g6Zjl+33gHvO/3i7ZCoQA8CZyyhSmLO8=; b=HHYuFBQMgc7fZHix3SudvKnvCAYYm81gvmMrebROLlpk9jCgr7nQNve4jmdRpwgfGB r3HO+4LDsmYgHzG0hJFkJKubPACwbsUauFpBw/aeS8Q0XECdg8SV1EzYJ54137lteEK6 W9tXD1y/mAI3VqDH3ModtAJwetFhFUFkEoeB08N8Fvghsb45fsC/u1P95x8pF/ICwF7f LjQo6lQlMWXlJb/afNIN1cbgX2N1hprkYSnQVlI9AuCJd6dYwinDdZQyIK6ArH2I4qOl 8YfOno18+aw43oKm1rvnjWIiAM6Echve3srMwoZSC/Kel4MPqLrecA1Fu4HLm/OBLuAo EtXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:from:to:subject:date:message-id :mime-version; bh=lY+aRnYqpz/g6Zjl+33gHvO/3i7ZCoQA8CZyyhSmLO8=; b=B7PwrnkuJs7YZv8yP1407xj1gC30Ac8l0zfqiA22S2eNTvMv6EMaZ/V0XpkJePUEBt /x8SkftRFmc4e0/8/FnWBOJWap/pAx1hwQub3pefZz4EC5kQh9fWxc7R5G1CCjTmxJ+s 7vg0bNojpmRT/W7zIYL128txWV24XEq07YJNAI3qqJ9SZQbEf+XG3snm+XdIJsj6GxM9 KSfyX8Q+COsb1sgcc/BSBMDymD+q3L43Hy0UV5SWDLNR8xsxGnDJUVcfcDpa2orZSaTl CVw8vuVDnr2tcRdzT4igCzM5JUx4SIHtyqbrr3ksd8URzDzyG61dqyxUYsQFg8aDqWx/ IzyA== X-Gm-Message-State: AA6/9Rm3t1T3huk04ShGRNN5whgSdqMBhs3apQiB590zSgFVk2TXahSooZ9hzuLTSAfLdI9G X-Received: by 10.25.18.97 with SMTP id h94mr3010277lfi.106.1476981276403; Thu, 20 Oct 2016 09:34:36 -0700 (PDT) Received: from localhost ([2a02:270:2014:40:c67d:46ff:fe17:5bed]) by smtp.gmail.com with ESMTPSA id z76sm12738066lff.35.2016.10.20.09.34.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Oct 2016 09:34:35 -0700 (PDT) User-agent: mu4e 0.9.16; emacs 24.5.1 From: David Hayes To: rmcat@ietf.org Date: Thu, 20 Oct 2016 18:34:35 +0200 Message-ID: <87a8dz0yjo.fsf@simula.no> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [rmcat] Review of draft-ietf-rmcat-scream-cc-06 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: Thu, 20 Oct 2016 16:34:43 -0000 Hi all, Below is my review of draft-ietf-rmcat-scream-cc-06. I hope the comments and corrections are helpful. Kind regards, David General comments: It would be better not to use the term "bandwidth", especially in the context of this draft where it often refers to LTE. Capacity or bit rate, where appropriate, make an unambiguous replacement. The algorithm description has many constant numerical values, e.g.: 50, 1.5, 1.25, 5, etc. It may be better if some of these were parameters. Some descriptions could be more concise. Section by section comments: 1. Introduction Applications don't necessarily need to "have" congestion control schemes. They may use transports that have them. Perhaps it is better to use the word "employ" instead of "have" in this context. "the service *it* provides" --- it is ambiguous in this sentence. "but also to ensure the function of the currently deployed Internet" --- this is vague. Perhaps this phrase is not needed. "over a large span in available bandwidth" -> "over a large dynamic range" "what is used in a new delay based rate adaptation algorithm, LEDBAT" -> "what is used in the LEDBAT based rate adaptation algorithm" SCREaAM is not an entirely self clocked protocol. It augments self clocking with pacing and a minimum send rate. Perhaps this should be mentioned up front. 1.1 Wireless (LTE) access properties "(in one RTT)" -> ("within one RTT)" 1.2 Why is it a self-clocked algorithm? The first paragraph is too long and difficult to read. I suggest starting as follows: "Self-clocked congestion control algorithms provide a benefit over rate based counterparts in that the former consists of two adaption mechanisms:" Then a numbered list of the two mechanisms. "the outcome is still that there is only" -> "there is still only" 3. Overview of SCReAM Algorithm [PACKET_CONSERVATION] reference does not seem to be listed fully in the bibliography. "the sender in feedback packets, the sender keeps" -> "the sender in feedback packets. The sender keeps" "amount of bytes" -> "number of bytes" "All this implements a congestion control that follows the packet conservation principle." -> "" (unnecessary repetition) "The fact that SCReAM follows ... makes it as safe ..." -> I'm not sure that a statement like this is needed. "No additional circuit breaker mechanisms are necessary with SCReAM as the ACK-clocking automatically falls back to a very low transmission rate (1 RTP packet/200ms) when the acknowledgements no longer arrive at the sender." --- I'm not sure how the need or not for a circuit breaker mechanism relates to SCReAM being able to keep sending even when it gets no ACKs. "Furthermore, high packet loss rates reduces the congestion value to very low values and thus a low transmission rate." --- This wording here doesn't make sense to me. I think the sentence can probably be removed. "LEDBAT is a congestion control..." --- keep with previous sentence. "LEDBAT ensures that the end-to-end latency is kept low" --- This is not what was found by Ros and Welzl (see http://home.ifi.uio.no/michawe/research/publications/ledbat-impact-letters.pdf). "concept work with conversational media. In a few words they are:" -> "concept work with conversational media:" "is limited by the amount of actual bytes" -> "is limited by the actual number of bytes" "Fast increase for quicker bitrate increase. It makes" -> "Fast increase makes" "this to enable a" -> "this enables a" "constitutes mainly three parts:" -> "consists of three main parts:" "All these" -> "All of these" 3.2. Sender Transmission Control "Packet pacing limits the packet transmission rate, given by the estimated link throughput, this has the effect that even if" -> "Packet pacing limits the packet transmission rate given by the estimated link throughput. Even if" 3.3. Media Rate Control "queued up in" -> "queued in" "such as the case" -> "such as in the case" "discarding of encoded" -> "discarding encoded" " RTP queues are drained quickly or simply that stale RTP packets are removed from the queue. Frame skipping means that the frame rate is temporarily" -> " RTP queues are drained quickly. Stale RTP packets are removed from the queue. Frame skipping results in the frame rate being temporarily" "design consideration" -- Do you mean policy? 4.1. SCReAM Sender "is a split between" -> "is split between" "(a.k.a stream)" -> "(or stream)" "different streams and then act like" -> "different streams and act like" "controls the media bitrate (3)" --- I think you mean "provides a target rate for the media encoder (3)" "takes care of the transmission of RTP packets to be written to the UDP socket" -> "sends the RTP packets to the UDP socket" "and is allowed to be transmitted if the number of bytes in flight is less " -> "and is limited so that the number of bytes in flight is less" 4.1.1.1. Constants QDELAY_TARGET_LO (0.1s) and QDELAY_TARGET_HI (0.4s) to not match the 50-100ms mentioned earlier. "H264 and VP8 have however given" -> "H264 and VP8 indicate" The last 4 constants do not start a new line for the description, and should to be consistent. 4.1.1.2. State variables "computed similar to method depicted in [RFC6298]" -> "computed with a similar method depicted to that in [RFC6298]" 4.1.2. Network congestion control "it contains two main functions" -> "it contains two main functions:" "i.e how many bytes that have been transmitted but not yet acknowledged" -> "" (unnecessary repetition) "Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an RTP packet oriented protocol. Thus a list of transmitted RTP packets and their respective transmission times (wall-clock time) is kept for further calculation. The congestion control is however based on transmitted and acknowledged bytes." --- This paragraph needs work. SCReAM is a byte oriented congestion control algorithm. The paragraph seems to contradict itself as it is written. "The qdelay fraction is sampled every 50ms" --- Previously it was mentioned that there were occasions where packets could be sent once every 200ms. Is this a problem here? Perhaps "The 50ms sampling is a simplification a ..." is addressing this, though I think it would be made clearer if the paragraph was reworded. "SCReAM on the other hand has a source which rate is limited to a value close to the available transmit rate and often below said value," -> "SCReAM on the other hand has a source whose rate is limited to a value close to the available transmit rate and often below that value," 4.1.2.2. Competing flows compensation "It is desired avoid" -> "It is desirable to avoid" "positives and negatives but it manages competing FTP flows reasonably well at the same time as it has proven to avoid accidental increased qdelay target relatively well in simulated LTE test cases." -> "positives and negatives. In the simulated LTE test cases it manages competing FTP flows reasonably well at the same time as generally avoiding accidental increases in the qdelay target." "The algorithm can however accidentally increase the qdelay target and cause self-inflicted congestion in certain cases, therefore it is recommended to turn off the algorithm if is unlikely that competing flows will occur over the same bottleneck." --- This is unclear and needs rewriting. 4.1.2.3. Lost packets detection -> Lost packet detection "Lost packets detection" -> "Lost packet detection" "to avoid that packet reordering triggers" -> "to avoid packet reordering triggering" 4.1.2.4. Send window calculation "A strict rule as the one given above will have the effect that the media bitrate will have difficulties to increase as the congestion window puts a too hard restriction on the media frame size variation. This can lead to" -> "A strict rule can lead to" "will further prevent bitrate increase" -> "will prevent bitrate increase" "bitrate to increase fast when" -> "bitrate to increase quickly when" 4.1.3. Media rate control "considered in the media rate control, this to" -> "considered in the media rate control to" "capacity and that the flow is starved out by other, more opportunistic traffic, on the other hand a too aggressive setting leads to extra jitter." -> "capacity leading to the flow being starved out by other, more opportunistic traffic. On the other hand too aggressive a setting leads to extra jitter." "to avoid that RTP packets are queued" -> "to avoid RTP packets being queued" "RTP packets in cases the network" -> "RTP packets in cases where the network" "pro actively avoids that RTP packets are queued" -> "pro actively avoids RTP packets being queued" 4.1.3.1. FEC and packet overhead considerations "The target bitrate given by SCReAM depicts the bitrate including RTP" -> "The target bitrate given by SCReAM includes RTP" **To me the congestion controller should be taking into account the codec, not the other way around. "compensate moderate errors." -> "compensate for moderate errors." "Under-compensation of the overhead has the effect that the jitter will increase somewhat while overcompensation will have the effect that the bottleneck link becomes under-utilized." -> "Under-compensation of the overhead has the effect of increasing jitter while overcompensation will have the effect of causing the bottleneck link to become under-utilized." 4.2. SCReAM Receiver "receiver will simply" -> "receiver must" "via RTCP"->"via an RTCP" 5. Discussion "as is the case with LEDBAT [RFC6817]. Section A.2 in said RFC however" -> "as is the case with LEDBAT [RFC6817]. Section A.2 in [RFC6817]" 10. Security Considerations "Furthermore, as SCReAM is self-clocked, a malicious middlebox can drop RTCP feedback packets and thus cause the self-clocking in SCReAM to stall." --- yes, but the self-clocking attack problem is mitigated by the minimum rate paced packets that SCReAM sends when there are no ACKs. -- David Hayes From nobody Fri Oct 21 16:28:50 2016 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 6908D1296AB; Fri, 21 Oct 2016 16:21:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208242.28214.11688712965439492082.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:22 -0700 Archived-At: Cc: rmcat@ietf.org, ietf@kuehlewind.net Subject: [rmcat] rmcat - Requested session has been scheduled for IETF 97 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 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, 21 Oct 2016 23:21:26 -0000 Dear Anna Brunstrom, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rmcat Session 1 (2:30:00) Thursday, Afternoon Session II 1520-1750 Room Name: Studio 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: RTP Media Congestion Avoidance Techniques Area Name: Transport Area Session Requester: Anna Brunstrom Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: perc netvc maprg iccrg tsvwg tsvarea taps quic aqm tcpm tcpinc avtext avtcore rtcweb mptcp Second Priority: tram mmusic ippm clue raiarea dispatch httpbis Third Priority: irtfopen Special Requests: Avoid transport BOFs. --------------------------------------------------------- From nobody Mon Oct 24 12:46:15 2016 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 146C61299C0 for ; Mon, 24 Oct 2016 12:46: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 ryuxFudnwAyt for ; Mon, 24 Oct 2016 12:46:11 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 CA86F1293F4 for ; Mon, 24 Oct 2016 12:46:10 -0700 (PDT) X-AuditID: c1b4fb25-15fff7000000793b-29-580e6500ba69 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 9D.91.31035.0056E085; Mon, 24 Oct 2016 21:46:09 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 24 Oct 2016 21:46:07 +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=G2luCV2Qptnt+nmF9dVnhaONdtAvQH0IAaWXOVfOe2s=; b=nM1ZdtXduVH+dwdrfcQZw497ZzYOGBkNjm5FTq3deg8754qP1pjp4AE8llJesjchCACqtyz4tS0ucDHkS2+vbAsXNkBI4ut+fu4P3/obJOq5HfD6peNU1y3Xay5Ym7h2zjViDPro/UiFuhNgfY69qllDcAktr+w5LcfP4Rlx2XM= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB299.eurprd07.prod.outlook.com (10.141.234.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Mon, 24 Oct 2016 19:46:06 +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.0669.021; Mon, 24 Oct 2016 19:46:05 +0000 From: Ingemar Johansson S To: David Hayes , "rmcat@ietf.org" Thread-Topic: [rmcat] Review of draft-ietf-rmcat-scream-cc-06 Thread-Index: AQHSKwRn4C2sgbWvrk6pNeD5/phMb6C3PeBQ Date: Mon, 24 Oct 2016 19:46:05 +0000 Message-ID: References: <87a8dz0yjo.fsf@simula.no> In-Reply-To: <87a8dz0yjo.fsf@simula.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.89] x-microsoft-exchange-diagnostics: 1; DB4PR07MB299; 6:Nv3XkU9Dhy9UwxKuE0QU39KAXws3a2pib8KHgQo79EVSm3SIuHSsw7pMoCssccRLAPVxopKZcYAtGA+Tqrt5J7+TVBEU8PFKNDrHhY60N2YzmQMfhylk2nRKF40iaxbkzui5R7m+wIYEWH47sofrRjq2Ldi3yoCj3/7hpXlkzrdZKBo8jUPrNvXxQsI707+FBA++136KwqxLZfJuvoekHFdM3FTKyQK6pn5qtdjRw+5QEaR+6D0bKG/w6uY+By6eZelvNuGBYDukIdzIKt/pMRxkgobBzc1INdbWjWN+8PE+ZciIAfmQhOVcb2QzwHY9; 5:MWP43kkVaQnMa6dELtfjOJshgvS+C2m7oqnG6daKlPSFESaJVBTc4ZQ2/DQ1CVfYh/8u7OLiZlBV8DN4XBxCodLc7qsYIHP+k6jlnz2G6LUqSFZvC4Grtq0hYBxIZcgGBQdrdyzUU6Ieqn8VXaE8lA==; 24:+UcLeY/sybLM5nxigDgvAeqICCDYM8tCpwTkYBRvuC2rl4Mxxt/8GTXvoDfrdXPRObd3rGivbXDEADxBaDy5R4xK2gWGltcvbP/thxzzQOQ=; 7:9goLKD5yiwbM17nt3UjuQR0RJ3NJvMMKdHDI9z39lE/hDRboEAkDC0JWeKYTZz+nvOeRqV1Zu9a15aNCpuU4w8d0w0asQKw0ZyPfjHQZ5j5yAypUlrCv4//58Mp99ZQjFpqJpL2h4yNrprDP65bUTwQ3vK4DYJS3BYldCipdD+n1Joy43BWvS+CB/zh/vpoR5jlc/eujznzs6U6q56WW0ftNYma7DfBHxgZwTe4wpln96lMqdmJZOZT0pSFk8/tdDxeUrQRoW9Q+t3JLii3D2AnS+wwkTY1dJMSvBkX1V0incihffd+e6GRJFO1o7qm+Lm4RFA6x9mhL2OUm60dZLRBGssdjLNru6opY5MrhXTg= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(51914003)(13464003)(53754006)(199003)(66654002)(87936001)(54356999)(33656002)(2501003)(106116001)(106356001)(77096005)(105586002)(101416001)(3280700002)(3660700001)(5660300001)(2950100002)(4326007)(7846002)(7736002)(8676002)(81166006)(92566002)(74316002)(15975445007)(81156014)(7696004)(102836003)(586003)(3846002)(6116002)(2900100001)(86362001)(2906002)(1720100001)(107886002)(305945005)(68736007)(230783001)(9686002)(8936002)(5001770100001)(97736004)(189998001)(10400500002)(5002640100001)(122556002)(4001430100002)(66066001)(76576001)(19580395003)(50986999)(19580405001)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB299; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: db70f263-385e-404d-ecd8-08d3fc46648d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB299; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR07MB299; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB299; x-forefront-prvs: 0105DAA385 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2016 19:46:05.1402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB299 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42KZGbFdV5cxlS/C4ONvHot/h86zW3T8bWGx WH3zA5sDs8eSJT+ZPLZ1HGb3+HL5M1sAcxSXTUpqTmZZapG+XQJXRsvfjewFeysq9h9azdTA +Dq+i5GTQ0LARKJ3VTNrFyMXh5DAekaJ3wc7WSCcE4wSk2a2MYE4LAK9zBLnpsxmAmkREpjC JPHtEDtE1TFGiY1fj7GDJNgEbCRWHvrOCGKLCLhKHHo6B2wUs8B2Rolfs1vBEsJARee2nWaB KLKVuNDYCjSVA8g2kjjcHQoSZhFQlfh8bhJYmFcgSuLJZqi9ahJP3x0HszkF1CX29k0CsxkF ZCXuf78HNpFZQFzi1pP5TBCvCUgs2XOeGcIWlXj5+B8rRH2yxKebvawQcQWJ4yvesoGcKSHw nl1i1u8JTBDOCjaJaTdes0NU+Urs7H3DAmG7SvSv3MAMcpyEQKbE6jNSEKaPxNLL6RCt2xgl tmw9A7VARqL39EQWiAdSJZavhQWDlMTdK52MExi1ZiG5G8LWkViw+xMbhK0tsWzha2YQm1dA UOLkzCcsCxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIEJpKDW36r7mC8/MbxEKMAB6MS D6+CD1+EEGtiWXFl7iFGCQ5mJRHe27FAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxmK++HCwmk J5akZqemFqQWwWSZODilGhjj5/595Nk2o9rlm1ZqEW/mJuOPDbva1x6N26HZ8G7B9+OfXwok CNvKrDO+E1LaJmgYobBJNOzU3sMzLpzV0n3w9ZTMn9+isy2zohMnqThMefkuM2vbaW+fh4md 13ZEWssmHi6VXq6d/9y6weHVId2dRx7X8E9lc+3etj/q/7P5vMc5Fn/d/UdRiaU4I9FQi7mo OBEACJSNiiADAAA= Archived-At: Cc: Ingemar Johansson S , Zaheduzzaman Sarker , "'rmcat-chairs@tools.ietf.org'" Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-06 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: Mon, 24 Oct 2016 19:46:14 -0000 Hi Many thanks for the review, most of the editorial comments are accepted,=20 some comments and suggested text changes inline, marked [IJ] /Ingemar > -----Original Message----- > From: David Hayes [mailto:davidh@simula.no] > Sent: den 20 oktober 2016 18:35 > To: rmcat@ietf.org > Subject: [rmcat] Review of draft-ietf-rmcat-scream-cc-06 >=20 > Hi all, >=20 > Below is my review of draft-ietf-rmcat-scream-cc-06. I hope the comments > and corrections are helpful. >=20 > Kind regards, >=20 > David >=20 > General comments: >=20 > It would be better not to use the term "bandwidth", especially in the con= text > of this draft where it often refers to LTE. Capacity or bit rate, where > appropriate, make an unambiguous replacement. [IJ] OK, it sounds quite reasonable >=20 > The algorithm description has many constant numerical values, e.g.: 50, 1= .5, > 1.25, 5, etc. It may be better if some of these were parameters. [IJ] Yes, will give it a shot, main problem is that sometimes find it had t= o find the proper names >=20 > Some descriptions could be more concise. >=20 >=20 > Section by section comments: >=20 > 1. Introduction >=20 > Applications don't necessarily need to "have" congestion control schemes. > They may use transports that have them. Perhaps it is better to use the w= ord > "employ" instead of "have" in this context. >=20 > "the service *it* provides" --- it is ambiguous in this sentence. >=20 > "but also to ensure the function of the currently deployed Internet" --- = this is > vague. Perhaps this phrase is not needed. [IJ] Perhaps rewrite as Applications that are deployed in the Internet must employ congestion control, to achieve robust performance and to avoid congestion collapse. >=20 > "over a large span in available bandwidth" -> "over a large dynamic range= " [IJ] OK >=20 > "what is used in a new delay based rate adaptation algorithm, LEDBAT" -> > "what is used in the LEDBAT based rate adaptation algorithm" [IJ] OK >=20 > SCREaAM is not an entirely self clocked protocol. It augments self clocki= ng > with pacing and a minimum send rate. Perhaps this should be mentioned up > front. [IJ] OK will add it=20 >=20 >=20 > 1.1 Wireless (LTE) access properties >=20 > "(in one RTT)" -> ("within one RTT)" >=20 >=20 > 1.2 Why is it a self-clocked algorithm? >=20 > The first paragraph is too long and difficult to read. I suggest starting= as > follows: >=20 > "Self-clocked congestion control algorithms provide a benefit over rate b= ased > counterparts in that the former consists of two adaption mechanisms:" >=20 > Then a numbered list of the two mechanisms. [IJ] OK >=20 >=20 > "the outcome is still that there is only" -> "there is still only" [IJ] OK >=20 >=20 > 3. Overview of SCReAM Algorithm >=20 > [PACKET_CONSERVATION] reference does not seem to be listed fully in the > bibliography. [IJ] Good observation, must have been trashed... >=20 > "the sender in feedback packets, the sender keeps" -> "the sender in > feedback packets. The sender keeps" >=20 > "amount of bytes" -> "number of bytes" >=20 > "All this implements a congestion control that follows the packet > conservation principle." -> "" (unnecessary repetition) [IJ] ACK to all the above >=20 > "The fact that SCReAM follows ... makes it as safe ..." -> I'm not sure t= hat a > statement like this is needed. [IJ] I can remove it, recall though that it was added because somebody aske= d a question related to this...?=20 >=20 >=20 > "No additional circuit breaker mechanisms are necessary with SCReAM as > the ACK-clocking automatically falls back to a very low transmission rat= e (1 > RTP packet/200ms) when the acknowledgements no longer arrive at the > sender." --- I'm not sure how the need or not for a circuit breaker > mechanism relates to SCReAM being able to keep sending even when it gets > no ACKs. [IJ] I can probably remove the sentence altogether, it is not needed for th= e draft. >=20 >=20 > "Furthermore, high packet loss rates reduces the congestion value to very > low values and thus a low transmission rate." --- This wording here doesn= 't > make sense to me. I think the sentence can probably be removed. [IJ] OK >=20 >=20 >=20 > "LEDBAT is a congestion control..." --- keep with previous sentence. [IJ] OK >=20 >=20 > "LEDBAT ensures that the end-to-end latency is kept low" --- This is not = what > was found by Ros and Welzl (see > http://home.ifi.uio.no/michawe/research/publications/ledbat-impact- > letters.pdf). [IJ] Have missed this paper, thanks for the heads up. Yes, the base delay history is an issue. The big difference with using LEDB= AT in the SCReAM context lies in the fact that the source is rate limited a= nd that it is required that RTP queue is kept short (preferably empty). In = addition the output from a video encoder is rarely constant bitrate, static= content (talking heads) for instance gives almost zero video rate. This gives two properties 1) There is always a certain probability that SCReAM is short of data to tr= ansmit, which means that the network queue will run empty every once in a w= hile. 2) The max video bitrate can be lower than the link capacity. If the max vi= deo bitrate is 5Mbps and the capacity is 10Mbps then we get an empty queue.= =20 It is sufficient that any of the two conditions above is fulfilled to make = the base delay update properly. As regards to the issue with shortlived competing flows, the case here is t= hat these shortlived flows will case the ACK-clocking in SCReAM to slow dow= n with the result that an RTP queue is built up, which will result in a red= uced video bitrate. SCReAM will thus yield more to competing short lived fl= ows than what is the case with traditional use of LEDBAT.=20 Perhaps this should be explained in the draft. >=20 >=20 > "concept work with conversational media. In a few words they are:" -> > "concept work with conversational media:" >=20 >=20 > "is limited by the amount of actual bytes" -> "is limited by the actual > number of bytes" >=20 >=20 > "Fast increase for quicker bitrate increase. It makes" -> "Fast increase > makes" >=20 > "this to enable a" -> "this enables a" >=20 > "constitutes mainly three parts:" -> "consists of three main parts:" >=20 > "All these" -> "All of these" [IJ] OK to all the above >=20 >=20 > 3.2. Sender Transmission Control >=20 > "Packet pacing limits the packet transmission rate, given by the > estimated link throughput, this has the effect that even if" -> "Packet > pacing limits the packet transmission rate given by the estimated link > throughput. Even if" >=20 > 3.3. Media Rate Control >=20 > "queued up in" -> "queued in" >=20 > "such as the case" -> "such as in the case" >=20 > "discarding of encoded" -> "discarding encoded" >=20 > " RTP queues are drained quickly or simply that stale RTP packets are > removed from the queue. Frame skipping means that the frame rate is > temporarily" -> " RTP queues are drained quickly. Stale RTP packets are > removed from the > queue. Frame skipping results in the frame rate being temporarily" >=20 [IJ] OK to all the above > "design consideration" -- Do you mean policy? [IJ] Yes. >=20 >=20 > 4.1. SCReAM Sender >=20 > "is a split between" -> "is split between" >=20 > "(a.k.a stream)" -> "(or stream)" >=20 > "different streams and then act like" -> "different streams and act > like" >=20 > "controls the media bitrate (3)" --- I think you mean "provides a target > rate for the media encoder (3)" >=20 > "takes care of the transmission of RTP packets to be > written to the UDP socket" -> "sends the RTP packets to the UDP socket" >=20 > "and is allowed to be transmitted if the number of bytes in flight is > less " -> "and is limited so that the number of bytes in flight is less" >=20 [IJ] OK to all the above >=20 > 4.1.1.1. Constants >=20 > QDELAY_TARGET_LO (0.1s) and QDELAY_TARGET_HI (0.4s) to not match the > 50-100ms mentioned earlier. [IJ] OK, needs a clarification, the QDELAY_TARGET_HI value is an upper limi= t to how much the target delay can be increased in order to cope with compe= ting loss based flows. It is not recommended to set the target delay this h= igh otherwise as it increases e2e delay and makes the rate control and cong= estion control loop sluggish >=20 >=20 > "H264 and VP8 have however given" -> "H264 and VP8 indicate" [IJ] OK >=20 > The last 4 constants do not start a new line for the description, and > should to be consistent. [IJ] OK >=20 > 4.1.1.2. State variables >=20 > "computed similar to method depicted in [RFC6298]" -> "computed with a > similar method depicted to that in [RFC6298]" [IJ] OK >=20 >=20 > 4.1.2. Network congestion control >=20 > "it contains two main functions" -> "it contains two main functions:" >=20 > "i.e how many bytes that have been transmitted but not yet acknowledged" > -> "" (unnecessary repetition) >=20 [IJ] OK >=20 > "Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an > RTP packet oriented protocol. Thus a list of transmitted RTP packets > and their respective transmission times (wall-clock time) is kept for > further calculation. The congestion control is however based on > transmitted and acknowledged bytes." --- This paragraph needs > work. SCReAM is a byte oriented congestion control algorithm. The > paragraph seems to contradict itself as it is written. [IJ] You are right , what about. "SCReAM is a byte protocol congestion control protocol, where the number of= bytes transmitted is inferred from the size of the transmitted RTP packets= . Thus a list of transmitted RTP packets and their respective transmission = times (wall-clock time) is kept for further calculation." >=20 >=20 > "The qdelay fraction is sampled every 50ms" --- Previously it was > mentioned that there were occasions where packets could be sent once > every 200ms. Is this a problem here? Perhaps "The 50ms sampling is a > simplification a ..." is addressing this, though I think it would be > made clearer if the paragraph was reworded. [IJ] Yes, in practice this does not seem to cause any problem. I will see i= f I can improve this para. >=20 > "SCReAM on the other hand has a source which rate is limited to a value > close to the available transmit rate and often below said value," -> > "SCReAM on the other hand has a source whose rate is limited to a value > close to the available transmit rate and often below that value," [IJ] OK >=20 >=20 > 4.1.2.2. Competing flows compensation >=20 > "It is desired avoid" -> "It is desirable to avoid" >=20 > "positives and negatives but it manages competing FTP flows reasonably > well at the same time as it has proven to avoid accidental increased > qdelay target relatively well in simulated LTE test cases." -> > "positives and negatives. In the simulated LTE test cases it manages > competing FTP flows reasonably well at the same time as generally > avoiding accidental increases in the qdelay target." >=20 > "The algorithm can however accidentally increase the qdelay target and > cause self-inflicted congestion in certain cases, therefore it is > recommended to turn off the algorithm if is unlikely that competing > flows will occur over the same bottleneck." --- This is unclear and > needs rewriting. [IJ] Ok, try with=20 "The algorithm can however accidentally increase the qdelay target and caus= e self-inflicted congestion in certain cases. It is therefore recommended t= hat the algorithm described in this section is turned off it is unlikely th= at competing flows occur over the same bottleneck.=20 " >=20 >=20 > 4.1.2.3. Lost packets detection -> Lost packet detection >=20 > "Lost packets detection" -> "Lost packet detection" >=20 > "to avoid that packet reordering triggers" -> "to avoid packet > reordering triggering" [IJ] OK >=20 >=20 > 4.1.2.4. Send window calculation >=20 > "A strict rule as the one given above will have the effect that the > media bitrate will have difficulties to increase as the congestion > window puts a too hard restriction on the media frame size variation. > This can lead to" -> "A strict rule can lead to" >=20 > "will further prevent bitrate increase" -> "will prevent bitrate > increase" >=20 > "bitrate to increase fast when" -> "bitrate to increase quickly when" [IJ] OK >=20 >=20 > 4.1.3. Media rate control >=20 > "considered in the media rate control, this to" -> "considered in the > media rate control to" >=20 > "capacity and that the flow is starved out by other, more opportunistic > traffic, on the other hand a too aggressive setting leads to extra > jitter." -> "capacity leading to the flow being starved out by other, > more opportunistic traffic. On the other hand too aggressive a setting > leads to extra jitter." >=20 > "to avoid that RTP packets are queued" -> "to avoid RTP packets being > queued" >=20 > "RTP packets in cases the network" -> "RTP packets in cases where the > network" >=20 > "pro actively avoids that RTP packets are queued" -> "pro actively > avoids RTP packets being queued" [IJ] OK >=20 >=20 > 4.1.3.1. FEC and packet overhead considerations >=20 > "The target bitrate given by SCReAM depicts the bitrate including RTP" > -> "The target bitrate given by SCReAM includes RTP" [IJ] OK >=20 > **To me the congestion controller should be taking into account the > codec, not the other way around. [IJ] Yes, perhaps. My thinking here is that SCReAM may not know how much ex= tra FEC overhead there is. The Video encoder may produce a variable FEC ove= rhead depending on the amount of packet loss. It can be tricky (?) for a b= ox outside the video encoder to infer this information from the RTP packet = stream. The Video coder should however have an exact knowledge about this = =20 I guess I here lack the expert knowledge to determine what is the most corr= ect. >=20 >=20 > "compensate moderate errors." -> "compensate for moderate errors." >=20 > "Under-compensation of the overhead has the effect that the jitter will > increase somewhat while overcompensation will have the effect that the > bottleneck link becomes under-utilized." -> "Under-compensation of the > overhead has the effect of increasing jitter while overcompensation will > have the effect of causing the bottleneck link to become > under-utilized." [IJ] OK >=20 >=20 > 4.2. SCReAM Receiver >=20 > "receiver will simply" -> "receiver must" >=20 > "via RTCP"->"via an RTCP" [IJ] OK >=20 > 5. Discussion >=20 > "as is the case with LEDBAT [RFC6817]. Section A.2 in said RFC however" = -> > "as > is the case with LEDBAT [RFC6817]. Section A.2 in [RFC6817]" [IJ OK >=20 >=20 >=20 > 10. Security Considerations >=20 > "Furthermore, as SCReAM is self-clocked, a malicious middlebox can drop > RTCP feedback packets and thus cause the self-clocking in SCReAM to > stall." --- yes, but the self-clocking attack problem is mitigated by > the minimum rate paced packets that SCReAM sends when there are no > ACKs. [IJ] OK, will add that. >=20 >=20 > -- > David Hayes >=20 From nobody Wed Oct 26 13:25:57 2016 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 209071299A0; Wed, 26 Oct 2016 13:25:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147751355212.2882.17375010911122387567.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2016 13:25:52 -0700 Archived-At: Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-eval-test-04.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 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, 26 Oct 2016 20:25:52 -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 : Test Cases for Evaluating RMCAT Proposals Authors : Zaheduzzaman Sarker Varun Singh Xiaoqing Zhu Michael A. Ramalho Filename : draft-ietf-rmcat-eval-test-04.txt Pages : 32 Date : 2016-10-26 Abstract: The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications, these applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-test/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rmcat-eval-test-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-eval-test-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 Fri Oct 28 08:44:47 2016 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 A5B71129692 for ; Fri, 28 Oct 2016 08:44:45 -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 hRd-le5D9Lrk for ; Fri, 28 Oct 2016 08:44:40 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 F18E012967D for ; Fri, 28 Oct 2016 08:44:38 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-5e-58137265947c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id D8.42.03250.46273185; Fri, 28 Oct 2016 17:44:37 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 28 Oct 2016 17:44:36 +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=3VNVdKq+EwtkCx8ajqt36CRMHdx0rMqvZQ6+lgY7gHk=; b=RAs7A+LLIPup9Py9+pA5Br5w9PLfgEyQA3eytN+N2lJmci2oyS0BLITk31TwBbA+366ZNy3OwOyyYd0qCkLmauyrLnS4qOlPSraPYJxiT9ZsbkIKoFPEKwDSPTz/iNzPsmnyuknomyEibbCVAJ8th4SjqbMdGa6Aqbje8GGoBxQ= Received: from AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) by AM3PR07MB289.eurprd07.prod.outlook.com (10.242.108.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Fri, 28 Oct 2016 15:44:35 +0000 Received: from AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::4073:398:9056:882c]) by AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::4073:398:9056:882c%14]) with mapi id 15.01.0707.002; Fri, 28 Oct 2016 15:44:35 +0000 From: Zaheduzzaman Sarker To: "rmcat@ietf.org" Thread-Topic: New Version Notification for draft-dt-rmcat-feedback-message-01.txt Thread-Index: AQHSMTDEV38XJCWO9kq5ZvEWZj6ljKC+AQfQ Date: Fri, 28 Oct 2016 15:44:35 +0000 Message-ID: References: <147766882451.24983.16939871056638638592.idtracker@ietfa.amsl.com> In-Reply-To: <147766882451.24983.16939871056638638592.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-office365-filtering-correlation-id: 5705dfa8-bd04-4eb9-3ff7-08d3ff495195 x-microsoft-exchange-diagnostics: 1; AM3PR07MB289; 7:0T2n4QLls5JR5UqOgZm5wND8WBxWcp9N+cmGs0tbGhdkU4wxfd8nG5OcqrYQp/UDiVir2fCL4tzwDotT518Bx9asndYH9ezIMYr+xJI2Xm/FOxKEd5nSNTd3KTQSu290D798R4S1HnSo/qniHD5qn550qsx8WZl213lWgRSn3ek41vMhYHiQWDEaU7BBABDLGdm8FUs+a6uA2RlnUbhNoXmcRitZhwn9v4MMOPp+1mncxb1LkAagjQrUwBRhra6DbbRRCOztaONrQ5s6sDAAeS+WIo/n6baNB3tCfqL3rrJc7y2zgVVQnC/vn52b5MEASYCnJ3kXyICXwe0h9+wFNIZTg6VUoBYTWFPtd2Is1dg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB289; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM3PR07MB289; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB289; x-forefront-prvs: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2473002)(53754006)(13464003)(199003)(189002)(377424004)(4001150100001)(97736004)(305945005)(189998001)(3280700002)(5640700001)(87936001)(54356999)(76176999)(50986999)(92566002)(19580395003)(19580405001)(76576001)(2501003)(5250100002)(450100001)(86362001)(7696004)(107886002)(2900100001)(15650500001)(66066001)(15975445007)(110136003)(6916009)(3660700001)(2950100002)(586003)(68736007)(81166006)(74316002)(5660300001)(6116002)(102836003)(7736002)(1730700003)(2351001)(8676002)(3846002)(11100500001)(7846002)(106356001)(106116001)(105586002)(230783001)(33656002)(9686002)(101416001)(81156014)(8936002)(2906002)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB289; H:AM3PR07MB292.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) 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: 28 Oct 2016 15:44:35.4011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB289 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUyM2K7n25qkXCEwcTTgharb35gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvzlN9kKZkhWfL3czdLAeESii5GTQ0LARGLylD7mLkYuDiGB 9YwSl07+YYJwTjBKTNg1jRXEYRHoZZaY232OFSIzlUli15u9bBDOfUaJZ68XAw3g4GATsJF4 vNgPZK6IgKrElv4/bCC2sECQxKtZm1kg4sESJy9PYoSwjSSOrpwBZrMA1X/oWA5m8wpESby6 8ZYZxBYS8JN41LiNCcTmFPCXWLRwKthMRgExie+n1oDFmQXEJW49mc8E8Y+AxJI955khbFGJ l4//sULUJ0tM/drKBhFXkDg2YyULhO0rcfveY7DHJATmM0vMOv4LKuEqsePBeUYIO1Piy/9T 7BB2tMScZ7Oglm1jlOjYYw5hy0jMezkHqncXm8TsbVIQD6RKLF/byggJCCmJu1c6oWwZiRd3 9rJOYNScheSHWcBgZBbQlFi/Sx8irCgxpfsh+yxwsAhKnJz5hGUBI8sqRtHi1OKk3HQjI73U oszk4uL8PL281JJNjMAEcXDLb4MdjC+fOx5iFOBgVOLhTeAQihBiTSwrrsw9xCjBwawkwvsv XzhCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6pBsaUTIPl d4zncR5aaGov9unjZMn6c6rzlC3Zp2/SYH731fdv+FM57semhudV+jd4L9fReSJi2xocPnVa W3+Lxpr3W9QNlrmWh4nz5H0pC44Kjtjs+Er5dOZH0zcO29Sfv2BY8H2/VqqnoN6MT8tKU20n fWW6oWtfvjOw6IWVhGTw6debjkhua1JiKc5INNRiLipOBAB/D+zQDAMAAA== Archived-At: Subject: [rmcat] FW: New Version Notification for draft-dt-rmcat-feedback-message-01.txt 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, 28 Oct 2016 15:44:46 -0000 SGkgYWxsLA0KDQpUaGUgRFQgaGFzIHVwZGF0ZSB0aGUgZmVlZGJhY2sgbWVzc2FnZSBkcmFmdC4N Cg0KMS4gRml4ZWQgUlRDUCBYUiBmb3JtYXQsIHRvIHJlbW92ZSByZWR1bmRhbnQgU1NSQw0KMi4g QWRkZWQgUlRQL0FWUEYgdHJhbnNwb3J0IGxheWVyIGZlZWRiYWNrIHBhY2tldA0KMy4gUmVtb3Zl ZCBjb3VwbGUgb2YgRklYTUVzLCBhY2NvcmRpbmcgdG8gdGhlIGRlY2lzaW9uIGluIHRoZSBEVC4N Cg0KRW5qb3kuLi4NCg0KWmFoZWQgKG9uIGJlaGFsZiBvZiB0aGUgRGVzaWduIFRlYW0pDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogZGVuIDI4IG9rdG9iZXIg MjAxNiAxNzozNA0KVG86IE1pY2hhZWwgQS4gUmFtYWxobyA8bXJhbWFsaG9AY2lzY28uY29tPjsg TWljaGFlbCBSYW1hbGhvIDxtcmFtYWxob0BjaXNjby5jb20+OyBWYXJ1biBTaW5naCA8dmFydW4u c2luZ2hAaWtpLmZpPjsgWmFoZWR1enphbWFuIFNhcmtlciA8emFoZWR1enphbWFuLnNhcmtlckBl cmljc3Nvbi5jb20+OyBDb2xpbiBQZXJraW5zIDxjc3BAY3NwZXJraW5zLm9yZz47IFphaGVkdXp6 YW1hbiBTYXJrZXIgPHphaGVkdXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tPg0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdC1ybWNhdC1mZWVkYmFjay1tZXNz YWdlLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kdC1ybWNhdC1mZWVk YmFjay1tZXNzYWdlLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBa YWhlZHV6emFtYW4gU2Fya2VyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZToJCWRyYWZ0LWR0LXJtY2F0LWZlZWRiYWNrLW1lc3NhZ2UNClJldmlzaW9uOgkwMQ0KVGl0 bGU6CQlSVFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgRmVlZGJhY2sgZm9yIENvbmdlc3Rpb24g Q29udHJvbA0KRG9jdW1lbnQgZGF0ZToJMjAxNi0xMC0yOA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOgkJMTINClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZHQtcm1jYXQtZmVlZGJhY2stbWVzc2FnZS0wMS50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1k dC1ybWNhdC1mZWVkYmFjay1tZXNzYWdlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1kdC1ybWNhdC1mZWVkYmFjay1tZXNzYWdlLTAxDQpEaWZmOiAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWR0LXJtY2F0 LWZlZWRiYWNrLW1lc3NhZ2UtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBhIGZlZWRiYWNrIG1lc3NhZ2UgaW50ZW5kZWQgdG8gZW5hYmxlDQogICBjb25nZXN0aW9u IGNvbnRyb2wgZm9yIGludGVyYWN0aXZlIHJlYWwtdGltZSB0cmFmZmljLiAgVGhlIFJUUCBNZWRp YQ0KICAgQ29uZ2VzdGlvbiBBdm9pZGFuY2UgVGVjaG5pcXVlcyAoUk1DQVQpIFdvcmtpbmcgR3Jv dXAgZm9ybWVkIGEgZGVzaWduDQogICB0ZWFtIHRvIGFuYWx5emUgZmVlZGJhY2sgcmVxdWlyZW1l bnRzIGZyb20gdmFyaW91cyBjb25nZXN0aW9uIGNvbnRyb2wNCiAgIGFsZ29yaXRobXMgYW5kIHRv IGRlc2lnbiBhIGdlbmVyaWMgZmVlZGJhY2sgbWVzc2FnZSB0byBoZWxwIGVuc3VyZQ0KICAgaW50 ZXJvcGVyYWJpbGl0eSBhY3Jvc3MgdGhvc2UgYWxnb3JpdGhtcy4gIFRoZSBmZWVkYmFjayBtZXNz YWdlIGlzDQogICBkZXNpZ25lZCBmb3IgYSBzZW5kZXItYmFzZWQgY29uZ2VzdGlvbiBjb250cm9s LCB3aGljaCBtZWFucyB0aGUNCiAgIHJlY2VpdmVyIG9mIHRoZSBtZWRpYSB3aWxsIHNlbmQgbmVj ZXNzYXJ5IGZlZWRiYWNrIHRvIHRoZSBzZW5kZXIgb2YNCiAgIHRoZSBtZWRpYSB0byBwZXJmb3Jt IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgYXQgdGhlIHNlbmRlci4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K From nobody Sat Oct 29 09:50:23 2016 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 EFC8D129437 for ; Sat, 29 Oct 2016 09:50:21 -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, RCVD_IN_DNSWL_MED=-2.3] 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 n0j7vn2t9Cjy for ; Sat, 29 Oct 2016 09:50:17 -0700 (PDT) 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 A11E812953A for ; Sat, 29 Oct 2016 09:50:17 -0700 (PDT) X-Spam-Processed: mail.kau.se, Sat, 29 Oct 2016 18:50:10 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 213.113.183.137 X-MDArrival-Date: Sat, 29 Oct 2016 18:50:10 +0200 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" From: Anna Brunstrom Message-ID: <7f8ca1f8-aa8c-f49c-09be-2d81f496e849@kau.se> Date: Sat, 29 Oct 2016 18:50:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rmcat] Agenda items for Seoul? 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: Sat, 29 Oct 2016 16:50:22 -0000 Dear all, As you have seen we have a usual 2.5 hour slot reserved for rmcat at IETF Seoul (Thursday, Afternoon Session II 1520-1750). Please let us know your agenda requests asap indicating: 1: presenter's name 2: title 3: length of the presentation Thanks, Anna & Martin From nobody Mon Oct 31 02:16:32 2016 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 8A9731295A1; Mon, 31 Oct 2016 02:16:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147790539056.32501.10691854906681967775.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 02:16:30 -0700 Archived-At: Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-04.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 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, 31 Oct 2016 09:16:30 -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-04.txt Pages : 24 Date : 2016-10-31 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 both the NADA and Google congestion control algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rmcat-coupled-cc-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-coupled-cc-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 Oct 31 02:19:25 2016 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 4703B129593 for ; Mon, 31 Oct 2016 02:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.097 X-Spam-Level: X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 2g5U_O-I57ZC for ; Mon, 31 Oct 2016 02:19:22 -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 ED89D12943C for ; Mon, 31 Oct 2016 02:19:21 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c18kR-00074q-LC for rmcat@ietf.org; Mon, 31 Oct 2016 10:19:19 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1c18kR-0003Zg-6p for rmcat@ietf.org; Mon, 31 Oct 2016 10:19:19 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <147790539056.32501.10691854906681967775.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 10:19:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <975AF5E4-BCA5-46AA-A0F7-184BA7AAD526@ifi.uio.no> References: <147790539056.32501.10691854906681967775.idtracker@ietfa.amsl.com> To: rmcat WG X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 3 total rcpts 48088 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.055, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AC6EC5383F96FE2CA0F8BA30A950D9DEB236BE1A X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 11491 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-04.txt 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: Mon, 31 Oct 2016 09:19:24 -0000 Hi all, This update incorporates all the comments from WGLC (which all were = editorial). Cheers, Michael et al > On 31 Oct 2016, at 10:16, 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-04.txt > Pages : 24 > Date : 2016-10-31 >=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 both the NADA and Google > 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-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-coupled-cc-04 >=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 From nobody Mon Oct 31 10:12:17 2016 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 6117E129953; Mon, 31 Oct 2016 10:12:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147793392437.32477.9838772207060535210.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 10:12:04 -0700 Archived-At: Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-rtp-cc-feedback-02.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 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, 31 Oct 2016 17:12:04 -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 : RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences Author : Colin Perkins Filename : draft-ietf-rmcat-rtp-cc-feedback-02.txt Pages : 12 Date : 2016-10-31 Abstract: This memo discusses the types of congestion control feedback that it is possible to send using the RTP Control Protocol (RTCP), and their suitability of use in implementing congestion control for unicast multimedia applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-rtp-cc-feedback/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rmcat-rtp-cc-feedback-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-rtp-cc-feedback-02 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 Oct 31 10:20:46 2016 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 C535012986C for ; Mon, 31 Oct 2016 10:20:44 -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, RCVD_IN_DNSWL_MED=-2.3] 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 92UJ6w8NGIID for ; Mon, 31 Oct 2016 10:20:43 -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 28944129413 for ; Mon, 31 Oct 2016 10:20:43 -0700 (PDT) Received: from [130.209.254.20] (port=61646 helo=vpn20.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1c1GGH-0002MW-2N for rmcat@ietf.org; Mon, 31 Oct 2016 17:20:41 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <147793392437.32477.9838772207060535210.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 17:20:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147793392437.32477.9838772207060535210.idtracker@ietfa.amsl.com> To: rmcat WG X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-rtp-cc-feedback-02.txt 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: Mon, 31 Oct 2016 17:20:45 -0000 Hi, This version of the draft expands the discussion of RTCP feedback = requirements for video conferencing scenarios, and adds some analysis of = VoIP scenarios. It also updates the security considerations, and = includes various editorial fixes throughout. Colin > On 31 Oct 2016, at 17:12, 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 : RTP Control Protocol (RTCP) Feedback for = Congestion Control in Interactive Multimedia Conferences > Author : Colin Perkins > Filename : draft-ietf-rmcat-rtp-cc-feedback-02.txt > Pages : 12 > Date : 2016-10-31 >=20 > Abstract: > This memo discusses the types of congestion control feedback that it > is possible to send using the RTP Control Protocol (RTCP), and their > suitability of use in implementing congestion control for unicast > multimedia applications. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rmcat-rtp-cc-feedback/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rmcat-rtp-cc-feedback-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-rtp-cc-feedback-02 >=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/