From nobody Thu Nov 2 14:53:12 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 C45AD13F69E for ; Thu, 2 Nov 2017 14:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, SPF_PASS=-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 ns_BU61jbIj6 for ; Thu, 2 Nov 2017 14:53:09 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25B4136934 for ; Thu, 2 Nov 2017 14:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4237; q=dns/txt; s=iport; t=1509659588; x=1510869188; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XIXciGzStVoBOFv7P/uajK6xAHmKCln6WH+aFEtOeXM=; b=LOCSFMAXlShh2kGmFzSgQYxmXVow49q3z+RPpwbwkZW3XoP+mFApdf72 5RJn8iavt5qow+3m2bWiQqAN+Gt8a3hKEDl+yN1kh+aOae2dKFrAvvd/o 9YN+LZfqWQZBhxeJqedvLvPO8oLFsZOp6gL2TjncTlEE64QwD+vE26wrG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAQD+kvtZ/5pdJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM0gVInB4ZCmGuEKwEClCgKhTsChFBCFQEBAQEBAQEBAWsohR0?= =?us-ascii?q?BAQEBA2ciAgEIEQQBAQolDyMdCAIEARKKI6tcixYBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBH4MuggeBU4FpgyqEaieFdwWSK49iAotLiS+CFYYDhASHFootizwCERkBgTg?= =?us-ascii?q?BNSJCgSp6FYMthCA/d4p+gTOBEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,335,1505779200"; d="scan'208";a="25426830" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 21:53:08 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA2Lr8Mn030130 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Nov 2017 21:53:08 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 2 Nov 2017 16:53:07 -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.1320.000; Thu, 2 Nov 2017 16:53:07 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "Bless, Roland (TM)" , "rmcat@ietf.org" Thread-Topic: [rmcat] I-D Action: draft-ietf-rmcat-nada-05.txt Thread-Index: AQHTVBPRFiiyxrx370amnNiaIgFkww== Date: Thu, 2 Nov 2017 21:53:07 +0000 Message-ID: <1509659647876.73468@cisco.com> References: <150663456501.27767.1526687431255447082@ietfa.amsl.com> <1506635454282.84079@cisco.com>, <408446c4-9fec-9582-159a-622dedb1d5f6@kit.edu> In-Reply-To: <408446c4-9fec-9582-159a-622dedb1d5f6@kit.edu> 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.24.163.233] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-nada-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, 02 Nov 2017 21:53:11 -0000 Hi Roland,=0A= =0A= Thanks much for reading our draft and for providing your comments. =0A= =0A= Please see answers to your questions below inline, marked [XZ]. In general= , these are very valuable comments/critiques, and we'll address them accord= ingly in the next revision for better clarity of the draft. =0A= =0A= Thanks!=0A= Xiaoqing=0A= =0A= ________________________________________=0A= From: Bless, Roland (TM) =0A= Sent: Friday, October 27, 2017 10:04 AM=0A= To: Xiaoqing Zhu (xiaoqzhu); rmcat@ietf.org=0A= Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-nada-05.txt=0A= =0A= Hi,=0A= =0A= I just read draft-ietf-rmcat-nada-05.txt for the first time and have=0A= some (probably dumb) questions (mainly related to the delay-based part):=0A= - The draft mentions a "15-tap minimum filter" (p. 12) and a=0A= "15-tab minimum filter" (p. 16). One of the seems to contain=0A= a type. Moreover, I have no clue what that actually is.=0A= Is it simply a minimum filter over the last 15 measured=0A= values?=0A= =0A= [XZ] Thanks for catching the typo. They were meant to be "15-tab minimum = filter", meaning taking the minimum value of the previous 15 measured value= s. I just realized that this is not a standard term, will re-word to "mini= mum filter with a window size of 15" in the next revision. =0A= =0A= =0A= - The description in 4.2 states:=0A= update baseline delay: d_base =3D min(d_base, d_fwd)=0A= is this where the minimum filter is applied? If so=0A= better use min_filtered(d_base, d_fwd) and define=0A= what that is.=0A= =0A= [XZ] Your understanding is correct. Agree that your proposed description = (explicitly calling out the filtering option) is more precise. Will change= accordingly. =0A= =0A= - 4.3 mentions "base delay expiration", but I wasn't able=0A= to find a discussion in section 5 about it.=0A= =0A= [XZ] The mention of "base delay expiration" refers to the potential scenari= o where an earlier measured base delay value may no longer be valid, e.g., = due to underlying route change, and therefore the need to maintain a limite= d history window for estimating base delay. This has been discussed in oth= er drafts on delay-based scheme such as LEDBAT (Sec. 5.2 of RFC 6817) and n= ot specific to NADA. I can add a brief discussion of this in Section 5 in = the next revision. =0A= =0A= - 5.1.1: "All delay estimations are based on sender timestamps with=0A= higher granularity than RTP timestamps."=0A= =0A= I'm not sure. RTP timestamps depend on the sampling clock frequency=0A= and this can be quite high, e.g., 8kHz corresponds to 125=B5s, 90kHz=0A= to 11=B5s. System clock resolution can be in the range of microseconds=0A= and sometimes even nanoseconds. So more interesting would be to state=0A= what minimum resolution the sender timestamps should have.=0A= =0A= [XZ] Thanks for raising this point. Based on our experimentation experienc= e, a timestamp accuracy on the order of 100=B5s. Agree that it will be more= informative to state the recommended timer resolution (we haven't carried = out sufficient experiments to state a minimum, will stick to what we know) = in the draft. =0A= =0A= - 6.3 "that a feedback interval below 250ms will not break=0A= up the feedback control loop of NADA congestion control."=0A= =0A= This is not clear to me. Does a "feedback interval below 250ms"=0A= mean a smaller interval and thus more frequent feedback?=0A= "feedback below 250 ms" could also mean slower and less frequent=0A= feedback.=0A= If so, I don't understand why more frequent feedback would=0A= "break up the feedback control loop". An unambiguous=0A= statement would be better.=0A= =0A= =0A= [XZ] Apologies for the confusion. By "feedback interval below 250ms" we m= ean feedback intervals smaller than 250ms, i.e., more frequent feedback. T= he word "interval" is kind of crucial here, but probably not sufficiently r= obust. I can revise it (e.g., by adding an equivalent term on "more freque= nt interval") in the next version to avoid such potential ambiguity. =0A= =0A= =0A= Regards,=0A= Roland=0A= From nobody Sun Nov 12 20:33:48 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 5B15C1293EC for ; Sun, 12 Nov 2017 20:33:47 -0800 (PST) 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, 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 iJa71c7WOtM5 for ; Sun, 12 Nov 2017 20:33:45 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 4AD91128DE5 for ; Sun, 12 Nov 2017 20:33:45 -0800 (PST) Received: from [66.96.212.196] (port=51215 helo=[10.0.0.254]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eE6RL-0003lA-AJ; Mon, 13 Nov 2017 04:33:43 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: Date: Mon, 13 Nov 2017 12:33:33 +0800 Cc: "rmcat@ietf.org" , Zaheduzzaman Sarker , "varun.singh@iki.fi" , "mramalho@cisco.com" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150913051158.22299.4504001911028448869@ietfa.amsl.com> To: Ingemar Johansson S X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [rmcat] I-D Action: draft-dt-rmcat-feedback-message-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, 13 Nov 2017 04:33:47 -0000 > On 30 Oct 2017, at 15:35, Ingemar Johansson S = wrote: >=20 > Hi >=20 > Read through the draft and I believe that I understand how it should = be implemented and when time permits I will replace the home-brewn RTCP = feedback that is currently used with SCReAM with the version that is = specified in the dt draft. >=20 > There are a few questions though. > 1) Arrival time offset (ATO) and Report timestamp (RTS): The time = granularity of the ATO is 1ms while the time granularity of the RTS = seems to be 0.1ms or can even be configurable?. Is there any reason to = have a differing time granularity for ATO and RTS? We need to define these more carefully, but I agree that ideally they = have the same units. The obvious unit for Report Timestamp would be the = middle 32 bits out of 64 in the NTP timestamp, as used in the LSR field = of SR packets. That doesn=E2=80=99t map so nicely to the 13 bit ATO = field though, unless we make it count 1/1024 of a second ticks rather = than 1/1000. > 2) Byte order for ATO and RTS is not specified. I guess it should be = network byte order for both RTS and ATO, right ?.=20 Right. Colin --=20 Colin Perkins https://csperkins.org/ From nobody Sun Nov 12 22:41:47 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 85318124B18 for ; Sun, 12 Nov 2017 22:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=callstats.io 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 1-fxouRglR8X for ; Sun, 12 Nov 2017 22:41:43 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 6E1111200C1 for ; Sun, 12 Nov 2017 22:41:43 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id e143so17050924lfg.12 for ; Sun, 12 Nov 2017 22:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=Xjql9L5v/qB3FyE6LgxAwTxCEuaCJjK1UNzePEXDLI4=; b=lcwVUoaNpfjODFPcH99eRuEdrAdX9FXE+U1Uyx06Sxr2nLwrGOVz58eNwUAn7hyViL OG93jB9mCnjb4wopLfRX+BMmrB3aTisCnnwcsImIDe/Mw/vvEwluLZkWqSa7krhcpvnJ w0N9RyLKNp8bCejeNKnTMWsM/472aYM4iySkE= 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:cc; bh=Xjql9L5v/qB3FyE6LgxAwTxCEuaCJjK1UNzePEXDLI4=; b=HL6tzN1jLuqNPYrmlatgwB8WBEHqQL5y4hOIzRUuPH2qYs1h4ULdHpib74lwNm+YMk 8eRYRn2Qnxltr8056rLv1ZyjPlJWWqv6EYkmd0lCjiZttHACB2JG05RgB5Fl+yz4IZVb uKOPOegnH4mcLFidGjmAuq7I+Zm3iA71nOriknXl6WClyNarRLra8PhNoBPxIh6wVa1v QBlHQlIR2FCiFSjS7pAudmqJcGWVtd+zJUVs7McWQnrxzH9OnmPLtx6217SS1CTbgreP XXwFvm6lSKgZrSht4iJ7zmEN9P4W1hfmKyzDnjpsfzADtMxe9A+dNSK2WWQhuektzDHB N7Fw== X-Gm-Message-State: AJaThX44mWg/183hxrNUT2DEbejlBmMv2M41TCYIVgByJ0i1vUKVKkzh e0B/KkYcIEXaPw2DTTpFpKERxgsC1Cua4pBL6w6g4Q== X-Google-Smtp-Source: AGs4zMYrt1sLJEZ8w+iRFlFV26EsOTLPRG/4wTJFmE37oW4iviJlFrZmPAdCfP9ouXRBNk6zkf01wJ/b2LgU42smNbw= X-Received: by 10.25.145.30 with SMTP id t30mr2459461lfd.247.1510555301625; Sun, 12 Nov 2017 22:41:41 -0800 (PST) MIME-Version: 1.0 From: Varun Singh Date: Mon, 13 Nov 2017 06:41:30 +0000 Message-ID: To: Zaheduzzaman Sarker , "rmcat@ietf.org" Cc: Colin Perkins Content-Type: multipart/alternative; boundary="94eb2c1cd0e62adc53055dd790a3" Archived-At: Subject: [rmcat] Parameters for congestion control 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, 13 Nov 2017 06:41:45 -0000 --94eb2c1cd0e62adc53055dd790a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Was there a study done for the parameters needed for congestion control? I know we debated this at length, were there slides created by the congestion control proponents, that I can reference. >From the top of my head, I remember there=E2=80=99s + priority (needed by coupled congestion control) I=E2=80=99m asking this for w3c input. They already have max bitrate, max framearte, and degradation preference degradation preference indicates where the bits should be allocated: in maintaining frame rates or frame sizes. Feedback is appreciated To make sure we didn=E2=80=99t miss anything. Cheers, Varun. --=20 Founder, CEO, callstats.io http://www.callstats.io Interested in networking, media quality, and diagnostics. We are hiring!: www.callstats.io/jobs/ --94eb2c1cd0e62adc53055dd790a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Wa= s there a study done for the parameters needed for congestion control? I kn= ow we debated this at length, were there slides created by =C2=A0the conges= tion control proponents, that I can reference.=C2=A0

From the top of my head, I remember there=E2= =80=99s=C2=A0
+ priority (needed by coupled congesti= on control)

I=E2=80=99m = asking this for w3c input. They already have max bitrate, max framearte, an= d degradation preference =C2=A0degradation preference indicates where the b= its should be allocated: in maintaining frame rates or frame sizes.=C2=A0

Feedback is appreciated T= o make sure we didn=E2=80=99t miss anything.

Cheers,
Varun.=C2=A0
--
Founder, CEO, callstats.io

Interested in networking,= media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/
--94eb2c1cd0e62adc53055dd790a3-- From nobody Sun Nov 12 22:51:35 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 9F06412008A for ; Sun, 12 Nov 2017 22:51:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=vidyo-com.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 9oAbqehaAlgp for ; Sun, 12 Nov 2017 22:51:30 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 9ADDB1292C5 for ; Sun, 12 Nov 2017 22:51:30 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id n89so11204826pfk.11 for ; Sun, 12 Nov 2017 22:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mGrmor/YopIy6TwKxmHszqB9AEMpyvZFQ59p/ifPpgA=; b=1ckVBg69xmJQUBKMd4DTbRsowamgZyoMLSoNVoxMzH182L0S2CeZyRQ0uOAJU4XeR6 Mqkf/uYlD9r3PFKyUBGoSioEpbl1rzqORj6Q9Kb2IsktPTYfSx+utK9wm8i0OVio/c5X 5pN8KCH77bvtdu6jaxMwKMIxOLxo7c5rV67p6+3xa/dDVdoOcpAfVdt8xVGv9fJRuZ/Q uV/qyVIa5tk094pxO5VCXST//ZpaawippBWdiWMXopDpYT9CMzDP5I9d7SqtBYyqfklC 7THsuiFatX38bg+7Mnl/D3So+VJ9O25oGJE67ZFsla+WmQU4C9FRcxp/Uw9XpObzXIrh hmJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mGrmor/YopIy6TwKxmHszqB9AEMpyvZFQ59p/ifPpgA=; b=lftridUtV97+Ynu5DTtVjhq3KQnZNC+BE/dzRdxQXH4Z6HeSpGJhv/Pe3oV0iYW2Mq Wtg6EeeTPymqwhe7jHCP9upd6SjcO0e1q9OcJwjz3LLW63MOClgsFPzZ5FKfqC3Di+G9 guKZQuRVdmkKtfCJTKNtTiNa22E58yHB0jo+36bss/LzNkoNWVM9g+DNpL0OoMaBYHbn 7E64RnaaOI4hx2C9IJv3AY3ngkHk4fxf42x9K2fBMQysk3TxmjOPyUEXLkBlf5FGOX6a UHYeW9abk/bYd4ZtsfeF33TLH/lPuJHh6zkT1O3j+Y24n+N+tGf5PR3H2e/QxcSDRkaL cs/g== X-Gm-Message-State: AJaThX4smnIs8D50Bp0f3t8ozoCZaXKYd0JzfCAfeVBxz/k1utAeuvdP YXYgvbEloG+0j6iRR9ovER8jYQ== X-Google-Smtp-Source: AGs4zMZcMFaC+rvQeknYvmKmIzPfGhe3VC7OjLVhekFSBUfFCd0hrwwunxQT57OqwCvrpvd5Sia8JA== X-Received: by 10.99.127.91 with SMTP id p27mr6896082pgn.1.1510555890234; Sun, 12 Nov 2017 22:51:30 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:ed0d:3546:761f:c4d5? ([2001:67c:1232:144:ed0d:3546:761f:c4d5]) by smtp.gmail.com with ESMTPSA id 84sm30444166pfy.179.2017.11.12.22.51.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 22:51:29 -0800 (PST) From: Jonathan Lennox Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_344783BB-C939-4402-9C4B-F71B651CC567" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 14:51:26 +0800 In-Reply-To: Cc: Ingemar Johansson S , "rmcat@ietf.org" , Zaheduzzaman Sarker , "Michael Ramalho (mramalho)" , "varun.singh@iki.fi" , IETF AVTCore WG To: Colin Perkins References: <150913051158.22299.4504001911028448869@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rmcat] I-D Action: draft-dt-rmcat-feedback-message-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, 13 Nov 2017 06:51:33 -0000 --Apple-Mail=_344783BB-C939-4402-9C4B-F71B651CC567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since this draft is now draft-ietf-avtcore-cc-feedback-message, it=E2=80=99= d be better to move this discussion to avt@ietf.org = . Thanks! Jonathan (AVTCore chair)=20 > On Nov 13, 2017, at 12:33 PM, Colin Perkins wrote: >=20 >=20 >> On 30 Oct 2017, at 15:35, Ingemar Johansson S = wrote: >>=20 >> Hi >>=20 >> Read through the draft and I believe that I understand how it should = be implemented and when time permits I will replace the home-brewn RTCP = feedback that is currently used with SCReAM with the version that is = specified in the dt draft. >>=20 >> There are a few questions though. >> 1) Arrival time offset (ATO) and Report timestamp (RTS): The time = granularity of the ATO is 1ms while the time granularity of the RTS = seems to be 0.1ms or can even be configurable?. Is there any reason to = have a differing time granularity for ATO and RTS? >=20 > We need to define these more carefully, but I agree that ideally they = have the same units. The obvious unit for Report Timestamp would be the = middle 32 bits out of 64 in the NTP timestamp, as used in the LSR field = of SR packets. That doesn=E2=80=99t map so nicely to the 13 bit ATO = field though, unless we make it count 1/1024 of a second ticks rather = than 1/1000. >=20 >> 2) Byte order for ATO and RTS is not specified. I guess it should be = network byte order for both RTS and ATO, right ?.=20 >=20 > Right. >=20 > Colin >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ --Apple-Mail=_344783BB-C939-4402-9C4B-F71B651CC567 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Since this draft is now = draft-ietf-avtcore-cc-feedback-message, it=E2=80=99d be better to move = this discussion to avt@ietf.org.  Thanks!

Jonathan (AVTCore chair) 

On = Nov 13, 2017, at 12:33 PM, Colin Perkins <csp@csperkins.org> = wrote:


On 30 Oct = 2017, at 15:35, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi

Read through = the draft and I believe that I understand how it should be implemented = and when time permits I will replace the home-brewn RTCP feedback that = is currently used with SCReAM with the version that is specified in the = dt draft.

There are a few questions = though.
1)  Arrival time offset (ATO) and Report = timestamp (RTS): The time granularity of the ATO is 1ms while the time = granularity of the RTS seems to be 0.1ms or can even be configurable?. = Is there any reason to have a differing time granularity for ATO and = RTS?

We need to define these = more carefully, but I agree that ideally they have the same units. The = obvious unit for Report Timestamp would be the middle 32 bits out of 64 = in the NTP timestamp, as used in the LSR field of SR packets. That = doesn=E2=80=99t map so nicely to the 13 bit ATO field though, unless we = make it count 1/1024 of a second ticks rather than 1/1000.

2) Byte = order for ATO and RTS is not specified. I guess it should be network = byte order for both RTS and ATO, right ?.

Right.

Colin



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

= --Apple-Mail=_344783BB-C939-4402-9C4B-F71B651CC567-- From nobody Mon Nov 13 00:44: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 70E02128BA2 for ; Mon, 13 Nov 2017 00:44:57 -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, 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 5T_tM-gUZ4yd for ; Mon, 13 Nov 2017 00:44:54 -0800 (PST) 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 B3A0B126B6E for ; Mon, 13 Nov 2017 00:44:54 -0800 (PST) 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 1eEAMO-000FwC-T7; Mon, 13 Nov 2017 09:44:52 +0100 Received: from dhcp-82c4.meeting.ietf.org ([31.133.130.196]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eEAMN-0003Xn-Fo; Mon, 13 Nov 2017 09:44:52 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_35CB4AC0-0F07-4A4C-A424-1B6FCF03C9EE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 16:44:46 +0800 In-Reply-To: Cc: Zaheduzzaman Sarker , "rmcat@ietf.org" , Colin Perkins To: Varun Singh References: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 31.133.130.196 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.130.196; envelope-from=michawe@ifi.uio.no; helo=dhcp-82c4.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.063, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B4A4F130CA9DD9CB2D94DDC4C27E959BD6DEB93B Archived-At: Subject: [rmcat] Priority and rtcweb 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, 13 Nov 2017 08:44:57 -0000 --Apple-Mail=_35CB4AC0-0F07-4A4C-A424-1B6FCF03C9EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Can I hijack this thread to talk about priority? There was a thread about priority in rtcweb - someone asking for a = float=E2=80=A6 coupled-cc can easily support a float, but Harald=E2=80=99s= transport draft doesn=E2=80=99t support it. Opinions went back and = forth for a bit... I think we should get more WebRTC deployment and not more debate on = small details that delays the work, so I don=E2=80=99t want to be a = troublemaker and didn=E2=80=99t interfere with this discussion. But, what is the view of people in rmcat about this? Cheers, Michael > On Nov 13, 2017, at 2:41 PM, Varun Singh wrote: >=20 > Hi, >=20 > Was there a study done for the parameters needed for congestion = control? I know we debated this at length, were there slides created by = the congestion control proponents, that I can reference.=20 >=20 > =46rom the top of my head, I remember there=E2=80=99s=20 > + priority (needed by coupled congestion control) >=20 > I=E2=80=99m asking this for w3c input. They already have max bitrate, = max framearte, and degradation preference degradation preference = indicates where the bits should be allocated: in maintaining frame rates = or frame sizes.=20 >=20 > Feedback is appreciated To make sure we didn=E2=80=99t miss anything. >=20 > Cheers, > Varun.=20 > --=20 > Founder, CEO, callstats.io > http://www.callstats.io >=20 > Interested in networking, media quality, and diagnostics. > We are hiring!: www.callstats.io/jobs/ --Apple-Mail=_35CB4AC0-0F07-4A4C-A424-1B6FCF03C9EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Can I hijack this thread to talk about priority?

There was a thread about = priority in rtcweb - someone asking for a float=E2=80=A6 coupled-cc can = easily support a float, but Harald=E2=80=99s transport draft doesn=E2=80=99= t support it. Opinions went back and forth for a bit...
I think we should get more WebRTC deployment and not more = debate on small details that delays the work, so I don=E2=80=99t want to = be a troublemaker and didn=E2=80=99t interfere with this = discussion.
But, what is the view of people in = rmcat about this?

Cheers,
Michael


On Nov 13, 2017, at 2:41 PM, = Varun Singh <varun@callstats.io> wrote:

Hi,

Was there a study done for the parameters = needed for congestion control? I know we debated this at length, were = there slides created by  the congestion control proponents, that I = can reference. 

=46rom the top of my head, = I remember there=E2=80=99s 
+ = priority (needed by coupled congestion control)

I=E2=80=99m = asking this for w3c input. They already have max bitrate, max framearte, = and degradation preference  degradation preference indicates where = the bits should be allocated: in maintaining frame rates or frame = sizes. 

Feedback is appreciated To make sure we didn=E2=80= =99t miss anything.

Cheers,
Varun. 
-- =
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media = quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/

= --Apple-Mail=_35CB4AC0-0F07-4A4C-A424-1B6FCF03C9EE-- From nobody Mon Nov 13 00:47:50 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 5BDBF128BA2 for ; Mon, 13 Nov 2017 00:47:49 -0800 (PST) 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 dcmAqdmEkg1Y for ; Mon, 13 Nov 2017 00:47:47 -0800 (PST) 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 3F2D4126B6E for ; Mon, 13 Nov 2017 00:47:47 -0800 (PST) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eEAPB-00065N-3l for rmcat@ietf.org; Mon, 13 Nov 2017 09:47:45 +0100 Received: from dhcp-82c4.meeting.ietf.org ([31.133.130.196]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eEAPA-0004q5-FJ for rmcat@ietf.org; Mon, 13 Nov 2017 09:47:45 +0100 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <440EBA4E-CD3E-4434-A475-C880D9DFD815@ifi.uio.no> Date: Mon, 13 Nov 2017 16:47:41 +0800 To: rmcat@ietf.org X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 31.133.130.196 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.130.196; envelope-from=michawe@ifi.uio.no; helo=dhcp-82c4.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.058, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 889AE024F4F0720D941B62B86793656EDF5C82DD Archived-At: Subject: [rmcat] RMCAT, quo vadis? 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, 13 Nov 2017 08:47:49 -0000 Hi, I=E2=80=99m getting the impression that rmcat is ignored in WebRTC, and = I don=E2=80=99t think that=E2=80=99s a good development. The rtcweb = overview draft ( draft-ietf-rtcweb-overview-19.txt ) has just been = approved as a Proposed Standard, but it doesn=E2=80=99t mention RMCAT at = all. Will people find our documents? Are we going to be ignored by = design? There=E2=80=99s also this interesting sentence towards the end of the = SIGCOMM 2017 paper on QUIC: "Third, we are working on using QUIC for WebRTC [4] and intend to = explore avenues for better supporting real-time payloads.=E2=80=9D What do people think about these matters? Cheers, Michael From nobody Mon Nov 13 01:03:22 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 5822D126CC4 for ; Mon, 13 Nov 2017 01:03:20 -0800 (PST) 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, 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 VgkbCrcLbEqr for ; Mon, 13 Nov 2017 01:03:18 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 9600012426E for ; Mon, 13 Nov 2017 01:03:18 -0800 (PST) Received: from [2001:67c:370:128:6944:b75a:342:f80c] (port=61687) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eEAeC-0000TA-NN; Mon, 13 Nov 2017 09:03:17 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <440EBA4E-CD3E-4434-A475-C880D9DFD815@ifi.uio.no> Date: Mon, 13 Nov 2017 17:03:10 +0800 Cc: rmcat@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <440EBA4E-CD3E-4434-A475-C880D9DFD815@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [rmcat] RMCAT, quo vadis? 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, 13 Nov 2017 09:03:20 -0000 > On 13 Nov 2017, at 16:47, Michael Welzl wrote: >=20 > I=E2=80=99m getting the impression that rmcat is ignored in WebRTC, = and I don=E2=80=99t think that=E2=80=99s a good development. The rtcweb = overview draft ( draft-ietf-rtcweb-overview-19.txt ) has just been = approved as a Proposed Standard, but it doesn=E2=80=99t mention RMCAT at = all. Will people find our documents? Are we going to be ignored by = design? It=E2=80=99s an intentional choice, since the WebRTC work is = significantly ahead of the RMCAT drafts in the process. Section 7 of = draft-ietf-rtcweb-rtp-usage-26 discusses a little, and is normative for = WebRTC implementations. > There=E2=80=99s also this interesting sentence towards the end of the = SIGCOMM 2017 paper on QUIC: > "Third, we are working on using QUIC for WebRTC [4] and intend to = explore avenues for better supporting real-time payloads.=E2=80=9D >=20 > What do people think about these matters? Some thoughts in draft-rtpfolks-quic-rtp-over-quic-01 and = draft-aboba-avtcore-quic-multiplexing-01 (the latter is being discussed = this week). --=20 Colin Perkins https://csperkins.org/ From nobody Mon Nov 13 01:11: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 02085126B6E for ; Mon, 13 Nov 2017 01:11:11 -0800 (PST) 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, 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 OoWUhBucF8Cl for ; Mon, 13 Nov 2017 01:11:08 -0800 (PST) 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 5C7D3129483 for ; Mon, 13 Nov 2017 01:11:08 -0800 (PST) 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 1eEAlm-0002ln-Pq; Mon, 13 Nov 2017 10:11:06 +0100 Received: from dhcp-82c4.meeting.ietf.org ([31.133.130.196]) 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 1eEAll-0004OF-LY; Mon, 13 Nov 2017 10:11:06 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: Date: Mon, 13 Nov 2017 17:11:01 +0800 Cc: rmcat@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <440EBA4E-CD3E-4434-A475-C880D9DFD815@ifi.uio.no> To: Colin Perkins X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 31.133.130.196 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.130.196; envelope-from=michawe@ifi.uio.no; helo=dhcp-82c4.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 15E139E7A9D35968B78F96373445FEDE106C17FF Archived-At: Subject: Re: [rmcat] RMCAT, quo vadis? 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, 13 Nov 2017 09:11:11 -0000 This is all very enlightening, thanks!! > On Nov 13, 2017, at 5:03 PM, Colin Perkins wrote: >=20 >> On 13 Nov 2017, at 16:47, Michael Welzl wrote: >>=20 >> I=E2=80=99m getting the impression that rmcat is ignored in WebRTC, = and I don=E2=80=99t think that=E2=80=99s a good development. The rtcweb = overview draft ( draft-ietf-rtcweb-overview-19.txt ) has just been = approved as a Proposed Standard, but it doesn=E2=80=99t mention RMCAT at = all. Will people find our documents? Are we going to be ignored by = design? >=20 > It=E2=80=99s an intentional choice, since the WebRTC work is = significantly ahead of the RMCAT drafts in the process. Section 7 of = draft-ietf-rtcweb-rtp-usage-26 discusses a little, and is normative for = WebRTC implementations. >=20 >> There=E2=80=99s also this interesting sentence towards the end of the = SIGCOMM 2017 paper on QUIC: >> "Third, we are working on using QUIC for WebRTC [4] and intend to = explore avenues for better supporting real-time payloads.=E2=80=9D >>=20 >> What do people think about these matters? >=20 >=20 > Some thoughts in draft-rtpfolks-quic-rtp-over-quic-01 and = draft-aboba-avtcore-quic-multiplexing-01 (the latter is being discussed = this week). >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 From nobody Mon Nov 13 01:52:47 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 47AEE128AB0 for ; Mon, 13 Nov 2017 01:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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=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 O6URT6f_Dccc for ; Mon, 13 Nov 2017 01:52:43 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 C209412762F for ; Mon, 13 Nov 2017 01:52:42 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id 73so3247960lfu.10 for ; Mon, 13 Nov 2017 01:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=ca6Mv2gSCGYnUoAVAfU8265sIewfX1TzyV8pqJE7Jm8=; b=epyNy0me/Hca0jMSGpscJrKEOA5q6zBbOrAeFZFJASrZ9noIO567MfY5ori8T+Y85j KYtWx1tV9vweMRt8fxalDVBwIcfz/b/iFi754enIzHVT7Z+Zi9Kfqtbx+nbE9RMxF9f2 iRuC0NNyRRjSGMOctfaICgPMT0MoRfF9d8zlNAWnKsMIACoNmI96OCbvbb/3wP2w6JCU 45NGLeqgp02p+KK48duujbk7iKhc3fjrefC+snJghTI8O7Ecg9LTyqmt+1imXm3EUzmD DGbv4Jy6+y0g5u0vxMOYl8Qm8YX2m50EvBEuepDoVbCyeUAZinawek8hN8/A0ig3XNK4 FuBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=ca6Mv2gSCGYnUoAVAfU8265sIewfX1TzyV8pqJE7Jm8=; b=TeBaCt6awOXfqyjeKWZ0KuQkyA4AfO2iEVmg9EcZRFB94a7cPdgdI6ks7lAGP8QGp1 uVb/yQaQoB9T8YGzX+sQQbWgdMU69FHmRgzPyPw+GeX34k2StgCI9rhASqVtFtANcqkB lxH8t4V8sS8QcybSywbfTurdnj7VwoMSb1Lxa2GMSkE7sGhTK0nrah9yEUvF+dSxjs9s dLcqQU4RyrmXRSn7Ra38d0RCM379yhCCzFWWaApwaHXBQJAP8cTbaQvLCuJew9Bge1lH WdiFq4QvSwkVJWidT+gcJPzkGw/gdWOqYqZA0sdHHF0ZisO31evMnT1gPKZjixhpFmYB ZU8Q== X-Gm-Message-State: AJaThX77kHtXq1D8K4R6xJPlRje4vR+4r/Uxez1fiIsC/icQILpinGpR 4xuhM+hgAVrwvNXRJbRmZF08Iw== X-Google-Smtp-Source: AGs4zManx8SQ25SiYlwqpvup/2ifKwEiIuYRLwgbUIGXGWTT5wq6mOIDbqRpgwG34AwRoKM4di76fQ== X-Received: by 10.46.42.196 with SMTP id q187mr2877424ljq.59.1510566760547; Mon, 13 Nov 2017 01:52:40 -0800 (PST) Received: from ?IPv6:2003:74:cf3f:7155:cc89:d600:387d:7866? (p200300061373C155CC89D600387D7866.dip0.t-ipconnect.de. [2003:6:1373:c155:cc89:d600:387d:7866]) by smtp.googlemail.com with ESMTPSA id i23sm2799918lfh.64.2017.11.13.01.52.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 01:52:39 -0800 (PST) To: "rmcat WG (rmcat@ietf.org)" From: Martin Stiemerling Message-ID: Date: Mon, 13 Nov 2017 10:52:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rmcat] Slides for RMCAT@IETF-100 session due! 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, 13 Nov 2017 09:52:44 -0000 Dear presenters, Please send your draft slides for the RMCAT@IETF-100 session to the chairs not later than Tuesday 11/14 1pm Singapore time. Thanks, Martin From nobody Mon Nov 13 01:52:53 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 584391294EF for ; Mon, 13 Nov 2017 01:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 Fp2XudXpUoP3 for ; Mon, 13 Nov 2017 01:52:46 -0800 (PST) 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 CF72212762F for ; Mon, 13 Nov 2017 01:52:45 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id e143so17584128lfg.12 for ; Mon, 13 Nov 2017 01:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=JXb1+zHdbyLG855PEdgUeSu56BLEez9MurjxHHaH1dE=; b=W1B2dc7KhLQuVfLZ1fX2aG9IT74NMiECnXVZrVkM/xCS1QweFbGnRnUuLFgRuuTzLj 8FUHBg0hl/UEdbQn3usCE9emABK4rCCLHe6A28VWn+j5rdANLiRWDylDGE1bAVcCumZO Xux5hLr6j9LF1RiTcprf7Q2eAzGaJFsSy+Ere19EJNRpxlAHVF3iUjp1Rw+dPaMxYu9N KWiYCJSNa/auYNsCUL3tNlo0OhFAwN2H9/wVGyIJOcXr2CS1MWSmtdJl3WvyJq4A/KVc VwXMi9YKMnyydE0hi0+gr+ZKBW4daasLdshm65V9TAhMEL9ngX84eAdB0gtFSEHp5nSR i+Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=JXb1+zHdbyLG855PEdgUeSu56BLEez9MurjxHHaH1dE=; b=CkhSeup7w8knFBSubN3hJ0UoTriPT5+Z7SvB7VxYBzT+tdOeKwmRfMO0nv+Cn8l189 MVAQamhIfJi6MiIv3aOol4/m2Kdm49HmeavYQXvCJgktCNAxHbOcaH7JDhZaALZ5ZwlB M1yaljJ37TsuVY7wV0OTt2IfHiTyNp1qtkit4ILnM91tk4XtAnck/yxgotaAh8NBP4CJ 3xzCD37v7oMSqfUHraVhAqrvAGm3mtD0S3Sa/tbYdzgdzkewgdmpvfl83EDOx8UvreWr NUxhGlA+FH3zXsRaguulgEOcJgyKkEh6uLlj2NL06A0X5lL+rcwYH5iYmXqaxTjUYz6H 6B6w== X-Gm-Message-State: AJaThX7YEJYh+6gYxpZ/bOxffzzbhcdy7xWkl78XJTTca7AStqIzJO1n /wQQlO154zwWjviz91uUYBre/Q== X-Google-Smtp-Source: AGs4zMbRl2Fnm/T86KBE129HiYmXUDDyoi3QEaY08ktWPgxJaNhgEJ9G676/1g46Uf/FgbNWltcVXQ== X-Received: by 10.46.83.25 with SMTP id h25mr3054802ljb.158.1510566763918; Mon, 13 Nov 2017 01:52:43 -0800 (PST) Received: from ?IPv6:2003:74:cf3f:7155:cc89:d600:387d:7866? (p200300061373C155CC89D600387D7866.dip0.t-ipconnect.de. [2003:6:1373:c155:cc89:d600:387d:7866]) by smtp.googlemail.com with ESMTPSA id r84sm3079457ljb.28.2017.11.13.01.52.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 01:52:43 -0800 (PST) To: "rmcat WG (rmcat@ietf.org)" From: Martin Stiemerling Message-ID: <1338680b-9b27-27a9-613a-cd5bc9e5ed1e@gmail.com> Date: Mon, 13 Nov 2017 10:52:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rmcat] Final agenda RMCAT@IETF-100 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, 13 Nov 2017 09:52:47 -0000 Dear all, The final agenda for the RMCAT@IETF-100 session has been uploaded (see also below for a copy). 13:30-15:00 Wednesday Afternoon session I Room: Orchard Chairs: Anna Brunstrom (anna.brunstrom@kau.se) Colin Perkins (csp@csperkins.org) Martin Stiemerling (mls.ietf@gmail.com) 1) Administrativa -- chairs note well minute taker jabber scribe blue sheets 2) WG status -- chairs 3) draft-ietf-rmcat-nada -- Xiaoqing Zhu 4) draft-ietf-rmcat-scream-cc and related -- Ingemar Johansson 5) draft-dt-rmcat-feedback-message -- Zahed Sarker Regards, Martin From nobody Mon Nov 13 02:50: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 A64BE120726; Mon, 13 Nov 2017 02:50:11 -0800 (PST) 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 3_Ii-y8QoERZ; Mon, 13 Nov 2017 02:50:09 -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 6EB95129485; Mon, 13 Nov 2017 02:50:09 -0800 (PST) To: From: Anna Brunstrom CC: "rmcat-chairs@ietf.org" , "rmcat@ietf.org" Message-ID: <0d6de6f9-3f1a-f56b-a5f4-4c619f14df96@kau.se> Date: Mon, 13 Nov 2017 11:49:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ClientProxiedBy: Exch-A2.personal.kau (130.243.19.83) To Exch-A2.personal.kau (130.243.19.83) Archived-At: Subject: [rmcat] SBD write-up: minor inconsistencies to resolve 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, 13 Nov 2017 10:50:12 -0000 Dear David and co-authors, When preparing the write-up for the SBD draft I found some smaller inconsistencies, mainly in the Definitions section, see comments below. Could you please submit a new version resolving the issues. The write-up is ready for the draft to be submitted for publication once the new version is available. Thanks, Anna Comments from draft write-up review: In section 2: - M is defined twice. Also the value is restricted to "where M <= N" in the definition of E_M, but I think this applies to M in general and should be part of the definition of M. - sum_N and num_VM are defined but never used in the rest of the text - num_MT and sum_M are not defined but used later in  the text - punctuation is also inconsistent in this section in case you want to fix that while editing In section 2.1: - For p_* : "Flows are separated when the skew_est|var_est|freq_est measure is greater than p_s|p_f|p_d|p_mad." - There are three measures for four thresholds? - p_l is not described. In section 3.2.3: - second last line: "For calculation of freq_est p_v=0.7" - This line seems misplaced and redundant as freq_est is discussed in 3.2.4 and the value of p_v is discussed there. - last line: "For the grouping threshold p_mad=0.1" - Also not sure that this really fits here, but should perhaps rather be mentioned in 3.3.1 instead? But ok if you want to keep it. Section 6: - "The algorithm described in this memo has so far been evaluated using simulations." - Should this be "... simulations and small scale experiments" or the experiments in the LCN paper are not relevant to mention? - "Real network tests using the proposed congestion control algorithms will help confirm the default parameter choice." - Not clear what " the proposed congestion control algorithm" refers to. References: - As you are making an update, please also update [I-D.ietf-rmcat-coupled-cc] and  [I-D.dt-rmcat-feedback-message] to the latest version, using the avtcore version for the feedback message draft. From nobody Mon Nov 13 12:51:28 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 582F9129562 for ; Mon, 13 Nov 2017 12:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=callstats.io 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 C_d_BjSMLpyD for ; Mon, 13 Nov 2017 12:51:25 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 430FC126DEE for ; Mon, 13 Nov 2017 12:51:25 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id a2so19871805lfh.11 for ; Mon, 13 Nov 2017 12:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sX8D1yav/1uDvjwMMltYkN+zI8y1hPHsw7vAi0VQyO0=; b=Pf42sWvx4W1Xjmql1YHTBh2x9mh6uq1FctKDDlGkFzC5jzm/5pyFFYuOLU6Z5UqGXp 5B8R7xgPEagePegivOyE6P8em7xb6V43VYJ7oZ69Low3P50SnE5EPxaxAVTO8BM1ZnnI xeHRjnlEpsu+8xzkWtzrzOuTVqwa2OZMVb8kQ= 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:cc; bh=sX8D1yav/1uDvjwMMltYkN+zI8y1hPHsw7vAi0VQyO0=; b=RbY2E/MMzs+6pBtjeQ7yIEov4zQs9njFPZVwzEyJsV8N/YAlfEg2ATMGwP0jk4OsDh WxYY8wICfKMwmkgPun93hQzr40mswDx8YlyB1Cskr/pAyub+sbkqmDBdaTvWZgfXjHAe PQBDhwj7XWEz4aV+G1v8kCmFV5H8IXtcAxp0giVy3Ygp0XxDSG6zzw/I57A6TApNZUFj mxlxEJ6CI89Sg7dwHHMjL3Joa9eFBEqIXmgAjG+mqpWSAzBKcobamGwbj/wyAtNAxuV5 eklY8NiTZmbjyf1uxB2q+koz3UEonktQd8uzuJlC6w4zqD8tGqxdmAjaTPzkRJvhHkSM O2sQ== X-Gm-Message-State: AJaThX5eBHuiocZ9upyTCjgxboKTF+LiMet6dkL/ZQuyBdF2Q+kY46B4 0yvMfh9FeRbrqhDeB+JxS1sFG7jyb246YSIEQW58aw== X-Google-Smtp-Source: AGs4zMa/O7eGwb3v3NKXWmPlD2vuqvhhxDVX19uKJAMELhC1hO2GWaDEn5fi+YjkaWNjUfZtSlPaQ7v5o/6mhp+1vTU= X-Received: by 10.46.76.9 with SMTP id z9mr3855612lja.105.1510606283247; Mon, 13 Nov 2017 12:51:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.167.129 with HTTP; Mon, 13 Nov 2017 12:51:02 -0800 (PST) In-Reply-To: References: From: Varun Singh Date: Mon, 13 Nov 2017 12:51:02 -0800 Message-ID: To: Michael Welzl Cc: Zaheduzzaman Sarker , "rmcat@ietf.org" , Colin Perkins , "W3C@CSIO" Content-Type: multipart/alternative; boundary="f403045ea626e8a2cf055de36ea1" Archived-At: Subject: Re: [rmcat] Priority and rtcweb 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, 13 Nov 2017 20:51:27 -0000 --f403045ea626e8a2cf055de36ea1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On Mon, Nov 13, 2017 at 10:44 AM, Michael Welzl wrote: > Can I hijack this thread to talk about priority? > > Priority is already defined in the API document to the following levels: high, medium, low, very-low. These labels map to the text in the transport document Thus, when congestion occurs, a "high" priority flow will have the ability to send 8 times as much data as a "very-low" priority flow if both have data to send. This prioritization is independent of the media type. The details of which packet to send first are implementation defined. WEBRTC API: https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprioritytype > There was a thread about priority in rtcweb - someone asking for a float= =E2=80=A6 > coupled-cc can easily support a float, but Harald=E2=80=99s transport dra= ft doesn=E2=80=99t > support it. Opinions went back and forth for a bit... > I think we should get more WebRTC deployment and not more debate on small > details that delays the work, so I don=E2=80=99t want to be a troublemake= r and > didn=E2=80=99t interfere with this discussion. > But, what is the view of people in rmcat about this? > > While the API does not provide a float value, nonetheless, doesn't the WebRTC stack or framework under the JS API have all the information to convert the set labels in to a float values after the flows are assigned values? > Cheers, > Michael > > > On Nov 13, 2017, at 2:41 PM, Varun Singh wrote: > > Hi, > > Was there a study done for the parameters needed for congestion control? = I > know we debated this at length, were there slides created by the > congestion control proponents, that I can reference. > > From the top of my head, I remember there=E2=80=99s > + priority (needed by coupled congestion control) > > I=E2=80=99m asking this for w3c input. They already have max bitrate, max > framearte, and degradation preference degradation preference indicates > where the bits should be allocated: in maintaining frame rates or frame > sizes. > > Feedback is appreciated To make sure we didn=E2=80=99t miss anything. > > Cheers, > Varun. > -- > Founder, CEO, callstats.io > http://www.callstats.io > > Interested in networking, media quality, and diagnostics. > We are hiring!: www.callstats.io/jobs/ > > > --=20 Founder, CEO, callstats.io http://www.callstats.io Interested in networking, media quality, and diagnostics. We are hiring!: www.callstats.io/jobs/ --f403045ea626e8a2cf055de36ea1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

On Mon, Nov 13, 2017 at 10:44 AM, Michael Welzl <michawe@ifi.u= io.no> wrote:
Can I hijack this thread to talk = about priority?


Priori= ty is already defined in the API document to the following levels: high, me= dium, low, very-low.
These labels map to the text in the transpor= t document

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thus, = when congestion occurs, a "high" priority flow will have the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ability to send 8 times as much data as a= "very-low" priority flow if
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 both have data to send. This prioritization is independent of the
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media type. The details of which packet to= send first are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation define= d.


=C2=A0
There was a thread about prior= ity in rtcweb - someone asking for a float=E2=80=A6 coupled-cc can easily s= upport a float, but Harald=E2=80=99s transport draft doesn=E2=80=99t suppor= t it. Opinions went back and forth for a bit...
I think we should= get more WebRTC deployment and not more debate on small details that delay= s the work, so I don=E2=80=99t want to be a troublemaker and didn=E2=80=99t= interfere with this discussion.
But, what is the view of people = in rmcat about this?


=
While the API does not provide a float value, nonetheless, doesn't= the WebRTC stack or framework under the JS API have all the information to= convert the set labels in to a float values after the flows are assigned v= alues?=C2=A0

=C2=A0
Cheers,
Michael


On Nov 13, 2017, at 2:41 PM, Varun Singh <varun@callstats.io> wrot= e:

=
Hi,

Was there a study done for the parameters needed for congestion control?= I know we debated this at length, were there slides created by =C2=A0the c= ongestion control proponents, that I can reference.=C2=A0

From the top of my head, I remember there= =E2=80=99s=C2=A0
+ priority (needed by coupled conge= stion control)

I=E2=80= =99m asking this for w3c input. They already have max bitrate, max frameart= e, and degradation preference =C2=A0degradation preference indicates where = the bits should be allocated: in maintaining frame rates or frame sizes.=C2= =A0

Feedback is apprecia= ted To make sure we didn=E2=80=99t miss anything.
Cheers,
Varun.=C2=A0
=
--
Founder, CEO, callstats.io

Interested= in networking, media quality, and diagnostics.
We are hiring!: <= a href=3D"http://www.callstats.io/jobs/" target=3D"_blank">www.callstats.io= /jobs/

<= br>

--
F= ounder, CEO, callstats.io=
http://www.ca= llstats.io

Interested in networking, media quality, and diagnost= ics.
We are hiring!: www.callstats.io/jobs/
--f403045ea626e8a2cf055de36ea1-- From nobody Mon Nov 13 19:01:50 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 BF3D11242F7 for ; Mon, 13 Nov 2017 19:01:42 -0800 (PST) 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 oqyL3tAIw-ff for ; Mon, 13 Nov 2017 19:01:40 -0800 (PST) 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 09703129B98 for ; Mon, 13 Nov 2017 19:01:40 -0800 (PST) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eERTm-0008Hl-Dp; Tue, 14 Nov 2017 04:01:38 +0100 Received: from dhcp-82c4.meeting.ietf.org ([31.133.130.196]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eERTk-000EAP-Bk; Tue, 14 Nov 2017 04:01:38 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2E5D07EF-75D7-40E5-BEEC-C6217A352049" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 14 Nov 2017 11:01:33 +0800 In-Reply-To: Cc: "rmcat@ietf.org" , Zaheduzzaman Sarker , Colin Perkins , "W3C@CSIO" To: Varun Singh References: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 31.133.130.196 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.130.196; envelope-from=michawe@ifi.uio.no; helo=dhcp-82c4.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.020, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BD63646515DD9ABB5841535B2942B50F5971F759 Archived-At: Subject: Re: [rmcat] Priority and rtcweb 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, 14 Nov 2017 03:01:43 -0000 --Apple-Mail=_2E5D07EF-75D7-40E5-BEEC-C6217A352049 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 14, 2017, at 4:51 AM, Varun Singh wrote: >=20 > Hi Michael, >=20 > On Mon, Nov 13, 2017 at 10:44 AM, Michael Welzl > wrote: > Can I hijack this thread to talk about priority? >=20 >=20 > Priority is already defined in the API document to the following = levels: high, medium, low, very-low. > These labels map to the text in the transport document >=20 > Thus, when congestion occurs, a "high" priority flow will have = the > ability to send 8 times as much data as a "very-low" priority = flow if > both have data to send. This prioritization is independent of = the > media type. The details of which packet to send first are > implementation defined. I know! The coupled-cc text matches these as well. > WEBRTC API: = https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprioritytype = >=20 > =20 > There was a thread about priority in rtcweb - someone asking for a = float=E2=80=A6 coupled-cc can easily support a float, but Harald=E2=80=99s= transport draft doesn=E2=80=99t support it. Opinions went back and = forth for a bit... > I think we should get more WebRTC deployment and not more debate on = small details that delays the work, so I don=E2=80=99t want to be a = troublemaker and didn=E2=80=99t interfere with this discussion. > But, what is the view of people in rmcat about this? >=20 >=20 > While the API does not provide a float value, nonetheless, doesn't the = WebRTC stack or framework under the JS API have all the information to = convert the set labels in to a float values after the flows are assigned = values?=20 Sure, but the point of that discussion was that the definition of these = values (high, very-low, etc etc) is too rigid. We could easily offer a much less rigid priority value - this is no = problem at all for coupled-cc (or a scheduler, for that matter). It is my understanding that the choices of high, very-low etc. were made = for simplicity, to just decide on *something* and move forward. I = respect that - but I also found it disappointing to see someone = complaining about this not supporting more flexible value choices when = technically, we can easily do so=E2=80=A6 Cheers, Michael --Apple-Mail=_2E5D07EF-75D7-40E5-BEEC-C6217A352049 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 14, 2017, at 4:51 AM, Varun Singh <varun@callstats.io> = wrote:

Hi Michael,

On Mon, Nov 13, 2017 at 10:44 AM, = Michael Welzl <michawe@ifi.uio.no> wrote:
Can I hijack this thread to = talk about priority?


Priority is already defined in the API = document to the following levels: high, medium, low, very-low.
These labels map to the text in the transport = document

        Thus, when congestion occurs, a = "high" priority flow will have the
    =     ability to send 8 times as much data as a "very-low" = priority flow if
        both = have data to send. This prioritization is independent of the
        media type. The details of which = packet to send first are
      =   implementation = defined.

I know!   The coupled-cc text matches these as = well.


WEBRTC = API: https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprio= ritytype

 
There was a thread = about priority in rtcweb - someone asking for a float=E2=80=A6 = coupled-cc can easily support a float, but Harald=E2=80=99s transport = draft doesn=E2=80=99t support it. Opinions went back and forth for a = bit...
I think we should get more WebRTC deployment = and not more debate on small details that delays the work, so I don=E2=80=99= t want to be a troublemaker and didn=E2=80=99t interfere with this = discussion.
But, what is the view of people in = rmcat about this?


While the API does not provide a float = value, nonetheless, doesn't the WebRTC stack or framework under the JS = API have all the information to convert the set labels in to a float = values after the flows are assigned = values? 

Sure, but the point of that discussion was that = the definition of these values (high, very-low, etc etc) is too = rigid.
We could easily offer a much less rigid priority value = - this is no problem at all for coupled-cc (or a scheduler, for that = matter).

It is my understanding that = the choices of high, very-low etc. were made for simplicity, to just = decide on *something* and move forward. I respect that - but I also = found it disappointing to see someone complaining about this not = supporting more flexible value choices when technically, we can easily = do so=E2=80=A6

Cheers,
Michael

= --Apple-Mail=_2E5D07EF-75D7-40E5-BEEC-C6217A352049-- From nobody Tue Nov 14 13:38:00 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 1E76C1289C3 for ; Tue, 14 Nov 2017 13:38:00 -0800 (PST) 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 k4PWI-ELQEta for ; Tue, 14 Nov 2017 13:37:57 -0800 (PST) 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 399C0127419 for ; Tue, 14 Nov 2017 13:37:57 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-3c-5a0b623307e7 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.A3.08439.3326B0A5; Tue, 14 Nov 2017 22:37:55 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 14 Nov 2017 22:37:54 +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=NHSXonChJJlWhf5N26+jzQHj1m/nT5Wtflo4gcHYEQA=; b=B3pm3Mk+t3k+rd4VFD1gjNlySIrgqde96LFewTagZ3M8EP9hURcb0/PkV21OHy6uI56UocMJHcoZh0+ptYqAxT+sYj2XM2olgpURXyDiqYRAV625z5Bt7qxBdxzdyMt+G3PkkjjaUanHe8tTn4Sk45Q/vECv6ZtQERRzgf+tpAg= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB6PR07MB3253.eurprd07.prod.outlook.com (10.175.233.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Tue, 14 Nov 2017 21:37:53 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::e0fd:9f9f:e232:b301]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::e0fd:9f9f:e232:b301%16]) with mapi id 15.20.0239.005; Tue, 14 Nov 2017 21:37:52 +0000 From: Ingemar Johansson S To: Varun Singh , Michael Welzl CC: Zaheduzzaman Sarker , "rmcat@ietf.org" , Colin Perkins , "W3C@CSIO" Thread-Topic: [rmcat] Priority and rtcweb Thread-Index: AQHTXYNiWzVJUBsXO06oaFXS+zl55qMUZRAA Date: Tue, 14 Nov 2017 21:37:51 +0000 Message-ID: References: In-Reply-To: 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: [31.133.151.23] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3253; 6:5ppSNGKJYXt+l8mz5RAj3Ur9Prtf4mJKp5tgsAOFTY1MXFjIxGYTUfjUmpb/VTNbzb/7UCPYMLIVXB11C7cjJLZmBsUc+aAzsQg0M7jrr821Zo2astmYSeA2Etyl7E3TgHECO8cM3fu44zpjObrT/aHSQ8+8o2ExseJdFYOh5UnNki+LFdO3Z5q5JQA6g+KimVJBVqX8h/+pmvGEs6q2lj4EXn4fLfsVaPjkFpUh32TI/HXM5mB0T5psTfuH5DDl8+AoImfcUEMJHRG8u/dfr8ZDC9OzapJXWhDqJ2BTwRj0urYg2Pkt7iCfHU7ddxfs3/yPkzOnivuBDEdkLznrtdUzZ7LrOBf1rc5WmTTEvO4=; 5:6INb98f2Itq8SiFJvEk8tHWQaR1Q6w6tU+SJc61CaPGBijjiR4llrwiuj/6sshnufWg6leJkvJptAvnaYHa1lJXLElxhIH1ORWym3Z+ynW4ey2f3LLXfxig5zDgyuSOmGOMIAYxEhwFe7UWQQAaUiQ8NALHaFUU8vhTRrMPGeaE=; 24:fYuVDfJZRlErOH3jXjJQ/4cTwU9DpRJz7w4AwxAxBrvCfAUx7QlMuJXwxe8vVW4uL5q9gUOAXJwaLwpsqr8gDQJTtXblGsHZJ5B4By5NdUk=; 7:8DxpTJPo+k4oZg3ail8gFqNVLSx7qP8/3xf063O9B4IyfOoPKsld6Pv3AvJfNklWxZ8ERfaQBPCt3eXPIyfVd6kOynnWn0dboIBh6rGjxBOFhoe4k5nixVAUboNRz7TVB+YnvbH83qhpbk9CJfd1wHSO3TW1bcMGj0h2IDinzQOvKWqsYHFe9VdQ5X7TmZcTWQBBKiqljGeWFN9hO8B3PTCebx+uzb/nrF8eUeIOytK108dAwrZvPpGlt5xxqrCT x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(199003)(24454002)(189002)(68736007)(9326002)(316002)(19609705001)(478600001)(86362001)(3660700001)(3280700002)(2900100001)(8936002)(790700001)(99286004)(2906002)(5250100002)(3846002)(81156014)(102836003)(81166006)(8676002)(25786009)(966005)(6116002)(33656002)(5660300001)(7696004)(236005)(97736004)(6246003)(6436002)(606006)(2950100002)(55016002)(54896002)(229853002)(53936002)(50986999)(9686003)(6306002)(7736002)(106356001)(53546010)(189998001)(14454004)(54906003)(110136005)(4326008)(6506006)(105586002)(66066001)(101416001)(53386004)(53376002)(54356999)(76176999)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3253; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 471d6ad5-9668-4d17-45a0-08d52ba7f57c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DB6PR07MB3253; x-ms-traffictypediagnostic: DB6PR07MB3253: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3231022)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR07MB3253; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR07MB3253; x-forefront-prvs: 04916EA04C received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB34887B56C06371BF3C0D938C2280DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 471d6ad5-9668-4d17-45a0-08d52ba7f57c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 21:37:51.9950 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3253 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUgTcRjH+e12t9ts+GvN9lAouOhtlZZGTtDI/0ZkZH+ELbKuPHU5NXZm rihWluJM3aSMmaWItczCCMssUZyVzuzFcr1RLZdBhlBJr4rVzrvA/z73fD/P89w9HE2o7pDz aFNuPmvJZcxaSiF1pbalrIjdFWJc6fCF6t2jfUj/60E7qW9++YXSf3d2UXrbwweSdaSh1ltJ GKr9fsrQ2PhbYmhuHiY2SY2KhHTWbCpgLdFrdyqyOt1u6d6BU6iwpOkHZUMDTmRHchrwavD+ DUjsSEGrcA+Cu/WTJB+ocB8CWxHDB1JcToBz4qpoVUvgha9FfBhGUNn4nOBbKJwATZ6f03PV 2ACTV37IeInAFxA4n7dJ+WAOXgKuowOUIC2F7to6UuAYGApcDDp0cN9C8LWt4VGJjXD021Zh 130EI+duTY+R4xQIjJ+W8IxwOPh/vp2uE1gDr0bqJMK3YWjseEQIHAaj7/+Qgr8bxl+Wk0I9 EoobBsVbhMOTujLELwPskcEzr10cFAt2RwcpBG4Kehz3xO5kaG34SAiBC8H5iSqxQweesSpR yoaSijcim+He5TaRh0gofbzNgVbUzHhzgfOgKxCgeFbi2eB1jUhrgtcgggdruRUtKJFwsmxY JvASOF57VjazXo9kl1AYx3K7cjJjYqNYi2k3x+XlRuWy+ddQ8N/qbp1ceBM9HUvyIEwj7Szl ju0hRhXJFHDWHA8CmtCqle01CqNKmc5YD7CWvB2WfWaW86D5tFSrURrUQRtnMvlsNsvuZS3/ Uwktn2dDG77IM6qqE248vHTduljTGz8RP67xWfecyEicVHRuKerO/GC+Yc9MV2ck7l9qal3E HTzWUfRpT9nmXvn6qKaYq1vnJhWkhR1axhQOZtx261J1ofen1J+zXsclLugcLTUfjojwMsv9 G13JOZr+9ndx7jNHfk+xaaVUf/fXirPF8a97tVIui1mlIywc8w9uJmIQVwMAAA== Archived-At: Subject: Re: [rmcat] Priority and rtcweb 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, 14 Nov 2017 21:38:00 -0000 --_000_DB4PR07MB34887B56C06371BF3C0D938C2280DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KU0NSZUFNIHN1cHBvcnRzIGEgZmxvYXQgcHJpb3JpdHkgdmFsdWUsIGluIHJlYWxpdHkg dGhvdWdoIEkgZG91YnQgdGhhdCB0aGVyZSBpcyBtdWNoIGJlbmVmaXQgdG8gaGF2ZSBhIGhpZ2hl ciBncmFudWxhcml0eSB0aGFuIHRoZSBnaXZlbiB2YWx1ZXMgYXMgd2UgZGVhbCB3aXRoIGxpdmUg ZW5jb2Rpbmcgd2l0aCB2aWRlbyBjb2RlcnMgdGhhdCBvZnRlbiBwcm9kdWNlIGEgbWVzc3kgb3V0 cHV0LiBJbiB0aGUgcHJlc2VudGF0aW9uIHRvZGF5IHlvdeKAmWxsIHNlZSBhbiBleGFtcGxlIG9m IHByaW9yaXRpemF0aW9uIGluIHRoZSB3aWxkIChwYWdlIDEyIGluIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbWVldGluZy8xMDAvbWF0ZXJpYWxzL3NsaWRlcy0xMDAtcm1jYXQtc2NyZWFt LWV4cGVyaW1lbnRzLyApDQoNCi9JbmdlbWFyDQoNCg0KRnJvbTogVmFydW4gU2luZ2ggW21haWx0 bzp2YXJ1bkBjYWxsc3RhdHMuaW9dDQpTZW50OiBkZW4gMTQgbm92ZW1iZXIgMjAxNyAwNDo1MQ0K VG86IE1pY2hhZWwgV2VsemwgPG1pY2hhd2VAaWZpLnVpby5ubz4NCkNjOiBaYWhlZHV6emFtYW4g U2Fya2VyIDx6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbT47IHJtY2F0QGlldGYub3Jn OyBDb2xpbiBQZXJraW5zIDxjc3BAY3NwZXJraW5zLm9yZz47IFczQ0BDU0lPIDx3ZWJydGNAY2Fs bHN0YXRzLmlvPg0KU3ViamVjdDogUmU6IFtybWNhdF0gUHJpb3JpdHkgYW5kIHJ0Y3dlYg0KDQpI aSBNaWNoYWVsLA0KDQpPbiBNb24sIE5vdiAxMywgMjAxNyBhdCAxMDo0NCBBTSwgTWljaGFlbCBX ZWx6bCA8bWljaGF3ZUBpZmkudWlvLm5vPG1haWx0bzptaWNoYXdlQGlmaS51aW8ubm8+PiB3cm90 ZToNCkNhbiBJIGhpamFjayB0aGlzIHRocmVhZCB0byB0YWxrIGFib3V0IHByaW9yaXR5Pw0KDQoN ClByaW9yaXR5IGlzIGFscmVhZHkgZGVmaW5lZCBpbiB0aGUgQVBJIGRvY3VtZW50IHRvIHRoZSBm b2xsb3dpbmcgbGV2ZWxzOiBoaWdoLCBtZWRpdW0sIGxvdywgdmVyeS1sb3cuDQpUaGVzZSBsYWJl bHMgbWFwIHRvIHRoZSB0ZXh0IGluIHRoZSB0cmFuc3BvcnQgZG9jdW1lbnQNCg0KICAgICAgICBU aHVzLCB3aGVuIGNvbmdlc3Rpb24gb2NjdXJzLCBhICJoaWdoIiBwcmlvcml0eSBmbG93IHdpbGwg aGF2ZSB0aGUNCiAgICAgICAgYWJpbGl0eSB0byBzZW5kIDggdGltZXMgYXMgbXVjaCBkYXRhIGFz IGEgInZlcnktbG93IiBwcmlvcml0eSBmbG93IGlmDQogICAgICAgIGJvdGggaGF2ZSBkYXRhIHRv IHNlbmQuIFRoaXMgcHJpb3JpdGl6YXRpb24gaXMgaW5kZXBlbmRlbnQgb2YgdGhlDQogICAgICAg IG1lZGlhIHR5cGUuIFRoZSBkZXRhaWxzIG9mIHdoaWNoIHBhY2tldCB0byBzZW5kIGZpcnN0IGFy ZQ0KICAgICAgICBpbXBsZW1lbnRhdGlvbiBkZWZpbmVkLg0KDQpXRUJSVEMgQVBJOiBodHRwczov L3Jhd2dpdC5jb20vdzNjL3dlYnJ0Yy1wYy9tYXN0ZXIvd2VicnRjLmh0bWwjZG9tLXJ0Y3ByaW9y aXR5dHlwZQ0KDQoNClRoZXJlIHdhcyBhIHRocmVhZCBhYm91dCBwcmlvcml0eSBpbiBydGN3ZWIg LSBzb21lb25lIGFza2luZyBmb3IgYSBmbG9hdOKApiBjb3VwbGVkLWNjIGNhbiBlYXNpbHkgc3Vw cG9ydCBhIGZsb2F0LCBidXQgSGFyYWxk4oCZcyB0cmFuc3BvcnQgZHJhZnQgZG9lc27igJl0IHN1 cHBvcnQgaXQuIE9waW5pb25zIHdlbnQgYmFjayBhbmQgZm9ydGggZm9yIGEgYml0Li4uDQpJIHRo aW5rIHdlIHNob3VsZCBnZXQgbW9yZSBXZWJSVEMgZGVwbG95bWVudCBhbmQgbm90IG1vcmUgZGVi YXRlIG9uIHNtYWxsIGRldGFpbHMgdGhhdCBkZWxheXMgdGhlIHdvcmssIHNvIEkgZG9u4oCZdCB3 YW50IHRvIGJlIGEgdHJvdWJsZW1ha2VyIGFuZCBkaWRu4oCZdCBpbnRlcmZlcmUgd2l0aCB0aGlz IGRpc2N1c3Npb24uDQpCdXQsIHdoYXQgaXMgdGhlIHZpZXcgb2YgcGVvcGxlIGluIHJtY2F0IGFi b3V0IHRoaXM/DQoNCg0KV2hpbGUgdGhlIEFQSSBkb2VzIG5vdCBwcm92aWRlIGEgZmxvYXQgdmFs dWUsIG5vbmV0aGVsZXNzLCBkb2Vzbid0IHRoZSBXZWJSVEMgc3RhY2sgb3IgZnJhbWV3b3JrIHVu ZGVyIHRoZSBKUyBBUEkgaGF2ZSBhbGwgdGhlIGluZm9ybWF0aW9uIHRvIGNvbnZlcnQgdGhlIHNl dCBsYWJlbHMgaW4gdG8gYSBmbG9hdCB2YWx1ZXMgYWZ0ZXIgdGhlIGZsb3dzIGFyZSBhc3NpZ25l ZCB2YWx1ZXM/DQoNCg0KQ2hlZXJzLA0KTWljaGFlbA0KDQoNCk9uIE5vdiAxMywgMjAxNywgYXQg Mjo0MSBQTSwgVmFydW4gU2luZ2ggPHZhcnVuQGNhbGxzdGF0cy5pbzxtYWlsdG86dmFydW5AY2Fs bHN0YXRzLmlvPj4gd3JvdGU6DQoNCkhpLA0KDQpXYXMgdGhlcmUgYSBzdHVkeSBkb25lIGZvciB0 aGUgcGFyYW1ldGVycyBuZWVkZWQgZm9yIGNvbmdlc3Rpb24gY29udHJvbD8gSSBrbm93IHdlIGRl YmF0ZWQgdGhpcyBhdCBsZW5ndGgsIHdlcmUgdGhlcmUgc2xpZGVzIGNyZWF0ZWQgYnkgIHRoZSBj b25nZXN0aW9uIGNvbnRyb2wgcHJvcG9uZW50cywgdGhhdCBJIGNhbiByZWZlcmVuY2UuDQoNCkZy b20gdGhlIHRvcCBvZiBteSBoZWFkLCBJIHJlbWVtYmVyIHRoZXJl4oCZcw0KKyBwcmlvcml0eSAo bmVlZGVkIGJ5IGNvdXBsZWQgY29uZ2VzdGlvbiBjb250cm9sKQ0KDQpJ4oCZbSBhc2tpbmcgdGhp cyBmb3IgdzNjIGlucHV0LiBUaGV5IGFscmVhZHkgaGF2ZSBtYXggYml0cmF0ZSwgbWF4IGZyYW1l YXJ0ZSwgYW5kIGRlZ3JhZGF0aW9uIHByZWZlcmVuY2UgIGRlZ3JhZGF0aW9uIHByZWZlcmVuY2Ug aW5kaWNhdGVzIHdoZXJlIHRoZSBiaXRzIHNob3VsZCBiZSBhbGxvY2F0ZWQ6IGluIG1haW50YWlu aW5nIGZyYW1lIHJhdGVzIG9yIGZyYW1lIHNpemVzLg0KDQpGZWVkYmFjayBpcyBhcHByZWNpYXRl ZCBUbyBtYWtlIHN1cmUgd2UgZGlkbuKAmXQgbWlzcyBhbnl0aGluZy4NCg0KQ2hlZXJzLA0KVmFy dW4uDQotLQ0KRm91bmRlciwgQ0VPLCBjYWxsc3RhdHMuaW88aHR0cDovL2NhbGxzdGF0cy5pby8+ DQpodHRwOi8vd3d3LmNhbGxzdGF0cy5pbzxodHRwOi8vd3d3LmNhbGxzdGF0cy5pby8+DQoNCklu dGVyZXN0ZWQgaW4gbmV0d29ya2luZywgbWVkaWEgcXVhbGl0eSwgYW5kIGRpYWdub3N0aWNzLg0K V2UgYXJlIGhpcmluZyE6IHd3dy5jYWxsc3RhdHMuaW8vam9icy88aHR0cDovL3d3dy5jYWxsc3Rh dHMuaW8vam9icy8+DQoNCg0KDQoNCi0tDQpGb3VuZGVyLCBDRU8sIGNhbGxzdGF0cy5pbzxodHRw Oi8vY2FsbHN0YXRzLmlvPg0KaHR0cDovL3d3dy5jYWxsc3RhdHMuaW8NCg0KSW50ZXJlc3RlZCBp biBuZXR3b3JraW5nLCBtZWRpYSBxdWFsaXR5LCBhbmQgZGlhZ25vc3RpY3MuDQpXZSBhcmUgaGly aW5nITogd3d3LmNhbGxzdGF0cy5pby9qb2JzLzxodHRwOi8vd3d3LmNhbGxzdGF0cy5pby9qb2Jz Lz4NCg== --_000_DB4PR07MB34887B56C06371BF3C0D938C2280DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZ21haWwtaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmdtYWlsLWhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TQ1JlQU0gc3VwcG9ydHMgYSBmbG9hdCBw cmlvcml0eSB2YWx1ZSwgaW4gcmVhbGl0eSB0aG91Z2ggSSBkb3VidCB0aGF0IHRoZXJlIGlzIG11 Y2ggYmVuZWZpdCB0byBoYXZlIGEgaGlnaGVyIGdyYW51bGFyaXR5IHRoYW4gdGhlIGdpdmVuIHZh bHVlcyBhcyB3ZSBkZWFsIHdpdGggbGl2ZSBlbmNvZGluZyB3aXRoIHZpZGVvIGNvZGVycyB0aGF0 IG9mdGVuIHByb2R1Y2UgYSBtZXNzeSBvdXRwdXQuIEluIHRoZSBwcmVzZW50YXRpb24NCiB0b2Rh eSB5b3XigJlsbCBzZWUgYW4gZXhhbXBsZSBvZiBwcmlvcml0aXphdGlvbiBpbiB0aGUgd2lsZCAo cGFnZSAxMiBpbiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcv MTAwL21hdGVyaWFscy9zbGlkZXMtMTAwLXJtY2F0LXNjcmVhbS1leHBlcmltZW50cy8iPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMC9tYXRlcmlhbHMvc2xpZGVzLTEw MC1ybWNhdC1zY3JlYW0tZXhwZXJpbWVudHMvPC9hPiApPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48dT48bzpw PjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+Jm5ic3A7PC9zcGFuPjwvbzpwPjwv dT48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBWYXJ1biBTaW5naCBbbWFpbHRvOnZh cnVuQGNhbGxzdGF0cy5pb10gPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAxNCBub3ZlbWJlciAyMDE3 IDA0OjUxPGJyPg0KPGI+VG86PC9iPiBNaWNoYWVsIFdlbHpsICZsdDttaWNoYXdlQGlmaS51aW8u bm8mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBaYWhlZHV6emFtYW4gU2Fya2VyICZsdDt6YWhlZHV6emFt YW4uc2Fya2VyQGVyaWNzc29uLmNvbSZndDs7IHJtY2F0QGlldGYub3JnOyBDb2xpbiBQZXJraW5z ICZsdDtjc3BAY3NwZXJraW5zLm9yZyZndDs7IFczQ0BDU0lPICZsdDt3ZWJydGNAY2FsbHN0YXRz LmlvJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3JtY2F0XSBQcmlvcml0eSBhbmQgcnRj d2ViPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWlj aGFlbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE5vdiAx MywgMjAxNyBhdCAxMDo0NCBBTSwgTWljaGFlbCBXZWx6bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1p Y2hhd2VAaWZpLnVpby5ubyIgdGFyZ2V0PSJfYmxhbmsiPm1pY2hhd2VAaWZpLnVpby5ubzwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DYW4gSSBoaWphY2sgdGhpcyB0aHJlYWQgdG8gdGFsayBhYm91dCBwcmlvcml0 eT88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Qcmlvcml0eSBpcyBhbHJlYWR5IGRlZmluZWQgaW4gdGhlIEFQSSBk b2N1bWVudCB0byB0aGUgZm9sbG93aW5nIGxldmVsczogaGlnaCwgbWVkaXVtLCBsb3csIHZlcnkt bG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlc2UgbGFiZWxzIG1hcCB0byB0aGUgdGV4dCBpbiB0aGUgdHJhbnNwb3J0IGRvY3VtZW50PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGh1cywgd2hlbiBjb25nZXN0aW9uIG9jY3Vy cywgYSAmcXVvdDtoaWdoJnF1b3Q7IHByaW9yaXR5IGZsb3cgd2lsbCBoYXZlIHRoZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGFiaWxpdHkgdG8gc2VuZCA4IHRpbWVzIGFzIG11Y2ggZGF0YSBhcyBh ICZxdW90O3ZlcnktbG93JnF1b3Q7IHByaW9yaXR5IGZsb3cgaWY8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBib3RoIGhhdmUgZGF0YSB0byBzZW5kLiBUaGlzIHByaW9yaXRpemF0aW9uIGlzIGluZGVw ZW5kZW50IG9mIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1lZGlhIHR5cGUuIFRoZSBkZXRh aWxzIG9mIHdoaWNoIHBhY2tldCB0byBzZW5kIGZpcnN0IGFyZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGltcGxlbWVudGF0aW9uIGRlZmluZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V0VCUlRDIEFQSTogPGEgaHJlZj0iaHR0 cHM6Ly9yYXdnaXQuY29tL3czYy93ZWJydGMtcGMvbWFzdGVyL3dlYnJ0Yy5odG1sI2RvbS1ydGNw cmlvcml0eXR5cGUiPg0KaHR0cHM6Ly9yYXdnaXQuY29tL3czYy93ZWJydGMtcGMvbWFzdGVyL3dl YnJ0Yy5odG1sI2RvbS1ydGNwcmlvcml0eXR5cGU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVy ZSB3YXMgYSB0aHJlYWQgYWJvdXQgcHJpb3JpdHkgaW4gcnRjd2ViIC0gc29tZW9uZSBhc2tpbmcg Zm9yIGEgZmxvYXTigKYgY291cGxlZC1jYyBjYW4gZWFzaWx5IHN1cHBvcnQgYSBmbG9hdCwgYnV0 IEhhcmFsZOKAmXMgdHJhbnNwb3J0IGRyYWZ0IGRvZXNu4oCZdCBzdXBwb3J0IGl0LiBPcGluaW9u cyB3ZW50IGJhY2sgYW5kIGZvcnRoIGZvciBhIGJpdC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB3ZSBzaG91bGQgZ2V0IG1vcmUg V2ViUlRDIGRlcGxveW1lbnQgYW5kIG5vdCBtb3JlIGRlYmF0ZSBvbiBzbWFsbCBkZXRhaWxzIHRo YXQgZGVsYXlzIHRoZSB3b3JrLCBzbyBJIGRvbuKAmXQgd2FudCB0byBiZSBhIHRyb3VibGVtYWtl ciBhbmQgZGlkbuKAmXQgaW50ZXJmZXJlIHdpdGggdGhpcyBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0LCB3aGF0IGlzIHRo ZSB2aWV3IG9mIHBlb3BsZSBpbiBybWNhdCBhYm91dCB0aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2hpbGUgdGhlIEFQSSBkb2VzIG5vdCBwcm92aWRlIGEgZmxvYXQgdmFsdWUsIG5vbmV0aGVs ZXNzLCBkb2Vzbid0IHRoZSBXZWJSVEMgc3RhY2sgb3IgZnJhbWV3b3JrIHVuZGVyIHRoZSBKUyBB UEkgaGF2ZSBhbGwgdGhlIGluZm9ybWF0aW9uIHRvIGNvbnZlcnQgdGhlIHNldCBsYWJlbHMgaW4g dG8gYSBmbG9hdCB2YWx1ZXMgYWZ0ZXIgdGhlIGZsb3dzIGFyZSBhc3NpZ25lZCB2YWx1ZXM/Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWNoYWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAxMywgMjAxNywgYXQgMjo0 MSBQTSwgVmFydW4gU2luZ2ggJmx0OzxhIGhyZWY9Im1haWx0bzp2YXJ1bkBjYWxsc3RhdHMuaW8i IHRhcmdldD0iX2JsYW5rIj52YXJ1bkBjYWxsc3RhdHMuaW88L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XYXMgdGhlcmUgYSBzdHVk eSBkb25lIGZvciB0aGUgcGFyYW1ldGVycyBuZWVkZWQgZm9yIGNvbmdlc3Rpb24gY29udHJvbD8g SSBrbm93IHdlIGRlYmF0ZWQgdGhpcyBhdCBsZW5ndGgsIHdlcmUgdGhlcmUgc2xpZGVzIGNyZWF0 ZWQgYnkgJm5ic3A7dGhlIGNvbmdlc3Rpb24gY29udHJvbCBwcm9wb25lbnRzLCB0aGF0IEkgY2Fu IHJlZmVyZW5jZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RnJvbSB0aGUgdG9wIG9mIG15IGhlYWQsIEkgcmVtZW1iZXIgdGhlcmXi gJlzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mIzQzOyBwcmlvcml0eSAobmVlZGVkIGJ5IGNvdXBsZWQgY29uZ2VzdGlvbiBjb250cm9s KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J 4oCZbSBhc2tpbmcgdGhpcyBmb3IgdzNjIGlucHV0LiBUaGV5IGFscmVhZHkgaGF2ZSBtYXggYml0 cmF0ZSwgbWF4IGZyYW1lYXJ0ZSwgYW5kIGRlZ3JhZGF0aW9uIHByZWZlcmVuY2UgJm5ic3A7ZGVn cmFkYXRpb24gcHJlZmVyZW5jZSBpbmRpY2F0ZXMgd2hlcmUgdGhlIGJpdHMgc2hvdWxkIGJlIGFs bG9jYXRlZDogaW4gbWFpbnRhaW5pbmcgZnJhbWUgcmF0ZXMgb3IgZnJhbWUgc2l6ZXMuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZl ZWRiYWNrIGlzIGFwcHJlY2lhdGVkIFRvIG1ha2Ugc3VyZSB3ZSBkaWRu4oCZdCBtaXNzIGFueXRo aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5WYXJ1bi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5Gb3VuZGVyLCBDRU8sIDxhIGhyZWY9Imh0 dHA6Ly9jYWxsc3RhdHMuaW8vIiB0YXJnZXQ9Il9ibGFuayI+DQpjYWxsc3RhdHMuaW88L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2FsbHN0YXRz LmlvLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuY2FsbHN0YXRzLmlvPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+SW50ZXJlc3RlZCBpbiBuZXR3b3JraW5nLCBtZWRpYSBxdWFsaXR5LCBhbmQgZGlhZ25vc3Rp Y3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPldlIGFyZSBoaXJpbmchOiA8YSBocmVm PSJodHRwOi8vd3d3LmNhbGxzdGF0cy5pby9qb2JzLyIgdGFyZ2V0PSJfYmxhbmsiPg0Kd3d3LmNh bGxzdGF0cy5pby9qb2JzLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm91bmRlciwgQ0VPLCA8YSBocmVmPSJodHRw Oi8vY2FsbHN0YXRzLmlvIiB0YXJnZXQ9Il9ibGFuayI+DQpjYWxsc3RhdHMuaW88L2E+PGJyPg0K PGEgaHJlZj0iaHR0cDovL3d3dy5jYWxsc3RhdHMuaW8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v d3d3LmNhbGxzdGF0cy5pbzwvYT48YnI+DQo8YnI+DQpJbnRlcmVzdGVkIGluIG5ldHdvcmtpbmcs IG1lZGlhIHF1YWxpdHksIGFuZCBkaWFnbm9zdGljcy4gPGJyPg0KV2UgYXJlIGhpcmluZyE6IDxh IGhyZWY9Imh0dHA6Ly93d3cuY2FsbHN0YXRzLmlvL2pvYnMvIiB0YXJnZXQ9Il9ibGFuayI+d3d3 LmNhbGxzdGF0cy5pby9qb2JzLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DB4PR07MB34887B56C06371BF3C0D938C2280DB4PR07MB348eurprd_-- From nobody Tue Nov 14 21:41: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 017441294B3 for ; Tue, 14 Nov 2017 21:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 BkXibCbFZjJw for ; Tue, 14 Nov 2017 21:41:13 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25D51292AE for ; Tue, 14 Nov 2017 21:41:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C932C7C3552 for ; Wed, 15 Nov 2017 06:41:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40gvJEcwEkKl for ; Wed, 15 Nov 2017 06:41:08 +0100 (CET) Received: from [IPv6:2001:67c:370:128:d17c:7d46:9cc9:b1a4] (unknown [IPv6:2001:67c:370:128:d17c:7d46:9cc9:b1a4]) by mork.alvestrand.no (Postfix) with ESMTPSA id DFB4E7C0166 for ; Wed, 15 Nov 2017 06:41:07 +0100 (CET) To: rmcat@ietf.org References: From: Harald Alvestrand Message-ID: <5e771d80-acd7-b18a-b00f-6e9bd252cb6c@alvestrand.no> Date: Wed, 15 Nov 2017 06:41:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------458379A6243DE3C4B6383284" Content-Language: en-US Archived-At: Subject: Re: [rmcat] Priority and rtcweb 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 Nov 2017 05:41:15 -0000 This is a multi-part message in MIME format. --------------458379A6243DE3C4B6383284 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/13/2017 09:44 AM, Michael Welzl wrote: > Can I hijack this thread to talk about priority? > > There was a thread about priority in rtcweb - someone asking for a > float=E2=80=A6 coupled-cc can easily support a float, but Harald=E2=80=99= s transport > draft doesn=E2=80=99t support it. Opinions went back and forth for a bi= t... > I think we should get more WebRTC deployment and not more debate on > small details that delays the work, so I don=E2=80=99t want to be a > troublemaker and didn=E2=80=99t interfere with this discussion. > But, what is the view of people in rmcat about this? the reason for the 4 levels was indeed that they were defined at a time when we thought that any underlying system (whether it be diffserv or congestion controllers that supported float priorities) could do something sensible with them, while having more than 4 things to choose from seemed to be of questionable value in a large majority of use cases.= a float doesn't help much if you don't know what the effect of changing the value is; is it linear in bandwidth, linear in bandwidth fraction=C2=A0= (sum and normalize? 0..1?), exponential in some dimension, logarithmic in some other dimension? If a congestion controller mechanism wants to interface to the webrtc 4 levels, it would have to do something like the diffserv-to-priority document from TSV - defining what controls on the congestion controller one needs to set to have an appropriate result on what gets sent when congestion happens. > > Cheers, > Michael > > >> On Nov 13, 2017, at 2:41 PM, Varun Singh > > wrote: >> >> Hi, >> >> Was there a study done for the parameters needed for congestion >> control? I know we debated this at length, were there slides created >> by =C2=A0the congestion control proponents, that I can reference.=C2=A0= >> >> From the top of my head, I remember there=E2=80=99s=C2=A0 >> + priority (needed by coupled congestion control) >> >> I=E2=80=99m asking this for w3c input. They already have max bitrate, = max >> framearte, and degradation preference =C2=A0degradation preference >> indicates where the bits should be allocated: in maintaining frame >> rates or frame sizes.=C2=A0 >> >> Feedback is appreciated To make sure we didn=E2=80=99t miss anything. >> >> Cheers, >> Varun.=C2=A0 >> --=20 >> Founder, CEO, callstats.io >> http://www.callstats.io >> >> Interested in networking, media quality, and diagnostics. >> We are hiring!: www.callstats.io/jobs/ = > --=20 Surveillance is pervasive. Go Dark. --------------458379A6243DE3C4B6383284 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/13/2017 09:44 AM, Michael Welzl wrote:
Can I hijack this thread to talk about priority?

There was a thread about priority in rtcweb - someone asking for a float… coupled-cc can easily support a float, but Harald’s transport draft doesn’t support it. Opinions went back and forth for a bit...
I think we should get more WebRTC deployment and not more debate on small details that delays the work, so I don’t want to be a troublemaker and didn’t interfere with this discussion.
But, what is the view of people in rmcat about this?

the reason for the 4 levels was indeed that they were defined at a time when we thought that any underlying system (whether it be diffserv or congestion controllers that supported float priorities) could do something sensible with them, while having more than 4 things to choose from seemed to be of questionable value in a large majority of use cases.

a float doesn't help much if you don't know what the effect of changing the value is; is it linear in bandwidth, linear in bandwidth fraction  (sum and normalize? 0..1?), exponential in some dimension, logarithmic in some other dimension?

If a congestion controller mechanism wants to interface to the webrtc 4 levels, it would have to do something like the diffserv-to-priority document from TSV - defining what controls on the congestion controller one needs to set to have an appropriate result on what gets sent when congestion happens.





Cheers,
Michael


On Nov 13, 2017, at 2:41 PM, Varun Singh <varun@callstats.io> wrote:

Hi,

Was there a study done for the parameters needed for congestion control? I know we debated this at length, were there slides created by  the congestion control proponents, that I can reference. 

From the top of my head, I remember there’s 
+ priority (needed by coupled congestion control)

I’m asking this for w3c input. They already have max bitrate, max framearte, and degradation preference  degradation preference indicates where the bits should be allocated: in maintaining frame rates or frame sizes. 

Feedback is appreciated To make sure we didn’t miss anything.

Cheers,
Varun. 
--
Founder, CEO, callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/


-- 
Surveillance is pervasive. Go Dark.
--------------458379A6243DE3C4B6383284-- From nobody Wed Nov 15 14:51:45 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 71AC4128B93 for ; Wed, 15 Nov 2017 14:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=callstats.io 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 TIOA9sqKJP8C for ; Wed, 15 Nov 2017 14:51:41 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 9FD6212708C for ; Wed, 15 Nov 2017 14:51:40 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id 73so13728703lfu.10 for ; Wed, 15 Nov 2017 14:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ehNyFyBdYzZuG6Opq15D5v+k16YwbmadRBVW9O7IyY4=; b=BgtbxjcVhf3eiD3EOaWEAh6PxmmAIe6WLjdNwuVA0vPzMxD5vlwHTtAoqHwChUAuGI xaV55lp12kwoE4PW1yoEQimGKLo58UuaKD1aosPsqVToYcC8EbMyrHtipX/vqHhkfuFf KsxqAlZOJ1uQe5W5xJZwl0Z1n3VJKQjYp4rWg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ehNyFyBdYzZuG6Opq15D5v+k16YwbmadRBVW9O7IyY4=; b=ngIp4Uemmy/6qGwj1EBxEaK4QOt63yglTA37dREZS1p/hhaJ1EnPkj/y2iFT3131sz oPj+hi0c5UytApMX1rsndqkvrzdQggeKxTKbwwDPMlW2c9R47cdL8Gpk0zWrZwL2uFtS BH4NOI50DXtzO3Pyh/QnUXooDvSQlVGmr1GqzuG/igbKyQ0+QgVWt3Bxyzf+5yn6CpN0 j95MpNkXuzdhO/16HI15yV+I2vXh84ZAv52C0sYU+Q+CqIUAas+lFpYIrTmknGVjJcJF 7e+OnSF0GTDH+FPWzEsTNxFnZJsYHGw+vEm5XvQoVEqnc6+uCchxu1GIEzyE07MaWt4m /RWw== X-Gm-Message-State: AJaThX7uHPCIkTGIvrCvdt4/oBPk2V6WRrngIKRrXdamKu0iruVUSiL4 4zpHisHEXi5oC7slifATgCPydgPfjs7Ac1fv9otuTA== X-Google-Smtp-Source: AGs4zMZ1//JEFWOMtONXFPS8RWI0OxvO/3uX2IjgM2610l+Xb56zCJiE5ko/NZUqqiUnJzzLc6Rg0Je9g4HO5X9fch0= X-Received: by 10.46.34.1 with SMTP id i1mr6181219lji.133.1510786298552; Wed, 15 Nov 2017 14:51:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Varun Singh Date: Wed, 15 Nov 2017 22:51:27 +0000 Message-ID: To: Ingemar Johansson S Cc: Michael Welzl , Zaheduzzaman Sarker , "rmcat@ietf.org" , Colin Perkins , "W3C@CSIO" Content-Type: multipart/alternative; boundary="f4030439e32ca83894055e0d58e7" Archived-At: Subject: Re: [rmcat] Priority and rtcweb 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 Nov 2017 22:51:43 -0000 --f4030439e32ca83894055e0d58e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, I'll check it out. Since I didn=E2=80=99t remotely participate in t= he meeting today, Was there any input from the room? On Tue, 14 Nov 2017 at 23.37, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > > > SCReAM supports a float priority value, in reality though I doubt that > there is much benefit to have a higher granularity than the given values = as > we deal with live encoding with video coders that often produce a messy > output. In the presentation today you=E2=80=99ll see an example of priori= tization > in the wild (page 12 in > https://datatracker.ietf.org/meeting/100/materials/slides-100-rmcat-screa= m-experiments/ > ) > > > > /Ingemar > > > > > > *From:* Varun Singh [mailto:varun@callstats.io] > *Sent:* den 14 november 2017 04:51 > *To:* Michael Welzl > *Cc:* Zaheduzzaman Sarker ; > rmcat@ietf.org; Colin Perkins ; W3C@CSIO < > webrtc@callstats.io> > *Subject:* Re: [rmcat] Priority and rtcweb > > > > Hi Michael, > > > > On Mon, Nov 13, 2017 at 10:44 AM, Michael Welzl > wrote: > > Can I hijack this thread to talk about priority? > > > > > > Priority is already defined in the API document to the following levels: > high, medium, low, very-low. > > These labels map to the text in the transport document > > > > Thus, when congestion occurs, a "high" priority flow will have th= e > > ability to send 8 times as much data as a "very-low" priority flo= w > if > > both have data to send. This prioritization is independent of the > > media type. The details of which packet to send first are > > implementation defined. > > > > WEBRTC API: > https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprioritytype > > > > > > There was a thread about priority in rtcweb - someone asking for a float= =E2=80=A6 > coupled-cc can easily support a float, but Harald=E2=80=99s transport dra= ft doesn=E2=80=99t > support it. Opinions went back and forth for a bit... > > I think we should get more WebRTC deployment and not more debate on small > details that delays the work, so I don=E2=80=99t want to be a troublemake= r and > didn=E2=80=99t interfere with this discussion. > > But, what is the view of people in rmcat about this? > > > > > > While the API does not provide a float value, nonetheless, doesn't the > WebRTC stack or framework under the JS API have all the information to > convert the set labels in to a float values after the flows are assigned > values? > > > > > > Cheers, > > Michael > > > > > > On Nov 13, 2017, at 2:41 PM, Varun Singh wrote: > > > > Hi, > > > > Was there a study done for the parameters needed for congestion control? = I > know we debated this at length, were there slides created by the > congestion control proponents, that I can reference. > > > > From the top of my head, I remember there=E2=80=99s > > + priority (needed by coupled congestion control) > > > > I=E2=80=99m asking this for w3c input. They already have max bitrate, max > framearte, and degradation preference degradation preference indicates > where the bits should be allocated: in maintaining frame rates or frame > sizes. > > > > Feedback is appreciated To make sure we didn=E2=80=99t miss anything. > > > > Cheers, > > Varun. > > -- > > Founder, CEO, callstats.io > > http://www.callstats.io > > > > Interested in networking, media quality, and diagnostics. > > We are hiring!: www.callstats.io/jobs/ > > > > > > > > -- > > Founder, CEO, callstats.io > http://www.callstats.io > > Interested in networking, media quality, and diagnostics. > We are hiring!: www.callstats.io/jobs/ > --=20 Founder, CEO, callstats.io http://www.callstats.io Interested in networking, media quality, and diagnostics. We are hiring!: www.callstats.io/jobs/ --f4030439e32ca83894055e0d58e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, I'll check it out. Since I didn=E2=80=99t remotely participate = in the meeting today, Was there any input from the room?
On Tue, 14 Nov 2017 at 23.37, Ingemar Johansso= n S <ingemar.s.johan= sson@ericsson.com> wrote:

Hi

=C2=A0

SCReAM supports a float priority value, in reality t= hough I doubt that there is much benefit to have a higher granularity than = the given values as we deal with live encoding with video coders that often= produce a messy output. In the presentation today you=E2=80=99ll see an example of prioritization in the wild (page 12= in https://datatracker.ietf.org/meeting/100/materials/slides-100-rmcat-scream-= experiments/ )

=C2=A0

/Ingemar

= =C2=A0

=C2=A0

From: Varun Singh [mailto:varun@callstats.io]
Sent: den 14 november 2017 04:51
To: Michael Welzl <michawe@ifi.uio.no>
Cc: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>; rmcat@ietf.org; Colin = Perkins <csp@cspe= rkins.org>; W3C@CSIO <webrtc@callstats.io>
Subject: Re: [rmcat] Priority and rtcweb

=

=C2=A0

Hi Michael,

=C2=A0

On Mon, Nov 13, 2017 at 10:44 AM, Michael Welzl <= michawe@ifi.uio.no<= /a>> wrote:

Can I hijack this thread to talk about priority?<= /u>

=C2=A0

=C2=A0

Priority is already defined in the API document to t= he following levels: high, medium, low, very-low.

These labels map to the text in the transport docume= nt

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thus, when congestion oc= curs, a "high" priority flow will have the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ability to send 8 times = as much data as a "very-low" priority flow if

=C2=A0 =C2=A0 =C2=A0 =C2=A0 both have data to send. = This prioritization is independent of the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 media type. The details = of which packet to send first are

=C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation defined.<= u>

=C2=A0

=C2=A0

=C2=A0

There was a thread about priority in rtcweb - someon= e asking for a float=E2=80=A6 coupled-cc can easily support a float, but Ha= rald=E2=80=99s transport draft doesn=E2=80=99t support it. Opinions went ba= ck and forth for a bit...

I think we should get more WebRTC deployment and not= more debate on small details that delays the work, so I don=E2=80=99t want= to be a troublemaker and didn=E2=80=99t interfere with this discussion.=

But, what is the view of people in rmcat about this?=

=C2=A0

=C2=A0

While the API does not provide a float value, noneth= eless, doesn't the WebRTC stack or framework under the JS API have all = the information to convert the set labels in to a float values after the fl= ows are assigned values?=C2=A0

=C2=A0

=C2=A0

Cheers,

Michael

=C2=A0

=C2=A0

On Nov 13, 2017, at 2:41 PM, Varun Singh <varun@callstats.io>= wrote:

=C2=A0

Hi,

=C2=A0

Was there a study done for the parameters needed for= congestion control? I know we debated this at length, were there slides cr= eated by =C2=A0the congestion control proponents, that I can reference.=C2= =A0

=C2=A0

From the top of my head, I remember there=E2=80=99s= =C2=A0

+ priority (needed by coupled congestion control)=

=C2=A0

I=E2=80=99m asking this for w3c input. They already = have max bitrate, max framearte, and degradation preference =C2=A0degradati= on preference indicates where the bits should be allocated: in maintaining = frame rates or frame sizes.=C2=A0

=C2=A0

Feedback is appreciated To make sure we didn=E2=80= =99t miss anything.

=C2=A0

Cheers,

Varun.=C2=A0

--

Founder, CEO, callstats.io

=C2=A0

Interested in networki= ng, media quality, and diagnostics.

We are hiring!: www.callstats.io/jobs/

=C2=A0



=C2=A0

--

Founder, CEO, callstats.io
http://www.callstats.= io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/

--
Interested in networking, media quality, and diagnostics.<= /div>
We are hiring!: www.cal= lstats.io/jobs/
--f4030439e32ca83894055e0d58e7-- From nobody Mon Nov 20 03:02:17 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 B350B12953B for ; Mon, 20 Nov 2017 03:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, URIBL_BLOCKED=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 JOK1-woFl-Ox for ; Mon, 20 Nov 2017 03:02:09 -0800 (PST) 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 191F91294FF for ; Mon, 20 Nov 2017 03:02:08 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-31-5a12b62f741a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.E9.08439.F26B21A5; Mon, 20 Nov 2017 12:02:07 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 20 Nov 2017 12:02:06 +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=efllzpt4QtxC8AysbBwQkDxf/Mc9ycI+ylyi2XwhCsk=; b=Tk8otNy39w6rbDEFaPKRwmmM2h7yYymB09erOW30Q2wQ9q2/K6TNiCWBXpACuxCgdrdNLcAs1xbTEtJD/q76zUb4/8a3E9p29KdSibdUIOYM7CC1ddgj9kKt0P5Y5gX+H1eDv8Gb9Jwp6Or5e6f/uJJWrZGXqf0OrVQm6Q/irPg= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Mon, 20 Nov 2017 11:02:05 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::e0fd:9f9f:e232:b301]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::e0fd:9f9f:e232:b301%16]) with mapi id 15.20.0260.004; Mon, 20 Nov 2017 11:02:05 +0000 From: Ingemar Johansson S To: "rmcat WG (rmcat@ietf.org)" CC: "Bob Briscoe (research@bobbriscoe.net)" , "De Schepper, Koen (Koen)" Thread-Topic: SCReAM code with L4S support Thread-Index: AdNh7tLkBd3Xzv60SFyDLyuaNB4W1w== Date: Mon, 20 Nov 2017 11:02:05 +0000 Message-ID: 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: [77.95.104.36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 6:fOcburle/KgLlSty6ZOz0JymIOWfUMo5BaZJLlY4pjcg4kAgSdtzk7nuUHZRmfVVpKrm8v/4i6Sd2/7j298U55/WaQw0VpD+kgmXp5ypMevfomOrOnFL/hxWfUZiP9lApm9W4+ATs4ip82bsOVBnrAsguOrsxG7VFh5hN2J1MR6EJgIgTr7yum8RBzqRM6v34C7JfCm6K+eDNV0cFZD8gMqW4MYV2dJAWps1BAPBsNF6hCLG0CLOeIyUCZ9guVHDFkrkBbCrmDVzyPwHHs/lBcyfWfLrUOt1cOTA/BdVX+lsAL9LBet+KsPYAk/px21xkq2W5sO9/96nK9mTtT1R7Z298ktdkEon8pTOzEEIK2o=; 5:/Po7EJXvhBgbqQq6DeA3cZ/XIaCjWTt/ZYBiVdN0FNa2yaB56+GBTrZNk5fSdOuWNibgizQt/4ypMv5Jq+DVMbkhM1PAu4CGlhH7aFGgRnrQUK4nx6GUenR3U7bK1R4tr9O5n2roeM/wbFLC350sgmo3s9mmjUplmWKHXZWlrY0=; 24:EMNRAzCp2T9et/EQOeEChk9PgNxSv0DrtRzxsl0IoAkB5sqo0yk3TbvptYB0QDQ+ppH88RmJLhs+p5+uNu0GQnQcrHpBClXnHkCZ66ec/4s=; 7:LH5YsD6egb+IrwdPdsjFfL3wTX1Wjpg9TqsKtw+5PQiCE0uFzFYh8hMmH0ifKQY/3XwEFNz2AO2SCVn35wxFNUAEm7d3oPBk8QuURNX4xU0250oRIGm7Um1AK4mmtmO52EO7aH0vary4F6n0cC4vcSTOYVQSX1U8dkeNVMLbh6mKLf2NbNxv/YTFRK7+HC5V+HTR76FhBQsgNBNIPrG4CxZGdyYx1Brfq1UN0DP84ag3VLg/4D0dzjdpsqqF67QJ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3984842a-e6cd-4d83-f0ac-08d5300622de x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DB4PR07MB347; x-ms-traffictypediagnostic: DB4PR07MB347: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(202460600054446)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231022)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB347; x-forefront-prvs: 04976078F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(189002)(199003)(6916009)(6506006)(55016002)(236005)(9686003)(6436002)(5250100002)(189998001)(7696004)(2900100001)(99286004)(53936002)(8936002)(8656006)(4326008)(7736002)(3660700001)(68736007)(81166006)(81156014)(8676002)(2906002)(3280700002)(478600001)(54356999)(74316002)(101416001)(606006)(14454004)(66066001)(6306002)(54896002)(33656002)(316002)(105586002)(19609705001)(54906003)(86362001)(106356001)(6116002)(102836003)(3846002)(790700001)(97736004)(25786009)(5660300001)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348589805C7FDA7EEC685B0C2220DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3984842a-e6cd-4d83-f0ac-08d5300622de X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2017 11:02:05.3109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB347 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGee+9u7uuBq9rspNp2mBBitM+JAkTlSBDpP4RbBI29abDOW3X JIViGCX4gUlpOjKVzKl9oM7pIBOdFJlooZOcorb8gFJJMtIorG13gf/93uc85xyew8uQkm6B P6PRFbB6nVorp0VUfUpfYlh4r0QVMWyXRS2MrQminLUlKOqpY4OOJRO+LnwQJLS0/CIS5mYm iAukShSdyWo1haw+POayKHvUsE7n10de77KM0wbkjChDPgzgE/DO+RCVIREjwcMIyrqXCP7x FkGVxUS5XRSuJMHaLuULtQTcavjodTkR2KcWhW4XjaOh3bblmsUwUhwBjspIt4fEBgSNr56Q bs8+rICBxwuEm6U4BH5WWUielTDZO07w2xRgb7B4NouxCubv1CE3IxwIC1vzHp3EMphZaiT4 DBha+t+TPPvBl8UdAe/PgO+OSgGvB0PFtz4vB8JEYznieUgIjsk9PCvBUr3u1ZPAbP0sdAcA XIdgarXfu+AIlM9bKZ414DS0eofegKqtUW/DhACs2z9I9yUAB0Dnp1RefykAY/Og51oSzILp +W10F4UadwUyulpInAcrVfuNnvy+MFK/RPEWJUzX3Kd5DoXW5lWS5zCo27FRu/UmJOxAfhzL pedmHTuuZPWaDI7L0yl1bEE3cv2koZ7fCiuaXIuzIcwg+V5xzAOJSiJQF3JFuTYEDCmXig+r XJI4U11UzOrz0vTXtCxnQwcYSi4Tj5wTqyQ4S13A5rBsPqv/XyUYH38DSp1qe2ZPtmjPt2pF PcvTFbNtRaspK2M5RKnPiBQdKjFLXr8wbCpOmfyFs1c2ukSxqzo60Jz0J/EiWTxYgzsGbGea toMvmeN904PvaeaSS6+GL99cedMZVOH0r041+Rz8mxbHJW09MnSdVmwsn/TLlSXl0WdDhEGy ANFmfLxKTnHZ6qMhpJ5T/wN2xsV0RQMAAA== Archived-At: Subject: [rmcat] SCReAM code with L4S support 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, 20 Nov 2017 11:02:16 -0000 --_000_DB4PR07MB348589805C7FDA7EEC685B0C2220DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gentlepeople! The SCReAM code (https://github.com/EricssonResearch/scream ) is now update= d with L4S support. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson Research Network Protocols & E2E Performance Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com The world is full of magical things patiently waiting for our wits to grow sharper Bertrand Russell =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB348589805C7FDA7EEC685B0C2220DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Gentlepeople!

The SCReAM code (https://github.com/EricssonResearch/scream ) is now= updated with L4S support.

 

/Ingemar

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson Research<= /o:p>

Network Protocols &= E2E Performance

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson= @ericsson.com

www.ericsson.com

 

The world is full of magical things patiently

    waiting for our wits to grow sharper

           &= nbsp;   Bertrand Russell
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

 

--_000_DB4PR07MB348589805C7FDA7EEC685B0C2220DB4PR07MB348eurprd_-- From nobody Tue Nov 21 01:23:38 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 AA021129445 for ; Tue, 21 Nov 2017 01:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, SPF_PASS=-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 ojgCpEaZ1TMa for ; Tue, 21 Nov 2017 01:23:33 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B409129437 for ; Tue, 21 Nov 2017 01:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=886; q=dns/txt; s=iport; t=1511256213; x=1512465813; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=NHbfWKRnxNjJUF3f7jXe012w2FpakqzQUXatmEXi4oU=; b=Jx0j5lJWxjAFmw3hVEHa1FZDbjDd5i3vhKXHdOjiDCn7IhZfApd3RXIa P8k79IeRIqQnjMGGKjjWsSW37yrr4+1z0sNNVhX01IOVLvVtUPZIpgXfa Nnz4nu5utLyCBIwNQaFbQXilUxiyFFZqj1tgIbVdKfZSG7QJ29Dg0HQKJ A=; X-IronPort-AV: E=Sophos;i="5.44,432,1505779200"; d="scan'208";a="340437" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2017 09:23:31 +0000 Received: from [10.0.2.15] ([10.228.220.83]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAL9NUhW024710; Tue, 21 Nov 2017 09:23:30 GMT To: "rmcat@ietf.org" , "Xiaoqing Zhu (xiaoqzhu)" , "Jeromy Fu (jianfu)" From: Sergio Mena Message-ID: <21299c21-b29b-97c8-f402-2d4ec77db12d@cisco.com> Date: Tue, 21 Nov 2017 10:23:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [rmcat] ns3-rmcat open source code available 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, 21 Nov 2017 09:23:34 -0000 Dear rmcat group, As Xiaoqing mentioned in her update during last week's meeting, we are pleased to announce the availability of the ns3-rmcat open source repository on github: https://github.com/cisco/ns3-rmcat This is an ns3-simulated testbed where congestion control algorithms can be run/debugged/compared/etc. You will find two congestion control protocols already in there: * NADA (as of latest update presented by Xiaoqing) * Dummy (a simplistic CC implementation) It is important to note that all the congestion control algorithms share the same (sender-based) interface (which is a C++ abstract class); so other congestion control algorithms should be easy to implement. Please have a look at the repo's README for further details. We will be happy to receive your feedback/questions/bug reports/etc. Thanks, Jeromy Xiaoqing Sergio From nobody Wed Nov 22 08:53: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 9A9AD126D74 for ; Wed, 22 Nov 2017 08:53:49 -0800 (PST) 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, 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 ykNzj_7vbRUq for ; Wed, 22 Nov 2017 08:53:47 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 97A331201F8 for ; Wed, 22 Nov 2017 08:53:47 -0800 (PST) Received: from [130.209.247.112] (port=60739 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eHYHR-0004tj-Un for rmcat@ietf.org; Wed, 22 Nov 2017 16:53:46 +0000 From: Colin Perkins Content-Type: multipart/mixed; boundary="Apple-Mail=_CBA45ED4-4A7B-412C-9457-DE3256BC454C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <36735037-4559-4D64-81DF-85CE9F1120F8@csperkins.org> Date: Wed, 22 Nov 2017 16:53:44 +0000 To: "rmcat@ietf.org WG" X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 14 Archived-At: Subject: [rmcat] Minutes from IETF 100 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 Nov 2017 16:53:49 -0000 --Apple-Mail=_CBA45ED4-4A7B-412C-9457-DE3256BC454C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Minutes from the RMCAT working group session at IETF 100 are attached, = and have been uploaded to the proceedings site. Thanks to Gorry = Fairhurst for helping to take notes. Please send any comments or = corrections to the chairs. Colin --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_CBA45ED4-4A7B-412C-9457-DE3256BC454C Content-Disposition: attachment; filename=minutes-100-rmcat-00.txt Content-Type: text/plain; x-unix-mode=0660; name="minutes-100-rmcat-00.txt" Content-Transfer-Encoding: 7bit RTP Media Congestion Control Working Group Minutes - IETF 100 ============================================================= Reported by Colin Perkins and Gorry Fairhurst The RMCAT working group met at IETF 100 in Singapore, on 15 November 2017. The chairs started the meeting with a review of the working group status: - The cc-requirements, coupled-cc, and SCReAM drafts are with the RFC Editor - The SBD draft has passed WG last call and the write-up is ready, minor issues to resolve then will go to the IESG - The NADA draft has been updated based on WG last call comments, and is on the agenda for this meeting - The GCC draft is waiting an update from the authors - The eval-test draft is blocked on eval-criteria, and eval-criteria is waiting on an update. Varun Singh volunteered to do this update at the last meeting, and it's hoped this will be received soon. If not, the chairs will try to find an additional editor to complete the work. - The wireless tests draft has no open issues. Reviews and implementation experience are needed. - The video-traffic-model draft is ready for review, and close to WG last call. - The feedback-message draft will be discussed later in the meeting. - The cc-feedback draft has expired, but will be updated to track changes to the feedback-message. - The cc-codec-interactions and framework draft are blocked waiting for a proposal for updates that Varun and Zahed volunteered at IETF 99. Zahed noted that the framework needs only small updates to align with the RTP topologies RFC, but that it's unclear how to align cc-codec-interactions and the framework, and he's had no time to review. Thinks the framework is in good shape. Xiaoqing Zhu noted that Cisco is open sourcing code that implements the framework, but again she has issues finding time. Zahed suggested to ship the framework, and leave cc-codec-interactions until later: he's not convinced they need to align. Zahed to discuss with Varun soon, and update the WG on the mailing list with how they plan to proceed The status update concluded with a review of the milestones. ## NADA Xiaoqing Zhu summarised the changes made to the NADA draft based on implementation feedback from Julius Flohr, and presented performance results to show their benefits and the behaviour of the algorithm. She also noted that they'd added Fixed-FPS and Trace-driven codecs to their synthetic codecs test suite. These are believed to be more realistic than the previously implemented models, and have been used for their latest experiments. Xiaoqing believes the video-traffic-model draft has now been completed, but it needs further review from the working group. Xiaoqing noted that their ns3-rmcat RMCAT simulation code, that has been previously discussed in the working group, has now been made open source. Jonathan Lennox asked if their simulator uses RTCP feedback as in the cc-feedback draft? Not yet, since the cc-feedback draft is still changing. An update will be submitted to address review comments from Roland Bless and Michael Welzl, then they believe the draft will be completed. It's expected this will be ready for a second WG last call. Ingemar Johansson asked if the evaluations were with CBR-like video, or something more realistic. They're a mixture. Xiaoqing noted their next steps are to experiment with embedding NADA in Mozilla browsers. Jonathan Lennox asked what feedback mechanism they're using, and if they could use the cc-feedback draft. ## SCReAM Ingemar Johansson presented experiments using SCReAM for congestion control of video over mobile 4G/5G links for remote control of vehicles. This needs low latency and good quality video, so similar requirements to interactive video applications that RMCAT has targetted. Their implementation uses a non-standard RTCP feedback format, but they intend that this will be replaced with the cc-feedback message once it's stabilised. Ingemar noted that video codecs can be challenging to work with, and have limited tuning capabilities in many cases. Randell Jesup asked a number of questions for clarification on these results. The perform strea prioritisation using weighted credit based scheduling. Ingemar noted some issues with this priorisation, and it works quite ok, but there is room for improvement. He believes use of ECN would improve performance (the ECN results presented used a simulated bottleneck, but the others use a real network). Xiaoqing Zhu asked for clarification on the packet loss rates observed, and whether there were self-induced losses as the flows compete. Ingemar noted that it was around 0.5% packet loss in the real network tests. It would perhaps be interesting to see packet loss traces, and to explore the effects of non-congestive packet loss on the algorithms. There was some discussion about packet loss patterns, and it seems that it was a little bursty. There was also discussion on the causes of loss in the LTE scenario. ## RTCP Feedback for Congestion Control Zahed Sarker presented the results of the design team on RTCP feedback. The design team was formed after IETF 94 to propose a generic congestion feedback RTCP message. This has now been done, and the draft has been passed to the AVTCORE working group to finalise. Expected outcome is a standards track RFC from AVTCORE. The chairs thanked the design team for their work. - + - --Apple-Mail=_CBA45ED4-4A7B-412C-9457-DE3256BC454C-- From nobody Thu Nov 23 20:22: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 E80A31294DC for ; Thu, 23 Nov 2017 20:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 GiIgigLkzn0a for ; Thu, 23 Nov 2017 20:22:12 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B5D1294E0 for ; Thu, 23 Nov 2017 20:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2270; q=dns/txt; s=iport; t=1511497332; x=1512706932; h=from:to:cc:subject:date:message-id:mime-version; bh=dinsh1LMZOV4vjOjsxEq/GbaJr948NdXx9Jajdm09kM=; b=Hc900+x4tdVTlzeW3ySaZbdwP1GdvNEB9czR6oK1VMHuFXpgVCVrp9KU kA7T+w5HYiOLcW7+bvmySuYVRQQz+v5hzuue7pydv2nHXsN4EV5n1ZY8v dIhD3XirW2yqT1fP1Ajri9pcclTuBMETfwvy2TSote68YXBhuzJNyB8Sf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAABknRda/5xdJa1bGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJKcmZuJweGRIdTjxWGMwECjGqFSYIRCiWFFoRYPxgBAQEBAQEBAQF?= =?us-ascii?q?rHQuFJHsSAQwBHDQjJwQOiUNkEKseg3yHAgEBAQEBAQQBAQEBAQEBAQEaBYM6g?= =?us-ascii?q?geBVYFphhVch04FjzeDDJADApUKk06WDQIRGQGBOQEfOYFQbxWCY4RUdwGJaIE?= =?us-ascii?q?UAQEB?= X-IronPort-AV: E=Sophos; i="5.44,444,1505779200"; d="scan'208,217"; a="35158618" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Nov 2017 04:22:11 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vAO4MBsG021803 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 Nov 2017 04:22:11 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 23 Nov 2017 22:22:10 -0600 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.1320.000; Thu, 23 Nov 2017 22:22:10 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: "rmcat@ietf.org" CC: "Sergio Mena de la Cruz (semena)" , "Jeromy Fu (jianfu)" Thread-Topic: NADA evaluation results in ns3 Thread-Index: AQHTZNo36PKC0M7Kb0yct1PyC0QDoQ== Date: Fri, 24 Nov 2017 04:22:10 +0000 Message-ID: <1511497352660.10391@cisco.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.24.214.232] Content-Type: multipart/alternative; boundary="_000_151149735266010391ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [rmcat] NADA evaluation results in ns3 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 Nov 2017 04:22:14 -0000 --_000_151149735266010391ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Folks, As mentioned during the presentation at IETF-100, we are sharing the comple= te set of evaluation results of NADA using the recently open-sourced ns3-rm= cat module via the following Dropbox link: https://www.dropbox.com/s/sgrcilpv0ez2vwf/2017-11-20-ietf-rmcat-nada-eval.p= df?dl=3D0 This contains results for both the basic wired test cases (draft-ietf-rmcat= -nada-05) and wifi test cases (Sec. 4 in draft-ietf-rmcat-wireless-tests-04= ). For ease of comparison, we have included results from both the previous= -04 and current -05 versions, whenever previous results are still availabl= e. Thanks, Xiaoqing --_000_151149735266010391ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Folks, 


As mentioned during the presentation at IETF-100, we are sharing th= e complete set of evaluation results of NADA using the recently open-source= d ns3-rmcat module via the following Dropbox link: 


https://www.dropbox.com/s/sgrcilpv0ez2vwf/2017-11-= 20-ietf-rmcat-nada-eval.pdf?dl=3D0


This contains results for both the basic wired test cases (draft-ietf-rm= cat-nada-05) and wifi test cases (Sec. 4 in draft-ietf-rmcat-wire= less-tests-04).  For ease of comparison, we have included results from=  both the previous -04 and current -05 versions, w= henever previous results are still available. 


Thanks,

Xiaoqing 

--_000_151149735266010391ciscocom_-- From nobody Mon Nov 27 10:45:28 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 A6E6E12426E; Mon, 27 Nov 2017 10:45:25 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151180832558.30934.3453178107488215708@ietfa.amsl.com> Date: Mon, 27 Nov 2017 10:45:25 -0800 Archived-At: Subject: [rmcat] I-D Action: draft-ietf-rmcat-sbd-09.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 Nov 2017 18:45:26 -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 WG of the IETF. Title : Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. Authors : David Hayes Simone Ferlin Michael Welzl Kristian Hiorth Filename : draft-ietf-rmcat-sbd-09.txt Pages : 24 Date : 2017-11-27 Abstract: This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. It relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed. This mechanism complements the coupled congestion control mechanism in draft-ietf-rmcat-coupled-cc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-sbd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rmcat-sbd-09 https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-sbd-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-sbd-09 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/