From lars@netapp.com Wed Oct 2 15:57:52 2013 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 3E7F611E80E8 for ; Wed, 2 Oct 2013 15:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkeLoZ-Fiq2T for ; Wed, 2 Oct 2013 15:57:41 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 22E5221F92E7 for ; Wed, 2 Oct 2013 15:56:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1022,1371106800"; d="asc'?scan'208";a="96065558" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 02 Oct 2013 15:55:59 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.46]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 2 Oct 2013 15:55:58 -0700 From: "Eggert, Lars" To: "rmcat@ietf.org WG" Thread-Topic: [rmcat] time to get busy Thread-Index: AQHOrVOiO8LKsMovVEmQjqmLEspWmZnin8wA Date: Wed, 2 Oct 2013 22:55:57 +0000 Message-ID: <0E869E54-7F54-42E6-80DA-BE98533DEE4A@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_FC7AF27C-8144-45A4-BA14-66B035342150"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [rmcat] time to get busy X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2013 22:57:52 -0000 --Apple-Mail=_FC7AF27C-8144-45A4-BA14-66B035342150 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, we're now only three weeks away from the ID cutoff for Vancouver. There = hasn't been much progress on the list since Berlin, at least not much = that was visible to us chairs. We really need folks to review the requirements documents, and we really = need to make some more progress on the evaluation criteria = (https://sites.google.com/site/ietfrmcatsolutionevaluations/ is a good = start!) Please also start sending agenda requests to Mirja and me. We asked for = a long slot, but we may scale down to a shorter slot based on mailing = list activity between now and the agenda cutoff. Lars On Sep 9, 2013, at 4:56, "Eggert, Lars" wrote: > it's only six short weeks to the ID submission cutoff for Vancouver. = I'd like us to complete some work before then; specifically: >=20 > (1) Reviews for draft-ietf-rmcat-cc-requirements-00, so that we can = last-call it in Vancouver. Any volunteers? >=20 > (2) Have some rough consensus on at least one initial evaluation = scenario. This includes a network topology, a traffic workload and a = list of performance metrics for that scenario. >=20 > On (2), is the design team still having calls? I have not seen any = announcements on the list after Berlin. If not, we should probably = restart the calls. --Apple-Mail=_FC7AF27C-8144-45A4-BA14-66B035342150 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUkykfNZcnpRveo1xAQJLbwP+PA1I0vFKrknPUQWmGPjR/FYnyuuUwHnc RB7aFemWqljekziA6kMC/Weh5v6y54fIDjnwVTBI6jjjtLyCOYLx6/D17Kay5gRZ h4ZV2UyGPiZ5tGTKsMY3gYmw3I1GaRMHK0Qh31itAYKmaIM10cfBo8a14hW7CcCn y5tcfn37DzU= =/idl -----END PGP SIGNATURE----- --Apple-Mail=_FC7AF27C-8144-45A4-BA14-66B035342150-- From michawe@ifi.uio.no Wed Oct 2 23:49:57 2013 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 8537D21F9E26 for ; Wed, 2 Oct 2013 23:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DM0QZyd6NNU5 for ; Wed, 2 Oct 2013 23:49:45 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEE121F8EB2 for ; Wed, 2 Oct 2013 23:49:26 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VRciz-0001lA-Dv; Thu, 03 Oct 2013 08:49:25 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VRciy-0008Vu-WB; Thu, 03 Oct 2013 08:49:25 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <0E869E54-7F54-42E6-80DA-BE98533DEE4A@netapp.com> Date: Thu, 3 Oct 2013 08:49:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99B2ABEF-D25C-4486-9DAD-6B6A1DD71C6B@ifi.uio.no> References: <0E869E54-7F54-42E6-80DA-BE98533DEE4A@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 3 total rcpts 8126 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.4, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.446, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 18A090395F12BE7DC087C8871E89F8321A37BDAD X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -63 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3154 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: "rmcat@ietf.org WG" Subject: Re: [rmcat] time to get busy X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 06:49:57 -0000 Hi, I'd like to ask for a slot on draft-welzl-rmcat-coupled-cc-02 (which = we're going to submit ASAP), and with title "Update on coupled congestion control", presenter myself, and duration = 20 min. The point is to address the criticism that we got: we'll present = a much simpler variant of the algorithm, and explain what it is that = made the other variant more complicated. The plan for the draft is to = include both variants, as each has its pro's and con's, and give an = update on what we have been and will be doing. Cheers, Michael On 3. okt. 2013, at 00:55, Eggert, Lars wrote: > Hi, >=20 > we're now only three weeks away from the ID cutoff for Vancouver. = There hasn't been much progress on the list since Berlin, at least not = much that was visible to us chairs. >=20 > We really need folks to review the requirements documents, and we = really need to make some more progress on the evaluation criteria = (https://sites.google.com/site/ietfrmcatsolutionevaluations/ is a good = start!) >=20 > Please also start sending agenda requests to Mirja and me. We asked = for a long slot, but we may scale down to a shorter slot based on = mailing list activity between now and the agenda cutoff. >=20 > Lars >=20 > On Sep 9, 2013, at 4:56, "Eggert, Lars" wrote: >> it's only six short weeks to the ID submission cutoff for Vancouver. = I'd like us to complete some work before then; specifically: >>=20 >> (1) Reviews for draft-ietf-rmcat-cc-requirements-00, so that we can = last-call it in Vancouver. Any volunteers? >>=20 >> (2) Have some rough consensus on at least one initial evaluation = scenario. This includes a network topology, a traffic workload and a = list of performance metrics for that scenario. >>=20 >> On (2), is the design team still having calls? I have not seen any = announcements on the list after Berlin. If not, we should probably = restart the calls. >=20 From aeh@db.org Sun Oct 6 05:16:40 2013 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 9388421E8096 for ; Sun, 6 Oct 2013 05:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U964Hx52WVYZ for ; Sun, 6 Oct 2013 05:16:34 -0700 (PDT) Received: from mailstore06.sysedata.no (b.mail.tornado.no [195.159.29.130]) by ietfa.amsl.com (Postfix) with ESMTP id E6FDC21E808F for ; Sun, 6 Oct 2013 05:16:31 -0700 (PDT) Received: from [46.15.202.74] (helo=alfred-heggestads-macbook-pro.local) by mailstore06.sysedata.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1VSnG9-0007Cd-P4 for rmcat@ietf.org; Sun, 06 Oct 2013 14:16:29 +0200 Message-ID: <5251549C.3080500@db.org> Date: Sun, 06 Oct 2013 14:16:28 +0200 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: rmcat@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rmcat] comments on draft-alvestrand-rmcat-remb-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 12:16:40 -0000 Hi, I have some comments/questions about draft-alvestrand-rmcat-remb-02 - is the new RTCP AFB message valid for all kinds of streams ? audio, video etc ? - the maximum bitrate, is it defined as the maximum bitrate for a particular stream, or the maximum bitrate for the whole "Session" ? - the message is using a unique identifier "REMB" to de-multiplex incoming AFB messages, is this method defined in a spec somewhere, and is there a central registry of other types of AFB messages? - section 2.3 OPEN ISSUE, I dont think explicit signaling is needed. /alfred From vsingh.ietf@gmail.com Sun Oct 6 09:46:38 2013 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 8F91C11E8114 for ; Sun, 6 Oct 2013 09:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.4 X-Spam-Level: ** X-Spam-Status: No, score=2.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz0nDbzKHYlc for ; Sun, 6 Oct 2013 09:46:27 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD7411E8118 for ; Sun, 6 Oct 2013 09:46:20 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so13589246iej.38 for ; Sun, 06 Oct 2013 09:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8dWgu/9/cOel5v154oboVZwfZjuHBu9Wt5cFJVC52AI=; b=S61LleCXa4ot9J+mNhyNPafIqtP95JDuDqIZxPB32yXizl0Ty4F/8o4KldTiFIIFWK kbMv3I0EHep+W97njHvTChPLFGGhPxNkZBs7edlf0ppvCZ+U04utXIhKWwELI8VtxlVv 0R3+V6f4oWRHIXi4jlogxsa5mrHz1urL5p9C9NZiMlIUJ6gdS2ljflBjZTiF+hTPWP6Q XHXkJXj8an4AddxeOlAhOolmpqOCFFH8ubf5VyjAUWc1sCBrZAwfycz2S5NnTYqJGamA LvvvhlOGYOOQFtDuP/mM7NrzsfbzSHqljwAc0qR0HZe22RVvv1QmuaO/75E1G++CPVt4 vRKA== X-Received: by 10.50.106.20 with SMTP id gq20mr13930398igb.36.1381077978469; Sun, 06 Oct 2013 09:46:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.7.35 with HTTP; Sun, 6 Oct 2013 09:45:58 -0700 (PDT) In-Reply-To: <5251549C.3080500@db.org> References: <5251549C.3080500@db.org> From: Varun Singh Date: Sun, 6 Oct 2013 19:45:58 +0300 Message-ID: To: "Alfred E. Heggestad" Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG Subject: Re: [rmcat] comments on draft-alvestrand-rmcat-remb-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 16:46:38 -0000 Hi Alfred, Some comment inline. -Varun On Sun, Oct 6, 2013 at 3:16 PM, Alfred E. Heggestad wrote: > Hi, > > I have some comments/questions about draft-alvestrand-rmcat-remb-02 > > > - is the new RTCP AFB message valid for all kinds of streams ? > audio, video etc ? > It depends on how many and which SSRCs are reported in the feedback message. As per the draft, it is up to the implementation (or the congestion control algorithm) to choose which SSRCs, i.e., it could report just the SSRCs of audio or video or a combination. > - the maximum bitrate, is it defined as the maximum bitrate for > a particular stream, or the maximum bitrate for the whole "Session" ? > One method of calculating the receiver's maximum estimate is defined by Google's congestion control (GCC) in http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion As per GCC, REMB can be used for reporting the sum of the receiver estimate across all media streams that share the same end-to-end path. I supposed the SSRCs of the multiple media streams that make up the aggregate estimate are reported in the block. > - the message is using a unique identifier "REMB" to de-multiplex incoming > AFB messages, is this method defined in a spec somewhere, and is there The demultiplexing is defined in Section 6.4 of RFC4585, https://tools.ietf.org/html/rfc4585#section-6.4 > a central registry of other types of AFB messages? > > - section 2.3 OPEN ISSUE, I dont think explicit signaling is needed. > > > > > /alfred -- http://www.netlab.tkk.fi/~varun/ From ldecicco@gmail.com Tue Oct 8 06:03:28 2013 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 BAC3521E819C for ; Tue, 8 Oct 2013 06:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA5L+V0NrWUg for ; Tue, 8 Oct 2013 06:03:24 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B729421E808A for ; Tue, 8 Oct 2013 06:02:47 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id m15so6368541wgh.5 for ; Tue, 08 Oct 2013 06:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=m9Btn6qDdD+X+Qhd9B59qOKAf1sRmZKd8b2qDNpvOSs=; b=jZy+ZBuKgyFOPDpZU/2cuC4nh+2t/6B/UdeZyRKP3uyGCCIKJEh4SEh1slprmv4npc 5zxSgtEIKprzcoC0WttNDRs0HEW3uYfnR0Dtu2j3KtpUMFh0/EpYmKx+QpSlIVs9vZvk /hnUFV/Ba1DHQhaHRacZmF+GkyL+dauSuR5EpmMHMsS86tGp2XFx0rsMWUe3pNoc0j81 K7TeQ75o94eN67oMUep7OFCVX2g7VM4+Rmg7N7Y7rbAjCIgbtcP7k4ZlXTVg4vBVG1ZX S/9uRXBOluEjH3z75QGImgFLv6lT4R+7u+QdxKEGdNFTuuY4zkfUPL7SQwJbqU9PMW9c zMMg== MIME-Version: 1.0 X-Received: by 10.180.107.99 with SMTP id hb3mr23867380wib.34.1381237366706; Tue, 08 Oct 2013 06:02:46 -0700 (PDT) Received: by 10.216.64.198 with HTTP; Tue, 8 Oct 2013 06:02:46 -0700 (PDT) Date: Tue, 8 Oct 2013 15:02:46 +0200 Message-ID: From: Luca De Cicco To: rmcat WG Content-Type: multipart/alternative; boundary=e89a8f23558197dd8c04e83a62ea Subject: [rmcat] fairness/unfairness metrics X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 13:03:28 -0000 --e89a8f23558197dd8c04e83a62ea Content-Type: text/plain; charset=ISO-8859-1 Dear all, I was wondering what's the status about the fairness/unfairness metric to be adopted for evaluating rmcat flows. In "draft-singh-rmcat-cc-eval-03" I only found some comments (open issue (1)) on "unfairness" defining three criteria. Thanks, -- Luca De Cicco, PhD, Eng. Politecnico di Bari Dipartimento di Elettrotecnica ed Elettronica Via Re David, 200 - Bari - ITALY Office: +39 080 596 3851 http://c3lab.poliba.it/index.php/LDC --e89a8f23558197dd8c04e83a62ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

I was w= ondering what's the status about the fairness/unfairness metric to be a= dopted for evaluating rmcat flows.
In "draft-singh-rmcat-cc-= eval-03" I only found some comments (open issue (1)) on "unfairne= ss" defining three criteria.=A0

Thanks,
--
Luca De Cicco, PhD, Eng= .
Politecnico di Bari
Dipartimento di Elettrotecnica ed ElettronicaVia Re David, 200 - Bari - ITALY
Office: +39 080 596 3851
--e89a8f23558197dd8c04e83a62ea-- From vsingh.ietf@gmail.com Tue Oct 8 06:46:54 2013 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 44E7121E80A9 for ; Tue, 8 Oct 2013 06:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=2.500, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOMbX0c7NDDM for ; Tue, 8 Oct 2013 06:46:51 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id E9FF721E8193 for ; Tue, 8 Oct 2013 06:46:50 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar20so1499445iec.35 for ; Tue, 08 Oct 2013 06:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bh/0Z6UE9DnIvYT4/VygJ3I6SqG7sdBQQJrFTeI4V5U=; b=E6dyYO0KCHwjqVEtZSNVRoV+YisjY58f0DQN5WsDuERR+zPkefUpc0eJvqWeD2vw8f BxY+btjyu/DgvO6HGEuhs0RIBhABS2QuUhQP5Z+jH2d5NmsrvJLxTXyP8VofEi+MNMkR tUzKCVGhk98KsOY0mTnZKKV15LlG2F7SzrkXefscPxKDYwH+0+dUJnykrA9ORT7u1ox3 Z6H+kI3R79mlXy2JTEaYIFTHtNrhEdywz+eGzTVZA/5oQgfMtH9hTOqUIGiVByUdCzZW ZLr0kil3I/pO7I7bBJ8+/rpMwYAC1nX596snCDzbOjq1dohDdnERe/hlxbILl2+sZaFP m5Zw== X-Received: by 10.50.39.51 with SMTP id m19mr21235639igk.51.1381240010214; Tue, 08 Oct 2013 06:46:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Tue, 8 Oct 2013 06:46:30 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Tue, 8 Oct 2013 16:46:30 +0300 Message-ID: To: Luca De Cicco Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG Subject: Re: [rmcat] fairness/unfairness metrics X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 13:46:54 -0000 Hi Luca, The last design meeting (in September) concluded that each scenario would describe the expected behaviour or describe what behavior of the congestion control it is attempting to verify. For example the scenarios already implemented in some papers are described in: https://sites.google.com/site/ietfrmcatsolutionevaluations/ , however, comments on desired behaviour is still pending. The three criteria in the cc-eval draft are more like a test than a metric and may not be applicable in all the cases. Cheers, Varun On Tue, Oct 8, 2013 at 4:02 PM, Luca De Cicco wrote: > Dear all, > > I was wondering what's the status about the fairness/unfairness metric to be > adopted for evaluating rmcat flows. > In "draft-singh-rmcat-cc-eval-03" I only found some comments (open issue > (1)) on "unfairness" defining three criteria. > > Thanks, > -- > Luca De Cicco, PhD, Eng. > Politecnico di Bari > Dipartimento di Elettrotecnica ed Elettronica > Via Re David, 200 - Bari - ITALY > Office: +39 080 596 3851 > http://c3lab.poliba.it/index.php/LDC -- http://www.netlab.tkk.fi/~varun/ From ldecicco@gmail.com Tue Oct 8 07:54:44 2013 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 348B721E818C for ; Tue, 8 Oct 2013 07:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHXPJ6rSyQSP for ; Tue, 8 Oct 2013 07:54:42 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6558621E80A7 for ; Tue, 8 Oct 2013 07:54:41 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ez12so6708317wid.14 for ; Tue, 08 Oct 2013 07:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6t+CvmfVveUjTw+a5u4W2h341LH5+Vi6i/6koDJe4/8=; b=eqynti1wQOIMdNDu6XVA7EAZD6RaHxKOY8DxP2XpvkSyrjSEP6Pw4bqzlvmHfDOpXR muuBf5NjW6fNTmPSl9XwnaemShr2pTVgU24mlGYZWD7dy8yMS8jXSHZK+WVH/3hG+vW/ rTbDHJrr8lb5Uh6SCejFdkCQMyZDURp3z01ryWbrDMOMLcvzHPR7sbXkAmrc3el8OLV0 HKpUnHAcpn/Ab9m6QQP0hfkH0UVkcfcIZxslc2W39bWbkYfSDWDqO8K53c7C8SNgHlD2 ZLQANRxJ2nEeQ8ZVtDXUqBqi97C6sY31PoPqsfkGy1RX7X0ZnvbpsCJyKCl3MTkWY8Dk JzJA== MIME-Version: 1.0 X-Received: by 10.180.189.17 with SMTP id ge17mr24033355wic.53.1381244080355; Tue, 08 Oct 2013 07:54:40 -0700 (PDT) Received: by 10.216.64.198 with HTTP; Tue, 8 Oct 2013 07:54:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Oct 2013 16:54:40 +0200 Message-ID: From: Luca De Cicco To: Varun Singh Content-Type: multipart/alternative; boundary=001a11c22866c2001f04e83bf2dd Cc: rmcat WG Subject: Re: [rmcat] fairness/unfairness metrics X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 14:54:44 -0000 --001a11c22866c2001f04e83bf2dd Content-Type: text/plain; charset=ISO-8859-1 Dear Varun, thanks for the clear explanation :). I have a follow-up question: what's the reason for considering only RED as bottleneck queue type? Also, why is drop-tail not to be considered? Best, Luca On Tue, Oct 8, 2013 at 3:46 PM, Varun Singh wrote: > Hi Luca, > > The last design meeting (in September) concluded that each scenario > would describe the expected behaviour or describe what behavior of > the congestion control it is attempting to verify. > > For example the scenarios already implemented in some papers are > described in: https://sites.google.com/site/ietfrmcatsolutionevaluations/ > , however, > comments on desired behaviour is still pending. > > The three criteria in the cc-eval draft are more like a test than a > metric and may > not be applicable in all the cases. > > Cheers, > Varun > > > On Tue, Oct 8, 2013 at 4:02 PM, Luca De Cicco wrote: > > Dear all, > > > > I was wondering what's the status about the fairness/unfairness metric > to be > > adopted for evaluating rmcat flows. > > In "draft-singh-rmcat-cc-eval-03" I only found some comments (open issue > > (1)) on "unfairness" defining three criteria. > > > > Thanks, > > -- > > Luca De Cicco, PhD, Eng. > > Politecnico di Bari > > Dipartimento di Elettrotecnica ed Elettronica > > Via Re David, 200 - Bari - ITALY > > Office: +39 080 596 3851 > > http://c3lab.poliba.it/index.php/LDC > > > > -- > http://www.netlab.tkk.fi/~varun/ > --001a11c22866c2001f04e83bf2dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Varun,

thanks for the clear explan= ation :).

I have a follow-up question: what's = the reason for considering only RED as bottleneck
queue type? Als= o, why is drop-tail not to be considered?

Best,
=
Luca


On Tue, Oct 8, 2013 at 3:46 PM, Varun Si= ngh <vsingh.ietf@gmail.com> wrote:
Hi Luca,

The last design meeting (in September) concluded that each scenario
would describe the expected behaviour or describe what behavior of
the congestion control it is attempting to verify.

For example the scenarios already implemented in some papers are
described in: https://sites.google.com/site/ietfrmcatsolutio= nevaluations/
, however,
comments on desired behaviour is still pending.

The three criteria in the cc-eval draft are more like a test than a
metric and may
not be applicable in all the cases.

Cheers,
Varun


On Tue, Oct 8, 2013 at 4:02 PM, Luca De Cicco <ldecicco@gmail.com> wrote:
> Dear all,
>
> I was wondering what's the status about the fairness/unfairness me= tric to be
> adopted for evaluating rmcat flows.
> In "draft-singh-rmcat-cc-eval-03" I only found some comments= (open issue
> (1)) on "unfairness" defining three criteria.
>
> Thanks,
> --
> Luca De Cicco, PhD, Eng.
> Politecnico di Bari
> Dipartimento di Elettrotecnica ed Elettronica
> Via Re David, 200 - Bari - ITALY
> Office: +39 080 596 3851
> htt= p://c3lab.poliba.it/index.php/LDC



--
http://www.n= etlab.tkk.fi/~varun/

--001a11c22866c2001f04e83bf2dd-- From vsingh.ietf@gmail.com Tue Oct 8 08:22:37 2013 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 D220B21E80A5 for ; Tue, 8 Oct 2013 08:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5g02TIC49Tm for ; Tue, 8 Oct 2013 08:22:37 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D8A8621E80A6 for ; Tue, 8 Oct 2013 08:22:36 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so20225576iec.30 for ; Tue, 08 Oct 2013 08:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QiRiZIRdSPc6oXb2XztKoMVOHjrBlpOOfBI6Kiw2g8U=; b=MV+YTbqGuMhVTVl6qJNaBJtrSeKdSSfVxiGG+mMMM32Tcikzr1EA71whGmj4VRB0Ap fT24tVhzGma4aDgjP1xEZUKUEecQgcW5Q4uSGMU5N0/r52Ovyd2yhdwyNn677PqYsbXm JSG+mpAOATKZBDb+p5mf7nd+2UeiRU2PtPklUBN5Rf33aFcQq2A2UQB/jSuAdArjqr/g BLPMbEDns9k6T2SBfWuod/Seb6lrcf+YLAtBDNGbjOJgeLU2xsUjIV8XCFUQewXS1a8c IlC7+9997dFmDMfhyNYrZDIOlAjkYS1WgcGpZWNynkurXJd3N5dBB1tALHSKCpB6i52q DW8A== X-Received: by 10.42.61.147 with SMTP id u19mr1451357ich.36.1381245756107; Tue, 08 Oct 2013 08:22:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Tue, 8 Oct 2013 08:22:16 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Tue, 8 Oct 2013 18:22:16 +0300 Message-ID: To: Luca De Cicco Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG Subject: Re: [rmcat] fairness/unfairness metrics X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 15:22:38 -0000 Hi Luca, We do consider Droptail, it is the default queue type (if it is not already mentioned, I'll make it more explicit). The open issue (no. 6) is if we should consider others, at the Berlin meeting the conclusion was to start with Droptail and move to other types of queue when we have more information about them. Cheers, Varun On Tue, Oct 8, 2013 at 5:54 PM, Luca De Cicco wrote: > Dear Varun, > > thanks for the clear explanation :). > > I have a follow-up question: what's the reason for considering only RED as > bottleneck > queue type? Also, why is drop-tail not to be considered? > > Best, > Luca > > > On Tue, Oct 8, 2013 at 3:46 PM, Varun Singh wrote: >> >> Hi Luca, >> >> The last design meeting (in September) concluded that each scenario >> would describe the expected behaviour or describe what behavior of >> the congestion control it is attempting to verify. >> >> For example the scenarios already implemented in some papers are >> described in: https://sites.google.com/site/ietfrmcatsolutionevaluations/ >> , however, >> comments on desired behaviour is still pending. >> >> The three criteria in the cc-eval draft are more like a test than a >> metric and may >> not be applicable in all the cases. >> >> Cheers, >> Varun >> >> >> On Tue, Oct 8, 2013 at 4:02 PM, Luca De Cicco wrote: >> > Dear all, >> > >> > I was wondering what's the status about the fairness/unfairness metric >> > to be >> > adopted for evaluating rmcat flows. >> > In "draft-singh-rmcat-cc-eval-03" I only found some comments (open issue >> > (1)) on "unfairness" defining three criteria. >> > >> > Thanks, >> > -- >> > Luca De Cicco, PhD, Eng. >> > Politecnico di Bari >> > Dipartimento di Elettrotecnica ed Elettronica >> > Via Re David, 200 - Bari - ITALY >> > Office: +39 080 596 3851 >> > http://c3lab.poliba.it/index.php/LDC >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ > > -- http://www.netlab.tkk.fi/~varun/ From aeh@db.org Tue Oct 8 11:41:20 2013 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 46DB621E81EE for ; Tue, 8 Oct 2013 11:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IAyx2oV919O for ; Tue, 8 Oct 2013 11:41:15 -0700 (PDT) Received: from mailstore06.sysedata.no (b.mail.tornado.no [195.159.29.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8B921E8113 for ; Tue, 8 Oct 2013 11:41:03 -0700 (PDT) Received: from [46.15.202.74] (helo=alfred-heggestads-macbook-pro.local) by mailstore06.sysedata.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1VTcDN-0004xd-7L; Tue, 08 Oct 2013 20:41:01 +0200 Message-ID: <525451BC.5030703@db.org> Date: Tue, 08 Oct 2013 20:41:00 +0200 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Varun Singh References: <5251549C.3080500@db.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmcat WG Subject: Re: [rmcat] comments on draft-alvestrand-rmcat-remb-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 18:41:20 -0000 Hi Varun, okay, thanks for the info! /alfred On 10/6/13 6:45 PM, Varun Singh wrote: > Hi Alfred, > > Some comment inline. > > -Varun > > On Sun, Oct 6, 2013 at 3:16 PM, Alfred E. Heggestad wrote: >> Hi, >> >> I have some comments/questions about draft-alvestrand-rmcat-remb-02 >> >> >> - is the new RTCP AFB message valid for all kinds of streams ? >> audio, video etc ? >> > > It depends on how many and which SSRCs are reported in the feedback message. > As per the draft, it is up to the implementation (or the congestion > control algorithm) > to choose which SSRCs, i.e., it could report just the SSRCs of audio > or video or a combination. > >> - the maximum bitrate, is it defined as the maximum bitrate for >> a particular stream, or the maximum bitrate for the whole "Session" ? >> > > One method of calculating the receiver's maximum estimate is defined by > Google's congestion control (GCC) in > http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion > > As per GCC, REMB can be used for reporting the sum of the receiver > estimate across all media streams that share the same end-to-end path. > I supposed the SSRCs of the multiple media streams that make up the > aggregate estimate > are reported in the block. > >> - the message is using a unique identifier "REMB" to de-multiplex incoming >> AFB messages, is this method defined in a spec somewhere, and is there > > The demultiplexing is defined in Section 6.4 of RFC4585, > https://tools.ietf.org/html/rfc4585#section-6.4 > >> a central registry of other types of AFB messages? >> >> - section 2.3 OPEN ISSUE, I dont think explicit signaling is needed. >> >> >> >> >> /alfred > > > From michawe@ifi.uio.no Wed Oct 9 01:02:34 2013 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 C51BC21E80F1 for ; Wed, 9 Oct 2013 01:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1EpRvyOD9Sx for ; Wed, 9 Oct 2013 01:02:30 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id E2F6321E80F5 for ; Wed, 9 Oct 2013 01:02:29 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VToiy-0007cu-Fo; Wed, 09 Oct 2013 10:02:28 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VToiy-0007R2-0T; Wed, 09 Oct 2013 10:02:28 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: Date: Wed, 9 Oct 2013 10:02:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Varun Singh X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 8259 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 61C039124B76A8744FE7FE097AFF1E381244996F X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3230 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Luca De Cicco Subject: Re: [rmcat] fairness/unfairness metrics X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 08:02:34 -0000 Hi, IMO, a good reason to use only DropTail and RED would be that RED is, so = far, the only IETF-recommended mechanism, and it'd be better for rmcat = evaluations to not be based on a moving target... Cheers, Michael On 8. okt. 2013, at 17:22, Varun Singh wrote: > Hi Luca, >=20 > We do consider Droptail, it is the default queue type (if it is not > already mentioned, I'll make it more explicit). > The open issue (no. 6) is if we should consider others, at the Berlin > meeting the conclusion was to start with Droptail and move to other > types of queue when we have more information about them. >=20 > Cheers, > Varun >=20 > On Tue, Oct 8, 2013 at 5:54 PM, Luca De Cicco = wrote: >> Dear Varun, >>=20 >> thanks for the clear explanation :). >>=20 >> I have a follow-up question: what's the reason for considering only = RED as >> bottleneck >> queue type? Also, why is drop-tail not to be considered? >>=20 >> Best, >> Luca >>=20 >>=20 >> On Tue, Oct 8, 2013 at 3:46 PM, Varun Singh = wrote: >>>=20 >>> Hi Luca, >>>=20 >>> The last design meeting (in September) concluded that each scenario >>> would describe the expected behaviour or describe what behavior of >>> the congestion control it is attempting to verify. >>>=20 >>> For example the scenarios already implemented in some papers are >>> described in: = https://sites.google.com/site/ietfrmcatsolutionevaluations/ >>> , however, >>> comments on desired behaviour is still pending. >>>=20 >>> The three criteria in the cc-eval draft are more like a test than a >>> metric and may >>> not be applicable in all the cases. >>>=20 >>> Cheers, >>> Varun >>>=20 >>>=20 >>> On Tue, Oct 8, 2013 at 4:02 PM, Luca De Cicco = wrote: >>>> Dear all, >>>>=20 >>>> I was wondering what's the status about the fairness/unfairness = metric >>>> to be >>>> adopted for evaluating rmcat flows. >>>> In "draft-singh-rmcat-cc-eval-03" I only found some comments (open = issue >>>> (1)) on "unfairness" defining three criteria. >>>>=20 >>>> Thanks, >>>> -- >>>> Luca De Cicco, PhD, Eng. >>>> Politecnico di Bari >>>> Dipartimento di Elettrotecnica ed Elettronica >>>> Via Re David, 200 - Bari - ITALY >>>> Office: +39 080 596 3851 >>>> http://c3lab.poliba.it/index.php/LDC >>>=20 >>>=20 >>>=20 >>> -- >>> http://www.netlab.tkk.fi/~varun/ >>=20 >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ From wes@mti-systems.com Wed Oct 9 06:06:43 2013 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 1C81F11E80E0 for ; Wed, 9 Oct 2013 06:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD3Z8mNgng-X for ; Wed, 9 Oct 2013 06:06:37 -0700 (PDT) Received: from atl4mhob01.myregisteredsite.com (atl4mhob01.myregisteredsite.com [209.17.115.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4077321F9EE5 for ; Wed, 9 Oct 2013 06:06:01 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob01.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r99D61nR019288 for ; Wed, 9 Oct 2013 09:06:01 -0400 Received: (qmail 22958 invoked by uid 0); 9 Oct 2013 13:06:01 -0000 X-TCPREMOTEIP: 107.45.236.150 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.236.150) by 0 with ESMTPA; 9 Oct 2013 13:06:00 -0000 Message-ID: <525554B3.7040601@mti-systems.com> Date: Wed, 09 Oct 2013 09:05:55 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Welzl References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rmcat WG , Luca De Cicco , Varun Singh Subject: Re: [rmcat] fairness/unfairness metrics X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 13:06:43 -0000 On 10/9/2013 4:02 AM, Michael Welzl wrote: > Hi, > > IMO, a good reason to use only DropTail and RED would be that RED is, > so far, the only IETF-recommended mechanism, and it'd be better for > rmcat evaluations to not be based on a moving target... > I'm not aware of an IETF recommendation for RED. 2309 was by the E2ERG, not an IETF consensus document, as I understand. Given that, and the sensitivity to parameterizing RED, I would personally be fine with tail-drop queues only, though I understand the motivation here to be able to show performance in cooperation with an AQM. IMHO, that can be left as future work. -- Wes Eddy MTI Systems From michawe@ifi.uio.no Wed Oct 9 06:09:21 2013 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 01C1111E818A for ; Wed, 9 Oct 2013 06:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1hJhRAw3PTl for ; Wed, 9 Oct 2013 06:09:15 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 10FBC11E80F6 for ; Wed, 9 Oct 2013 06:09:14 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VTtVn-00087T-PX; Wed, 09 Oct 2013 15:09:11 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VTtVn-0004qE-DU; Wed, 09 Oct 2013 15:09:11 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: <525554B3.7040601@mti-systems.com> Date: Wed, 9 Oct 2013 15:09:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <525554B3.7040601@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 18 sum msgs/h 7 total rcpts 8314 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 30060C36B285C422FA6611C58F568DDAEB2B33A1 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 3260 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Luca De Cicco , Varun Singh Subject: Re: [rmcat] fairness/unfairness metrics X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 13:09:21 -0000 On 9. okt. 2013, at 15:05, Wesley Eddy wrote: > On 10/9/2013 4:02 AM, Michael Welzl wrote: >> Hi, >>=20 >> IMO, a good reason to use only DropTail and RED would be that RED is, >> so far, the only IETF-recommended mechanism, and it'd be better for >> rmcat evaluations to not be based on a moving target... >>=20 >=20 >=20 > I'm not aware of an IETF recommendation for RED. >=20 > 2309 was by the E2ERG, not an IETF consensus document, as I = understand. Sorry: IETF-described! I know it's an important difference, really just = mistyped, apologies. > Given that, and the sensitivity to parameterizing RED, I would > personally be fine with tail-drop queues only, though I understand > the motivation here to be able to show performance in cooperation > with an AQM. IMHO, that can be left as future work. +1, I actually agree on that. Cheers, Michael From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Oct 10 06:24:02 2013 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 AB48121F9B25 for ; Thu, 10 Oct 2013 06:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK-f3J+iQVD4 for ; Thu, 10 Oct 2013 06:23:57 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id B47EA21E8118 for ; Thu, 10 Oct 2013 06:23:50 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 6733B60155 for ; Thu, 10 Oct 2013 15:23:43 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 57D6D60154 for ; Thu, 10 Oct 2013 15:23:43 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat@ietf.org Date: Thu, 10 Oct 2013 15:23:42 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 13:24:02 -0000 Hi group, I have a question as an individual contributor. Looking at the current proposals which are all rate-based (right?), I was wondering if we maybe need a higher layer interface to announce the current rate to the application? Moreover, if the sending rate is application limited, don't we need a way to tell the application that there is more space on the link and e.g. the quality could be increased? Therefore we would need to know how much more capacity would be available. Normally congestion control does this by probing/slowly increasing the sending rate, but if the traffic is application limited that's not possible. Thus we maybe need some kind of measurement/testing method, that maintains an average rate as provided by the application, but can send for very short intervals with a higher and respective lower rate, like chirping (see PathChirp or TCP Rapid). Any opinions on this? Mirja From p.ohanlon@gmail.com Thu Oct 10 07:29:18 2013 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 7A10111E8178 for ; Thu, 10 Oct 2013 07:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsspX3JaXPYz for ; Thu, 10 Oct 2013 07:29:15 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3F21F9B28 for ; Thu, 10 Oct 2013 07:29:02 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id f12so2553603wgh.2 for ; Thu, 10 Oct 2013 07:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z4Vkzh8po9Mu14eUN3muh8/KZAQEBsd10NSGFZIvsVU=; b=KCGBMgIN+AWvvsy+llCI08qsG5Q7iX+qXRHElJreHqPNQIhGCiXQWmU8BG0A5+ujWL Nf14AhzQMHVBexwEhqzE/gp5xAem0WO8YhJI21GyTxJ+Rq5+63iFPTk4SPgvFOr2Mddn uWzIAeooZW3cpGHeW0zBMaX2WQk3SLwknwH/LyepbQFRZrlpZTgm7WIk0QMCUzMT02E0 z3M4irNGoONg5gva1Y2rvKlEzcEYyE94jdfM6z6ZbPYU2MovE6B7TU1F3wqwUn8iwiL2 jdisdxBp8cWrgJzXpmiHnEuyZZfDvQWmWFungxOF+ng5px0+MLbWLeJSo/JpTXm6E+Pr 0tGQ== X-Received: by 10.180.9.69 with SMTP id x5mr8035669wia.41.1381415341018; Thu, 10 Oct 2013 07:29:01 -0700 (PDT) Received: from black.lan ([149.241.129.101]) by mx.google.com with ESMTPSA id e5sm25930529wiy.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Oct 2013 07:28:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Piers O'Hanlon In-Reply-To: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Thu, 10 Oct 2013 15:28:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> To: =?iso-8859-1?Q?Mirja_K=FChlewind?= X-Mailer: Apple Mail (2.1283) Cc: rmcat WG Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 14:29:18 -0000 Hi Mirja, You bring up two points: - I'd agree we do need to have some sort of communication between the = congestion control and media/codec delivery - probably some API is = needed to communicate current parameters such as operating rate, = latency, and possibly some time limited projections (or confidence) of = such parameters. - The issue in your second point as I see is the issue of how deal with = application limited and/or silence periods - which are a tricky area. I = guess the corresponding concept for TCP is Congestion Window Validation, = and the changes in TFRC from RFC3448 to RFC5348 were largely down to = such data-limited behaviours. For general info Gorry Fairhurst has a = couple of recent papers on the subject: "TCP-Friendly Rate Control (TFRC) for bursty media flows", ComCom, 2011 And for TCP: "Enhancing TCP to Support Rate-Limited Traffic", CSWS, 2012 But you are suggesting a further addition to this - maybe when CWV = limits are exceed - by adding a probe phase. Although I think it's = possible to monitor the 'available' bandwidth on the link - the problem = maybe that other other flows will rapidly take up their 'fair share' of = the that available capacity. So probably the only way to maintain one's = capacity is send some sort of dummy traffic - or if we're WebRTC mode - = send some HTML/JS/CSS etc in between the lulls of media. I guess this mix could be handled via some coupled congestion service or = suitable multi-substream low latency transport with optional reliability = per substream... Cheers, Piers On 10 Oct 2013, at 14:23, Mirja K=FChlewind wrote: > Hi group, >=20 > I have a question as an individual contributor. Looking at the current=20= > proposals which are all rate-based (right?), I was wondering if we = maybe need=20 > a higher layer interface to announce the current rate to the = application? >=20 > Moreover, if the sending rate is application limited, don't we need a = way to=20 > tell the application that there is more space on the link and e.g. the=20= > quality could be increased? Therefore we would need to know how much = more=20 > capacity would be available. Normally congestion control does this by=20= > probing/slowly increasing the sending rate, but if the traffic is = application=20 > limited that's not possible. Thus we maybe need some kind of=20 > measurement/testing method, that maintains an average rate as provided = by the=20 > application, but can send for very short intervals with a higher and=20= > respective lower rate, like chirping (see PathChirp or TCP Rapid). >=20 > Any opinions on this? >=20 > Mirja >=20 >=20 From kevin.gross@avanw.com Thu Oct 10 08:05:56 2013 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 53D2121E8118 for ; Thu, 10 Oct 2013 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.352 X-Spam-Level: **** X-Spam-Status: No, score=4.352 tagged_above=-999 required=5 tests=[AWL=4.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rojfge4tujwe for ; Thu, 10 Oct 2013 08:05:48 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 86B5D21E8133 for ; Thu, 10 Oct 2013 08:05:23 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id bP3X1m00217dt5G5AT5LEV; Thu, 10 Oct 2013 15:05:20 +0000 Received: from mail-wg0-x22e.google.com ([IPv6:2a00:1450:400c:c00::22e]) by omta13.westchester.pa.mail.comcast.net with comcast id bT5K1m00T5S3McJ3ZT5LDo; Thu, 10 Oct 2013 15:05:20 +0000 Received: by mail-wg0-f46.google.com with SMTP id k14so2623616wgh.13 for ; Thu, 10 Oct 2013 08:05:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L3q+YowZlSlQilUvBJ+DCsbghFIMZgI54rQejPmUN8s=; b=GJ3TDxU98buKbs7IL5i30niny4PoyqIIKFZTYZzQ2V1bsv/xC2T/pK+JnFXLMbUC14 pzA7aUumkwLYVkvgfprvm5rqvYOiFR9DfoRDkt+6kxch64woNnchACHFzlBfhDM9yr76 KXCszvaRR4ue0uHqOAARbw0SGNVmFcqOc6gKNKJSgI1ultoP9dVGKPpTxWqzF70HtOlI w+dce0T+Xdh4WQ1Twuhy7WVLeSs741jS1xCMtmX9kv+PIdwMDhVVeV7/NH2Myu2bGK2I /ys10PsCbwIwANRtfRC/i87xVg6KrpdGvQQY/YqKnlT7R22F7AgpGJ5VK4uyNFiHtOD9 SfpA== MIME-Version: 1.0 X-Received: by 10.194.123.227 with SMTP id md3mr12569550wjb.17.1381417519249; Thu, 10 Oct 2013 08:05:19 -0700 (PDT) Received: by 10.216.202.7 with HTTP; Thu, 10 Oct 2013 08:05:19 -0700 (PDT) In-Reply-To: <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> Date: Thu, 10 Oct 2013 09:05:19 -0600 Message-ID: From: Kevin Gross To: "Piers O'Hanlon" Content-Type: multipart/alternative; boundary=089e01229a5885841404e8645490 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381417520; bh=L3q+YowZlSlQilUvBJ+DCsbghFIMZgI54rQejPmUN8s=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=et613qbbim7nLVmCcQTS6QyDc6EKRnKsSq8Ewl7pbqduBSLmf+nQ7diz2/o3Hwurh UnCQy7XntgtU52k5Duy5+T7PyMNOa+Gj2fiGuusiuZr7zuPaHsCXUGEPUDoLl4aAf2 Gb5LLRy1Co08P56bA9uX+gTKC738zTt9NFmFI4bHzet3bqX5ViWOpAu1M5hZayuiv8 2nOusTMnI7So+lUTf0C9Vi2xoFVvhFd32YD1XGuaxwB2/SiDH2nMn/T0EiOWECOHSC 2IDURZUvI7Z8PoUDpUPLIJLiqogPfy0g03SlhEnLCjl/1OkchTmoMqQ4bhx2eBHElt mgPj401qZt7qQ== Cc: rmcat WG , =?ISO-8859-1?Q?Mirja_K=FChlewind?= Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 15:05:56 -0000 --089e01229a5885841404e8645490 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought the scope of the work for this group was to develop techniques applications can use to avoid congestion. Since this is all being done internal to the application, there's no need for an API to an application. We may need to have interfaces to the network for ECN or whatnot. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com On Thu, Oct 10, 2013 at 8:28 AM, Piers O'Hanlon wrote= : > Hi Mirja, > > You bring up two points: > > - I'd agree we do need to have some sort of communication between the > congestion control and media/codec delivery - probably some API is needed > to communicate current parameters such as operating rate, latency, and > possibly some time limited projections (or confidence) of such parameters= . > > - The issue in your second point as I see is the issue of how deal with > application limited and/or silence periods - which are a tricky area. I > guess the corresponding concept for TCP is Congestion Window Validation, > and the changes in TFRC from RFC3448 to RFC5348 were largely down to suc= h > data-limited behaviours. For general info Gorry Fairhurst has a couple of > recent papers on the subject: > "TCP-Friendly Rate Control (TFRC) for bursty media flows", ComCom, 2011 > And for TCP: > "Enhancing TCP to Support Rate-Limited Traffic", CSWS, 2012 > > But you are suggesting a further addition to this - maybe when CWV limits > are exceed - by adding a probe phase. Although I think it's possible to > monitor the 'available' bandwidth on the link - the problem maybe that > other other flows will rapidly take up their 'fair share' of the that > available capacity. So probably the only way to maintain one's capacity i= s > send some sort of dummy traffic - or if we're WebRTC mode - send some > HTML/JS/CSS etc in between the lulls of media. > > I guess this mix could be handled via some coupled congestion service or > suitable multi-substream low latency transport with optional reliability > per substream... > > Cheers, > > Piers > > > On 10 Oct 2013, at 14:23, Mirja K=FChlewind wrote: > > > Hi group, > > > > I have a question as an individual contributor. Looking at the current > > proposals which are all rate-based (right?), I was wondering if we mayb= e > need > > a higher layer interface to announce the current rate to the applicatio= n? > > > > Moreover, if the sending rate is application limited, don't we need a > way to > > tell the application that there is more space on the link and e.g. the > > quality could be increased? Therefore we would need to know how much mo= re > > capacity would be available. Normally congestion control does this by > > probing/slowly increasing the sending rate, but if the traffic is > application > > limited that's not possible. Thus we maybe need some kind of > > measurement/testing method, that maintains an average rate as provided > by the > > application, but can send for very short intervals with a higher and > > respective lower rate, like chirping (see PathChirp or TCP Rapid). > > > > Any opinions on this? > > > > Mirja > > > > > > --089e01229a5885841404e8645490 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I thought the scope of the work for this group was to deve= lop techniques applications can use to avoid congestion. Since this is all = being done internal to the application, there's no need for an API to a= n application. We may need to have interfaces to the network for ECN or wha= tnot.

Kevin Gr= oss
+1-303-447-0517
Media Network Consultant
AVA = Networks -=A0www.AVAnw.= com


On Thu, Oct 10, 2013 at 8:28 AM, Piers O= 'Hanlon <p.ohanlon@gmail.com> wrote:
Hi Mirja,

You bring up two points:

- I'd agree we do need to have some sort of communication between the c= ongestion control and media/codec delivery - probably some API is needed to= communicate current parameters such as operating rate, latency, and possib= ly some time limited projections (or confidence) of such parameters.

- The issue in your second point as I see is the issue of how deal with app= lication limited and/or silence periods - which are a tricky area. I guess = the corresponding concept for TCP is Congestion Window Validation, and the = changes in TFRC from RFC3448 to =A0RFC5348 were largely down to such data-l= imited behaviours. For general info Gorry Fairhurst has a couple of recent = papers on the subject:
"TCP-Friendly Rate Control (TFRC) for bursty media flows", ComCom= , 2011
And for TCP:
"Enhancing TCP to Support Rate-Limited Traffic", CSWS, 2012

But you are suggesting a further addition to this - maybe when CWV limits a= re exceed - by adding a probe phase. Although I think it's possible to = monitor the 'available' bandwidth on the link - the problem maybe t= hat other other flows will rapidly take up their 'fair share' of th= e that available capacity. So probably the only way to maintain one's c= apacity is send some sort of dummy traffic - or if we're WebRTC mode - = send some HTML/JS/CSS etc in between the lulls of media.

I guess this mix could be handled via some coupled congestion service or su= itable multi-substream low latency transport with optional reliability per = substream...

Cheers,

Piers


On 10 Oct 2013, at 14:23, Mirja K=FChlewind wrote:

> Hi group,
>
> I have a question as an individual contributor. Looking at the current=
> proposals which are all rate-based (right?), I was wondering if we may= be need
> a higher layer interface to announce the current rate to the applicati= on?
>
> Moreover, if the sending rate is application limited, don't we nee= d a way to
> tell the application that there is more space on the link and e.g. the=
> quality could be increased? Therefore we would need to know how much m= ore
> capacity would be available. Normally congestion control does this by<= br> > probing/slowly increasing the sending rate, but if the traffic is appl= ication
> limited that's not possible. Thus we maybe need some kind of
> measurement/testing method, that maintains an average rate as provided= by the
> application, but can send for very short intervals with a higher and > respective lower rate, like chirping (see PathChirp or TCP Rapid).
>
> Any opinions on this?
>
> Mirja
>
>


--089e01229a5885841404e8645490-- From mramalho@cisco.com Thu Oct 10 12:43:32 2013 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 9E2F821F9FB7 for ; Thu, 10 Oct 2013 12:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI4t-TQqt2QH for ; Thu, 10 Oct 2013 12:42:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6E78621F9BFA for ; Thu, 10 Oct 2013 12:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2725; q=dns/txt; s=iport; t=1381434157; x=1382643757; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dOqLhLb2z2PzBRlCPM20Hf0u5QdkwyhC2fdFD8Eh7WE=; b=FRgFhfO+5npLhp1HXVAR0ej9BNWPYNywBaSAEB8eOJqzqROyc7qAzgqM q9OSiFf7rYXOPwyPQcSA9SIvzCr/0wotaCn3Isw5AIxWdHEP+RmSIQYM6 HWI/zsOO4PgWxIICSTly3aOQ22W6tnPikUZd3AcJtBJIredeW3mgdDoxR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOgBV1KtJV2d/2dsb2JhbABZgweBCsEvgSUWdIIlAQEBBIEFBAIBCBEEAQELHQcyFAkIAgQBEgiHfrpDjgiBDjgGgxmBBAOJBKEDgySBaEI X-IronPort-AV: E=Sophos;i="4.90,1074,1371081600"; d="scan'208";a="270687092" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 10 Oct 2013 19:42:35 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9AJgZ9S001119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 19:42:35 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.19]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 14:42:35 -0500 From: "Michael Ramalho (mramalho)" To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , "rmcat@ietf.org" Thread-Topic: [rmcat] application interface Thread-Index: AQHOxbv+M5s7nccLykC4LvLJrsMxOZnuMH9Q Date: Thu, 10 Oct 2013 19:42:34 +0000 Message-ID: References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.20.113] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 19:43:32 -0000 Mirja, Comments below with "MAR:". Michael -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of M= irja K=FChlewind Sent: Thursday, October 10, 2013 8:24 AM To: rmcat@ietf.org Subject: [rmcat] application interface Hi group, I have a question as an individual contributor. Looking at the current prop= osals which are all rate-based (right?), I was wondering if we maybe need a= higher layer interface to announce the current rate to the application? MAR: Although I agree that most of the discussion on the list has assumed "= rate" as an application controlling variable, I have posted early on that I= believe that we should not rule out other mechanisms at this point.=20 MAR: I would like to keep in scope any mechanism (i.e., passing of any nece= ssary congestion control parameter) that the RMCAT participants may find as= necessary to attain our goals of bandwidth sharing with a constraint of mi= nimizing delay (when possible). MAR: So, from my perspective (as an independent contributor, I am not speak= ing for any group/team) I believe that some interface (API or whatever) wil= l be required to tell the application about the known/observed congestion s= tate and behaviors of the application (e.g., you can speed up at a given ra= te until informed otherwise ... or please stop sending video frames for the= next X milliseconds ... or ?). Moreover, if the sending rate is application limited, don't we need a way t= o tell the application that there is more space on the link and e.g. the qu= ality could be increased? Therefore we would need to know how much more cap= acity would be available. MAR: One could opportunistically send probes (when traffic is known or beli= eved to be light) to estimate what the maximum rate could be. As you say, k= nowledge that a given applications traffic is causing congestion is only kn= own AFTER such congestion can be measured. Thus you don't know how high you= r ceiling is until you bump your head against it. Normally congestion control does this by probing/slowly increasing the send= ing rate, but if the traffic is application limited that's not possible. Th= us we maybe need some kind of measurement/testing method, that maintains an= average rate as provided by the application, but can send for very short i= ntervals with a higher and respective lower rate, like chirping (see PathCh= irp or TCP Rapid). MAR: Agree on that point. I would classify it as "opportunistic probing" as= I mentioned above. If the application would like to know if more bandwidth= is available, then such probing can occur. Any opinions on this? Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 11 04:52:45 2013 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 6686D21F9C4D for ; Fri, 11 Oct 2013 04:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZyO+8sf76rj for ; Fri, 11 Oct 2013 04:52:41 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6488921F9BB5 for ; Fri, 11 Oct 2013 04:52:36 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id ADEF2602DB; Fri, 11 Oct 2013 13:52:34 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id A952D602D8; Fri, 11 Oct 2013 13:52:34 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Fri, 11 Oct 2013 13:52:34 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> In-Reply-To: <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310111352.34562.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Piers O'Hanlon Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 11:52:45 -0000 Hi Piers, inline... > - I'd agree we do need to have some sort of communication between the > congestion control and media/codec delivery - probably some API is needed > to communicate current parameters such as operating rate, latency, and > possibly some time limited projections (or confidence) of such parameters. I would be careful to make the interface too large and too complicated. The= =20 question is which information is really needed for the application to decid= e=20 to switch the coding and also (maybe even more important) which information= =20 can be understood by every application designer. I currently believe that t= he=20 information, what the estimated largest possible rate is, might be enough. > > - The issue in your second point as I see is the issue of how deal with > application limited and/or silence periods - which are a tricky area. I > guess the corresponding concept for TCP is Congestion Window Validation, > and the changes in TFRC from RFC3448 to RFC5348 were largely down to such > data-limited behaviours. For general info Gorry Fairhurst has a couple of > recent papers on the subject: "TCP-Friendly Rate Control (TFRC) for bursty > media flows", ComCom, 2011 And for TCP: > "Enhancing TCP to Support Rate-Limited Traffic", CSWS, 2012 These mechanisms do not address the same problem. They mainly handle the ca= se=20 when you've already been sending at a larger rate but now you have a smalle= r=20 rate or stopped sending for a little while. In my case you would like to=20 indicate also that the application could switch to a higher rate. That mean= s=20 the link is currently not full and you would like to know how much space is= =20 available. Of course other might also try to use some of the space but that= =20 means simply you probably want to increase your rate step-wise (on the high= er=20 layer) and not try to grab all at once. The other problem is, when the coding is changed, the rate will increase=20 step-wise while the proposed congestion control schemes ramp up slowly. Whe= n=20 you already did some probing before, it might be (more or less) safe to als= o=20 increase by a step (if not too large) at congestion control level. > > But you are suggesting a further addition to this - maybe when CWV limits > are exceed - by adding a probe phase. Although I think it's possible to > monitor the 'available' bandwidth on the link - the problem maybe that > other other flows will rapidly take up their 'fair share' of the that > available capacity. So probably the only way to maintain one's capacity is > send some sort of dummy traffic - or if we're WebRTC mode - send some > HTML/JS/CSS etc in between the lulls of media. Yes and no. I partly addressed this already above basically saying don't gr= ab=20 the whole available capacity at once but increase the application rate=20 step-wise. But in fact you bring up one more problem. Let's assume the link= =20 is already full. How do I know that it still would be possible to increase = my=20 sending rate because other (potentially less important traffic) might adapt= =20 and free some capacity for me (without increasing the total congestion=20 level)? > > I guess this mix could be handled via some coupled congestion service or > suitable multi-substream low latency transport with optional reliability > per substream... You mean, sending dummy data? Not sure if that's the right solution. For su= re=20 it's a solution which probably works but I would favor any other solution i= f=20 we could find one. Mirja > > Cheers, > > Piers > > On 10 Oct 2013, at 14:23, Mirja K=FChlewind wrote: > > Hi group, > > > > I have a question as an individual contributor. Looking at the current > > proposals which are all rate-based (right?), I was wondering if we maybe > > need a higher layer interface to announce the current rate to the > > application? > > > > Moreover, if the sending rate is application limited, don't we need a w= ay > > to tell the application that there is more space on the link and e.g. t= he > > quality could be increased? Therefore we would need to know how much mo= re > > capacity would be available. Normally congestion control does this by > > probing/slowly increasing the sending rate, but if the traffic is > > application limited that's not possible. Thus we maybe need some kind of > > measurement/testing method, that maintains an average rate as provided = by > > the application, but can send for very short intervals with a higher and > > respective lower rate, like chirping (see PathChirp or TCP Rapid). > > > > Any opinions on this? > > > > Mirja =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 11 04:55:55 2013 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 3EFD221E80E4 for ; Fri, 11 Oct 2013 04:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Htg5UAcOCIub for ; Fri, 11 Oct 2013 04:55:35 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 131C321E80DF for ; Fri, 11 Oct 2013 04:55:33 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 7209D602DC; Fri, 11 Oct 2013 13:55:32 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 6281C602DB; Fri, 11 Oct 2013 13:55:32 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Kevin Gross Date: Fri, 11 Oct 2013 13:55:32 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310111355.32264.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: rmcat WG , Piers O'Hanlon Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 11:55:56 -0000 Hi Kevin, sure the congestion control could also be implemented in the application. I= =20 was assuming that the congestion control is part if the transport layer. Bu= t=20 even if you implement it in the application, you potentially would like to= =20 define some kind of interface such that the same congestion control could=20 more easily be implemented (or even code could be re-used) by different=20 applications and the application could then implement an addition control=20 loop on top to change the coding. This additional higher layer control loop= =20 is not part of the rmcat charter thus having a well defined interface would= =20 be useful form my point of view. Mirja On Thursday 10 October 2013 17:05:19 Kevin Gross wrote: > I thought the scope of the work for this group was to develop techniques > applications can use to avoid congestion. Since this is all being done > internal to the application, there's no need for an API to an application. > We may need to have interfaces to the network for ECN or whatnot. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com > > On Thu, Oct 10, 2013 at 8:28 AM, Piers O'Hanlon wro= te: > > Hi Mirja, > > > > You bring up two points: > > > > - I'd agree we do need to have some sort of communication between the > > congestion control and media/codec delivery - probably some API is need= ed > > to communicate current parameters such as operating rate, latency, and > > possibly some time limited projections (or confidence) of such > > parameters. > > > > - The issue in your second point as I see is the issue of how deal with > > application limited and/or silence periods - which are a tricky area. I > > guess the corresponding concept for TCP is Congestion Window Validation, > > and the changes in TFRC from RFC3448 to RFC5348 were largely down to > > such data-limited behaviours. For general info Gorry Fairhurst has a > > couple of recent papers on the subject: > > "TCP-Friendly Rate Control (TFRC) for bursty media flows", ComCom, 2011 > > And for TCP: > > "Enhancing TCP to Support Rate-Limited Traffic", CSWS, 2012 > > > > But you are suggesting a further addition to this - maybe when CWV limi= ts > > are exceed - by adding a probe phase. Although I think it's possible to > > monitor the 'available' bandwidth on the link - the problem maybe that > > other other flows will rapidly take up their 'fair share' of the that > > available capacity. So probably the only way to maintain one's capacity > > is send some sort of dummy traffic - or if we're WebRTC mode - send some > > HTML/JS/CSS etc in between the lulls of media. > > > > I guess this mix could be handled via some coupled congestion service or > > suitable multi-substream low latency transport with optional reliability > > per substream... > > > > Cheers, > > > > Piers > > > > On 10 Oct 2013, at 14:23, Mirja K=FChlewind wrote: > > > Hi group, > > > > > > I have a question as an individual contributor. Looking at the current > > > proposals which are all rate-based (right?), I was wondering if we > > > maybe > > > > need > > > > > a higher layer interface to announce the current rate to the > > > application? > > > > > > Moreover, if the sending rate is application limited, don't we need a > > > > way to > > > > > tell the application that there is more space on the link and e.g. the > > > quality could be increased? Therefore we would need to know how much > > > more capacity would be available. Normally congestion control does th= is > > > by probing/slowly increasing the sending rate, but if the traffic is > > > > application > > > > > limited that's not possible. Thus we maybe need some kind of > > > measurement/testing method, that maintains an average rate as provided > > > > by the > > > > > application, but can send for very short intervals with a higher and > > > respective lower rate, like chirping (see PathChirp or TCP Rapid). > > > > > > Any opinions on this? > > > > > > Mirja =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From gorius@nt.uni-saarland.de Fri Oct 11 05:10:28 2013 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 2E7CB21E8063 for ; Fri, 11 Oct 2013 05:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGPMcRvlvzJx for ; Fri, 11 Oct 2013 05:10:23 -0700 (PDT) Received: from triton.rz.uni-saarland.de (triton.rz.uni-saarland.de [134.96.7.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3085A21F9AA2 for ; Fri, 11 Oct 2013 05:10:22 -0700 (PDT) Received: from dhcp86-91.nt.uni-saarland.de (dhcp86-91.nt.uni-saarland.de [134.96.86.91]) (authenticated bits=0) by triton.rz.uni-saarland.de (8.14.1/8.14.0) with ESMTP id r9BCAIue000579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Oct 2013 14:10:18 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_82ACE9B6-63BC-4829-BDC6-640C88C0AA99" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Manuel Gorius In-Reply-To: <201310111352.34562.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Fri, 11 Oct 2013 14:10:19 +0200 Message-Id: <0A762FF3-7824-44D0-BE2E-1C3DA2C0615D@nt.uni-saarland.de> References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> <201310111352.34562.mirja.kuehlewind@ikr.uni-stuttgart.de> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (triton.rz.uni-saarland.de [134.96.7.25]); Fri, 11 Oct 2013 14:10:18 +0200 (CEST) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-14; AVE: 7.9.10.68; VDF: 7.11.99.164; host: AntiVir3) Cc: rmcat@ietf.org, Piers O'Hanlon Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 12:10:28 -0000 --Apple-Mail=_82ACE9B6-63BC-4829-BDC6-640C88C0AA99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Mirja, Hi Piers, We are dealing with similar problems in the context of real-time dynamic = media streaming. We decided (as we just designed a kind of real-time and = media-friendly transport protocol for research purposes) to communicate = the transport protocol's current goodput estimate (after deducting error = control and header overhead from the throughput) to the application as a = part of some socket state information that might be polled by the = application. Measurements of the end-to-end communication delay and the = packet loss rate are available as well. In the context of dynamic media streaming we also observe the problem of = biased congestion feedback as a result of the multimedia flow's rigid = rate requirement. As you mention, it makes rate-adaptive flows weak in = the competition for available bandwidth. I'm just wondering whether it = wouldn't be more beneficial to fill the gap between the congestion = control's rate estimate and the application's actual rate requirement = with error control data instead of dummy traffic. This information could = even protect the real-time flows against congestion losses during the = (probably) upcoming congestion event caused by the probing activities = (e. g. chirping). Best, Manuel Gorius Telecommunications Lab Saarland University Campus C6 3, 9.06 66123 Saarbruecken Germany T +49 681 302 6544 F +49 681 302 6542 gorius@nt.uni-saarland.de www.nt.uni-saarland.de/people/gorius On 11.10.2013, at 13:52, Mirja Kuehlewind = wrote: > Hi Piers, >=20 > inline... >=20 >=20 >> - I'd agree we do need to have some sort of communication between the >> congestion control and media/codec delivery - probably some API is = needed >> to communicate current parameters such as operating rate, latency, = and >> possibly some time limited projections (or confidence) of such = parameters. > I would be careful to make the interface too large and too = complicated. The=20 > question is which information is really needed for the application to = decide=20 > to switch the coding and also (maybe even more important) which = information=20 > can be understood by every application designer. I currently believe = that the=20 > information, what the estimated largest possible rate is, might be = enough. >=20 >>=20 >> - The issue in your second point as I see is the issue of how deal = with >> application limited and/or silence periods - which are a tricky area. = I >> guess the corresponding concept for TCP is Congestion Window = Validation, >> and the changes in TFRC from RFC3448 to RFC5348 were largely down to = such >> data-limited behaviours. For general info Gorry Fairhurst has a = couple of >> recent papers on the subject: "TCP-Friendly Rate Control (TFRC) for = bursty >> media flows", ComCom, 2011 And for TCP: >> "Enhancing TCP to Support Rate-Limited Traffic", CSWS, 2012 > These mechanisms do not address the same problem. They mainly handle = the case=20 > when you've already been sending at a larger rate but now you have a = smaller=20 > rate or stopped sending for a little while. In my case you would like = to=20 > indicate also that the application could switch to a higher rate. That = means=20 > the link is currently not full and you would like to know how much = space is=20 > available. Of course other might also try to use some of the space but = that=20 > means simply you probably want to increase your rate step-wise (on the = higher=20 > layer) and not try to grab all at once. > The other problem is, when the coding is changed, the rate will = increase=20 > step-wise while the proposed congestion control schemes ramp up = slowly. When=20 > you already did some probing before, it might be (more or less) safe = to also=20 > increase by a step (if not too large) at congestion control level. >=20 >>=20 >> But you are suggesting a further addition to this - maybe when CWV = limits >> are exceed - by adding a probe phase. Although I think it's possible = to >> monitor the 'available' bandwidth on the link - the problem maybe = that >> other other flows will rapidly take up their 'fair share' of the that >> available capacity. So probably the only way to maintain one's = capacity is >> send some sort of dummy traffic - or if we're WebRTC mode - send some >> HTML/JS/CSS etc in between the lulls of media. > Yes and no. I partly addressed this already above basically saying = don't grab=20 > the whole available capacity at once but increase the application rate=20= > step-wise. But in fact you bring up one more problem. Let's assume the = link=20 > is already full. How do I know that it still would be possible to = increase my=20 > sending rate because other (potentially less important traffic) might = adapt=20 > and free some capacity for me (without increasing the total congestion=20= > level)? >=20 >>=20 >> I guess this mix could be handled via some coupled congestion service = or >> suitable multi-substream low latency transport with optional = reliability >> per substream... > You mean, sending dummy data? Not sure if that's the right solution. = For sure=20 > it's a solution which probably works but I would favor any other = solution if=20 > we could find one. >=20 > Mirja >=20 >>=20 >> Cheers, >>=20 >> Piers >>=20 >> On 10 Oct 2013, at 14:23, Mirja K=FChlewind wrote: >>> Hi group, >>>=20 >>> I have a question as an individual contributor. Looking at the = current >>> proposals which are all rate-based (right?), I was wondering if we = maybe >>> need a higher layer interface to announce the current rate to the >>> application? >>>=20 >>> Moreover, if the sending rate is application limited, don't we need = a way >>> to tell the application that there is more space on the link and = e.g. the >>> quality could be increased? Therefore we would need to know how much = more >>> capacity would be available. Normally congestion control does this = by >>> probing/slowly increasing the sending rate, but if the traffic is >>> application limited that's not possible. Thus we maybe need some = kind of >>> measurement/testing method, that maintains an average rate as = provided by >>> the application, but can send for very short intervals with a higher = and >>> respective lower rate, like chirping (see PathChirp or TCP Rapid). >>>=20 >>> Any opinions on this? >>>=20 >>> Mirja >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- --Apple-Mail=_82ACE9B6-63BC-4829-BDC6-640C88C0AA99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 +49 681 302 6544

=
On 11.10.2013, at 13:52, Mirja Kuehlewind <mirja.kuehlewind@ikr= .uni-stuttgart.de> wrote:

Hi = Piers,

inline...


- I'd agree = we do need to have some sort of communication between the
congestion = control and media/codec delivery - probably some API is needed
to = communicate current parameters such as operating rate, latency, = and
possibly some time limited projections (or confidence) of such = parameters.
I would be careful to make the interface too = large and too complicated. The
question is which information is = really needed for the application to decide
to switch the coding and = also (maybe even more important) which information
can be understood = by every application designer. I currently believe that the =
information, what the estimated largest possible rate is, might be = enough.


- The issue in your second = point as I see is the issue of how deal with
application limited = and/or silence periods - which are a tricky area. I
guess the = corresponding concept for TCP is Congestion Window Validation,
and = the changes in TFRC from RFC3448 to  RFC5348 were largely down to = such
data-limited behaviours. For general info Gorry Fairhurst has a = couple of
recent papers on the subject: "TCP-Friendly Rate Control = (TFRC) for bursty
media flows", ComCom, 2011 And for = TCP:
"Enhancing TCP to Support Rate-Limited Traffic", CSWS, = 2012
These mechanisms do not address the same problem. = They mainly handle the case
when you've already been sending at a = larger rate but now you have a smaller
rate or stopped sending for a = little while. In my case you would like to
indicate also that the = application could switch to a higher rate. That means
the link is = currently not full and you would like to know how much space is =
available. Of course other might also try to use some of the space = but that
means simply you probably want to increase your rate = step-wise (on the higher
layer) and not try to grab all at = once.
The other problem is, when the coding is changed, the rate will = increase
step-wise while the proposed congestion control schemes = ramp up slowly. When
you already did some probing before, it might = be (more or less) safe to also
increase by a step (if not too large) = at congestion control level.


But = you are suggesting a further addition to this - maybe when CWV = limits
are exceed - by adding a probe phase. Although I think it's = possible to
monitor the 'available' bandwidth on the link - the = problem maybe that
other other flows will rapidly take up their 'fair = share' of the that
available capacity. So probably the only way to = maintain one's capacity is
send some sort of dummy traffic - or if = we're WebRTC mode - send some
HTML/JS/CSS etc in between the lulls of = media.
Yes and no. I partly addressed this already above = basically saying don't grab
the whole available capacity at once but = increase the application rate
step-wise. But in fact you bring up = one more problem. Let's assume the link
is already full. How do I = know that it still would be possible to increase my
sending rate = because other (potentially less important traffic) might adapt
and = free some capacity for me (without increasing the total congestion =
level)?


I guess this mix could = be handled via some coupled congestion service or
suitable = multi-substream low latency transport with optional reliability
per = substream...
You mean, sending dummy data? Not sure if = that's the right solution. For sure
it's a solution which probably = works but I would favor any other solution if
we could find = one.

Mirja


Cheers,

Piers

On 10 Oct 2013, at 14:23, = Mirja K=FChlewind wrote:
Hi group,

I = have a question as an individual contributor. Looking at the = current
proposals which are all rate-based (right?), I was wondering = if we maybe
need a higher layer interface to announce the current = rate to the
application?

Moreover, if the sending rate is = application limited, don't we need a way
to tell the application that = there is more space on the link and e.g. the
quality could be = increased? Therefore we would need to know how much more
capacity = would be available. Normally congestion control does this = by
probing/slowly increasing the sending rate, but if the traffic = is
application limited that's not possible. Thus we maybe need some = kind of
measurement/testing method, that maintains an average rate as = provided by
the application, but can send for very short intervals = with a higher and
respective lower rate, like chirping (see PathChirp = or TCP Rapid).

Any opinions on = this?

Mirja



-- =
-------------------------------------------------------------------Dipl.-Ing. Mirja K=FChlewind
Institute of Communication Networks and = Computer Engineering (IKR)
University of Stuttgart, = Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: = +49(0)711/685-67973
email: mirja.kuehlewind@ikr= .uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
-= ------------------------------------------------------------------

= --Apple-Mail=_82ACE9B6-63BC-4829-BDC6-640C88C0AA99-- From michawe@ifi.uio.no Fri Oct 11 06:13:11 2013 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 DF85721F9D31 for ; Fri, 11 Oct 2013 06:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.757 X-Spam-Level: X-Spam-Status: No, score=-102.757 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcQt0DMiK-o5 for ; Fri, 11 Oct 2013 06:13:07 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id CFED921F9DA1 for ; Fri, 11 Oct 2013 06:13:06 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VUcWZ-0005DY-F3; Fri, 11 Oct 2013 15:12:59 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUcWY-0000EI-Gj; Fri, 11 Oct 2013 15:12:59 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_27C96504-391E-4072-804A-881BB536FC2B" From: Michael Welzl In-Reply-To: <201310111355.32264.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Fri, 11 Oct 2013 15:12:57 +0200 Message-Id: References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> <201310111355.32264.mirja.kuehlewind@ikr.uni-stuttgart.de> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 8425 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.502, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BCB9A2527D622C1399127C6261D25829847EF126 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -64 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3301 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Piers O'Hanlon , Kevin Gross Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 13:13:12 -0000 --Apple-Mail=_27C96504-391E-4072-804A-881BB536FC2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, I don't understand why you call it a control loop, it's just an API, and = I don't understand why you say it's not in the charter? The charter = says: "Identify interactions between applications and RTP flows to enable = conveying helpful cross-layer information such as per-packet priorities, flow = elasticity, etc. This information might be used to populate an API, but the WG will not = define a specific API itself." The intention behind this really was an API, conceptually - as far as I = can tell the (later added) "anti-API" wording is just there to ensure = that there won't be an API defined in the sense of defining datatypes = and such machine-specific things, but something more abstract. But it's = about defining how applications communicate with the transport layer. FWIW, the result on slide 16: http://www.ietf.org/proceedings/87/slides/slides-87-rmcat-2.pdf is only possible because we assume that coupled congestion control gets = not only the rate that the congestion controller has calculated, but = also the "desired rate" from the application (which may be smaller than = the congestion controller's rate). Now this is the other direction than what you mean - the transport = getting the rate from the application - but it does require at least = some rudimentary communication between applications and the transport. = About the rest of your musings, I agree, and I also agree with the = concerns that were raised about defining too much, we'd have to be = careful here. In your answer to Piers, you wrote: "I would be careful to make the interface too large and too complicated. = The=20 question is which information is really needed for the application to = decide=20 to switch the coding and also (maybe even more important) which = information=20 can be understood by every application designer. I currently believe = that the=20 information, what the estimated largest possible rate is, might be = enough." and I agree, probably you won't need more than this, *upward*, and what = we called the application's "desired rate", *downward*. As another comment to address Kevin's concern: this would be only about = things that are of definite concern to the application and can't be = dealt with below without involving the application. ECN is in fact a = nice example of a case that doesn't need the application, it could be = dealt with below - even for TCP, as Mirja et al's related draft shows: http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback Cheers, Michael On 11. okt. 2013, at 13:55, Mirja Kuehlewind wrote: > Hi Kevin, >=20 > sure the congestion control could also be implemented in the = application. I=20 > was assuming that the congestion control is part if the transport = layer. But=20 > even if you implement it in the application, you potentially would = like to=20 > define some kind of interface such that the same congestion control = could=20 > more easily be implemented (or even code could be re-used) by = different=20 > applications and the application could then implement an addition = control=20 > loop on top to change the coding. This additional higher layer control = loop=20 > is not part of the rmcat charter thus having a well defined interface = would=20 > be useful form my point of view. >=20 > Mirja >=20 >=20 >=20 > On Thursday 10 October 2013 17:05:19 Kevin Gross wrote: >> I thought the scope of the work for this group was to develop = techniques >> applications can use to avoid congestion. Since this is all being = done >> internal to the application, there's no need for an API to an = application. >> We may need to have interfaces to the network for ECN or whatnot. >>=20 >> Kevin Gross >> +1-303-447-0517 >> Media Network Consultant >> AVA Networks - www.AVAnw.com >>=20 >> On Thu, Oct 10, 2013 at 8:28 AM, Piers O'Hanlon = wrote: >>> Hi Mirja, >>>=20 >>> You bring up two points: >>>=20 >>> - I'd agree we do need to have some sort of communication between = the >>> congestion control and media/codec delivery - probably some API is = needed >>> to communicate current parameters such as operating rate, latency, = and >>> possibly some time limited projections (or confidence) of such >>> parameters. >>>=20 >>> - The issue in your second point as I see is the issue of how deal = with >>> application limited and/or silence periods - which are a tricky = area. I >>> guess the corresponding concept for TCP is Congestion Window = Validation, >>> and the changes in TFRC from RFC3448 to RFC5348 were largely down = to >>> such data-limited behaviours. For general info Gorry Fairhurst has a >>> couple of recent papers on the subject: >>> "TCP-Friendly Rate Control (TFRC) for bursty media flows", ComCom, = 2011 >>> And for TCP: >>> "Enhancing TCP to Support Rate-Limited Traffic", CSWS, 2012 >>>=20 >>> But you are suggesting a further addition to this - maybe when CWV = limits >>> are exceed - by adding a probe phase. Although I think it's possible = to >>> monitor the 'available' bandwidth on the link - the problem maybe = that >>> other other flows will rapidly take up their 'fair share' of the = that >>> available capacity. So probably the only way to maintain one's = capacity >>> is send some sort of dummy traffic - or if we're WebRTC mode - send = some >>> HTML/JS/CSS etc in between the lulls of media. >>>=20 >>> I guess this mix could be handled via some coupled congestion = service or >>> suitable multi-substream low latency transport with optional = reliability >>> per substream... >>>=20 >>> Cheers, >>>=20 >>> Piers >>>=20 >>> On 10 Oct 2013, at 14:23, Mirja K=FChlewind wrote: >>>> Hi group, >>>>=20 >>>> I have a question as an individual contributor. Looking at the = current >>>> proposals which are all rate-based (right?), I was wondering if we >>>> maybe >>>=20 >>> need >>>=20 >>>> a higher layer interface to announce the current rate to the >>>> application? >>>>=20 >>>> Moreover, if the sending rate is application limited, don't we need = a >>>=20 >>> way to >>>=20 >>>> tell the application that there is more space on the link and e.g. = the >>>> quality could be increased? Therefore we would need to know how = much >>>> more capacity would be available. Normally congestion control does = this >>>> by probing/slowly increasing the sending rate, but if the traffic = is >>>=20 >>> application >>>=20 >>>> limited that's not possible. Thus we maybe need some kind of >>>> measurement/testing method, that maintains an average rate as = provided >>>=20 >>> by the >>>=20 >>>> application, but can send for very short intervals with a higher = and >>>> respective lower rate, like chirping (see PathChirp or TCP Rapid). >>>>=20 >>>> Any opinions on this? >>>>=20 >>>> Mirja >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- --Apple-Mail=_27C96504-391E-4072-804A-881BB536FC2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 helpful cross-layer information such as per-packet = priorities, flow elasticity, etc.
This information might be used to = populate an API, but the WG will not define a
specific API = itself."

The intention behind this really was = an API, conceptually - as far as I can tell the (later added) "anti-API" = wording is just there to ensure that there won't be an API defined in = the sense of defining datatypes and such machine-specific things, but = something more abstract. But it's about defining how applications = communicate with the transport layer.

FWIW, the = result on slide 16:
is only possible because we assume that coupled congestion control = gets not only the rate that the congestion controller has calculated, = but also the "desired rate" from the application (which may be smaller = than the congestion controller's rate).

Now = this is the other direction than what you mean - the transport = getting the rate from the application - but it does require at least = some rudimentary communication between applications and the transport. = About the rest of your musings, I agree, and I also agree with the = concerns that were raised about defining too much, we'd have to be = careful here. In your answer to Piers, you = wrote:

"I would be careful to make the = interface too large and too complicated. The 
question is = which information is really needed for the application to = decide 
to switch the coding and also (maybe even more = important) which information 
can be understood by every = application designer. I currently believe that the 
information, = what the estimated largest possible rate is, might be = enough."

and I agree, probably you won't need more = than this, *upward*, and what we called the application's "desired = rate", *downward*.

As another comment to = address Kevin's concern: this would be only about things that are of = definite concern to the application and can't be dealt with below = without involving the application. ECN is in fact a nice example of a = case that doesn't need the application, it could be dealt with below - = even for TCP, as Mirja et al's related draft shows:
<= br>
Cheers,
Michael


=
On 11. okt. 2013, at 13:55, Mirja Kuehlewind wrote:

Hi = Kevin,

sure the congestion control could also be implemented in = the application. I
was assuming that the congestion control is part = if the transport layer. But
even if you implement it in the = application, you potentially would like to
define some kind of = interface such that the same congestion control could
more easily be = implemented (or even code could be re-used) by different =
applications and the application could then implement an addition = control
loop on top to change the coding. This additional higher = layer control loop
is not part of the rmcat charter thus having a = well defined interface would
be useful form my point of = view.

Mirja



On Thursday 10 October 2013 17:05:19 = Kevin Gross wrote:
I thought the scope of = the work for this group was to develop = techniques
applications can = use to avoid congestion. Since this is all being = done
internal to the = application, there's no need for an API to an = application.
We may need to = have interfaces to the network for ECN or = whatnot.

Kevin = Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>

On= Thu, Oct 10, 2013 at 8:28 AM, Piers O'Hanlon <p.ohanlon@gmail.com> = wrote:
Hi Mirja,

You bring up two = points:

- I'd agree we do need to have = some sort of communication between = the
congestion control and media/codec delivery - probably = some API is needed
to communicate current = parameters such as operating rate, latency, = and
possibly some time limited projections (or confidence) of = such
parameters.

- The issue in your second point = as I see is the issue of how deal = with
application limited and/or silence periods - which are a = tricky area. I
guess the corresponding concept = for TCP is Congestion Window = Validation,
and the changes in TFRC from = RFC3448 to  RFC5348 were largely down = to
such data-limited behaviours. For general info Gorry = Fairhurst has a
couple of recent papers on the = subject:
"TCP-Friendly Rate Control = (TFRC) for bursty media flows", ComCom, = 2011
And for TCP:
"Enhancing TCP to Support = Rate-Limited Traffic", CSWS, = 2012

But you are suggesting a further = addition to this - maybe when CWV = limits
are exceed - by adding a probe phase. Although I think = it's possible to
monitor the 'available' = bandwidth on the link - the problem maybe = that
other other flows will rapidly take up their 'fair share' = of the that
available capacity. So probably = the only way to maintain one's = capacity
is send some sort of dummy = traffic - or if we're WebRTC mode - send = some
HTML/JS/CSS etc in between the lulls of = media.

I guess this mix could be = handled via some coupled congestion service = or
suitable multi-substream low latency transport with = optional reliability
per = substream...

Cheers,

Piers

On 10 Oct 2013, at 14:23, Mirja = K=FChlewind wrote:
Hi = group,

I have = a question as an individual contributor. Looking at the = current
proposals which are all rate-based (right?), I was = wondering if we
maybe

need

a = higher layer interface to announce the current rate to = the
application?

Moreover, if the sending rate is application limited, = don't we need a

way = to

tell = the application that there is more space on the link and e.g. = the
quality = could be increased? Therefore we would need to know how = much
more = capacity would be available. Normally congestion control does = this
by = probing/slowly increasing the sending rate, but if the traffic = is

application

limited = that's not possible. Thus we maybe need some kind = of
measurement/testing method, that maintains an average rate = as provided

by = the

application, but can send for very short intervals with a = higher and
respective lower rate, like chirping (see PathChirp or TCP = Rapid).

Any = opinions on this?

Mirja



= -- =
-------------------------------------------------------------------Dipl.-Ing. Mirja K=FChlewind
Institute of Communication Networks and = Computer Engineering (IKR)
University of Stuttgart, = Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: = +49(0)711/685-67973
email: mirja.kuehlewind@ikr= .uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
-= ------------------------------------------------------------------

= --Apple-Mail=_27C96504-391E-4072-804A-881BB536FC2B-- From vsingh.ietf@gmail.com Fri Oct 11 06:36:59 2013 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 BF21821E81AF for ; Fri, 11 Oct 2013 06:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Woh-0J3htgi5 for ; Fri, 11 Oct 2013 06:36:58 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5993E21E816A for ; Fri, 11 Oct 2013 06:36:57 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so917658iet.7 for ; Fri, 11 Oct 2013 06:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=BHeWnempzjLdEP7lQvBzkpnJpVvLX5D2GbzHYQUCPxg=; b=A5VxPQbl9UC1WXB3TFsmm+N/zLlsW6ziLBNucK2NR3bdi9LvzqhXHz1tn9BEeR0YaR jpLbIKnrYNvI9eipE80sOFVxNSWnNSc6bwqK7t9Z2+Ef2mwFyCBrXMnyxG5BvHctKI3h 0AkokejFlPWeZBv5SNg13Ha3EFMV1zfQDNK/qz2gZbRvHwECpZh+5DrZIvCthdpQOj8c uLXM7TIyhtJNZhPrmW9+8nalv4Ulu7PC93mAPXlwk5+T1tFasQ2jK3qNet5ZslSltcNd rzibR7u4skz3tPWqfXaqUE15GrU1qaoQowAKbzWrm+ikmnT5eYlECrbNkKAeZi3AanmX m2TQ== X-Received: by 10.42.84.130 with SMTP id m2mr11341243icl.16.1381498616730; Fri, 11 Oct 2013 06:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Fri, 11 Oct 2013 06:36:36 -0700 (PDT) In-Reply-To: <201310111352.34562.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> <201310111352.34562.mirja.kuehlewind@ikr.uni-stuttgart.de> From: Varun Singh Date: Fri, 11 Oct 2013 16:36:36 +0300 Message-ID: To: Mirja Kuehlewind Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Piers O'Hanlon Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 13:36:59 -0000 Hi Piers, Mirja, Snipping away and remarking only on the dummy/redundant data inline. On Fri, Oct 11, 2013 at 2:52 PM, Mirja Kuehlewind wrote: > Hi Piers, > > inline... > >> But you are suggesting a further addition to this - maybe when CWV limit= s >> are exceed - by adding a probe phase. Although I think it's possible to >> monitor the 'available' bandwidth on the link - the problem maybe that >> other other flows will rapidly take up their 'fair share' of the that >> available capacity. So probably the only way to maintain one's capacity = is >> send some sort of dummy traffic - or if we're WebRTC mode - send some >> HTML/JS/CSS etc in between the lulls of media. > Yes and no. I partly addressed this already above basically saying don't = grab > the whole available capacity at once but increase the application rate > step-wise. But in fact you bring up one more problem. Let's assume the li= nk > is already full. How do I know that it still would be possible to increas= e my > sending rate because other (potentially less important traffic) might ada= pt > and free some capacity for me (without increasing the total congestion > level)? > >> >> I guess this mix could be handled via some coupled congestion service or >> suitable multi-substream low latency transport with optional reliability >> per substream... > You mean, sending dummy data? Not sure if that's the right solution. For = sure > it's a solution which probably works but I would favor any other solution= if > we could find one. > We experimented with sending redundant data for congestion control, it was = not exactly done to fill up the gap between the expected rate by the rate-contr= oller and the rate generated by the codec but to actually perform congestion cont= rol. Basic idea is to use higher redundancy when aggressively probing and less redundancy when conservative. This adaptive FEC mechanism could be used with other congestion control algorithms. We recently published this on arXiv (http://arxiv.org/pdf/1310.1582v1.pdf). Take a look and comment on if it is closer to what you had in mind. > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- --=20 http://www.netlab.tkk.fi/~varun/ From lars@netapp.com Fri Oct 11 06:41:15 2013 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 51F7221E81C4 for ; Fri, 11 Oct 2013 06:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.074 X-Spam-Level: X-Spam-Status: No, score=-5.074 tagged_above=-999 required=5 tests=[AWL=-2.475, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCYkypjKBAH5 for ; Fri, 11 Oct 2013 06:41:11 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id D689E21E81C2 for ; Fri, 11 Oct 2013 06:41:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1080,1371106800"; d="asc'?scan'208";a="58763189" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 11 Oct 2013 06:41:07 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Fri, 11 Oct 2013 06:41:08 -0700 From: "Eggert, Lars" To: Varun Singh Thread-Topic: [rmcat] application interface Thread-Index: AQHOxbwUG71BH2GC90SSIdxAvdvmm5nuc/gAgAFmpwCAAB0RAIAAAUIA Date: Fri, 11 Oct 2013 13:41:07 +0000 Message-ID: <0DA7B119-F0A1-4293-95F1-CEEE6077B873@netapp.com> References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> <201310111352.34562.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_0A8EB70C-FB7F-4F1B-9C44-03812FC03AF3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: rmcat WG , Mirja Kuehlewind , Piers O'Hanlon Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 13:41:15 -0000 --Apple-Mail=_0A8EB70C-FB7F-4F1B-9C44-03812FC03AF3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On Oct 11, 2013, at 15:36, Varun Singh wrote: > Basic idea is to use higher redundancy when aggressively probing and less > redundancy when conservative. This adaptive FEC mechanism could be used > with other congestion control algorithms. We recently published this on > arXiv (http://arxiv.org/pdf/1310.1582v1.pdf). Take a look and comment > on if it is closer to what you had in mind. Full disclosure: Nokia may have IPR on the mechanism described in the paper. Lars --Apple-Mail=_0A8EB70C-FB7F-4F1B-9C44-03812FC03AF3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUlf/8tZcnpRveo1xAQK3FgP/VVMNsR0OIeVDjSWDmJe68q54wCc4V1F9 NpIycD6Sby73lXcrB6D5PL3bOf1f7OdE5S9NakdmyG1FOuiirKHVJfa4QQLRr+8N cyFK7HKgnCjL0IkKM1E5aYzxl4zhPQEooXWmknZeM7aBNNjaUOVU9lmomNpui7fR U3WIiTi466g= =AjqF -----END PGP SIGNATURE----- --Apple-Mail=_0A8EB70C-FB7F-4F1B-9C44-03812FC03AF3-- From wes@mti-systems.com Fri Oct 11 07:10:51 2013 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 7542511E8141 for ; Fri, 11 Oct 2013 07:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnNNTv7rtyQv for ; Fri, 11 Oct 2013 07:10:45 -0700 (PDT) Received: from atl4mhob01.myregisteredsite.com (atl4mhob01.myregisteredsite.com [209.17.115.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7068111E81F4 for ; Fri, 11 Oct 2013 07:10:08 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob01.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r9BEA7uA009158 for ; Fri, 11 Oct 2013 10:10:07 -0400 Received: (qmail 9160 invoked by uid 0); 11 Oct 2013 14:10:07 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.129?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 11 Oct 2013 14:10:07 -0000 Message-ID: <525806BA.8040605@mti-systems.com> Date: Fri, 11 Oct 2013 10:10:02 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Welzl References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <3D885D4A-A5B7-409F-BC55-9D44EC787EDC@gmail.com> <201310111355.32264.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rmcat WG , Mirja Kuehlewind , Piers O'Hanlon , Kevin Gross Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 14:10:51 -0000 On 10/11/2013 9:12 AM, Michael Welzl wrote: > I don't understand why you call it a control loop, it's just an API, and > I don't understand why you say it's not in the charter? The charter says: > > "Identify interactions between applications and RTP flows to enable > conveying > helpful cross-layer information such as per-packet priorities, flow > elasticity, etc. > This information might be used to populate an API, but the WG will not > define a > specific API itself." > > The intention behind this really was an API, conceptually - as far as I > can tell the (later added) "anti-API" wording is just there to ensure > that there won't be an API defined in the sense of defining datatypes > and such machine-specific things, but something more abstract. But it's > about defining how applications communicate with the transport layer. Yes, the need is to define what information needs to be available "above" the CC algorithm. "API" suggests definition of how that information is accessed (polled, evented up, etc), which we don't need to get into. -- Wes Eddy MTI Systems From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 11 07:19:09 2013 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 B64EE21E80F4 for ; Fri, 11 Oct 2013 07:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL+ETCSY3v3o for ; Fri, 11 Oct 2013 07:19:06 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6604711E81BF for ; Fri, 11 Oct 2013 07:19:04 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 573AA602DB; Fri, 11 Oct 2013 16:19:03 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 127DA60177; Fri, 11 Oct 2013 16:19:03 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Michael Welzl Date: Fri, 11 Oct 2013 16:19:02 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <201310111355.32264.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310111619.02743.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: rmcat WG Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 14:19:09 -0000 Hi Michael, To clarify this: the API is in charter! I was talking about the control loo= p=20 on the application layer that might decide to change codec based on=20 information provided by this API.=20 In fact, my original question was explicitly about how this API should look= =20 like. As you mention correctly, we also have this milestone on "Interaction= s=20 between applications and RTP flows as an Informational RFC". As a chair, I= =20 believe (and I hope that this discussion will help) we should focus next on= =20 actually writing a first draft to specify the API. Because my feeling that= =20 this is also needed for the people designing/proposing an congestion contro= l=20 scheme to orientate.=20 Moreover, what I also took from the on-going discussion is, that it might b= e=20 important to get an application model (this is also related to the evaluati= on=20 design team though). I was always having in mind, that die audio/video=20 applications can switch rates only in discrete steps. But I guess but addin= g=20 more or less FEC, the rate spectrum can be more continuously as well...? I think we as a working group need to have a clear view, what a RT applicat= ion=20 can do and where the limits are, before designing and evaluation the=20 congestion control. So eventhough we will not design and standardize this = =20 application layer control loop, I was talking about, we should at least be= =20 aware what applications are doing or what should/would be possible in futur= e. Mirja On Friday 11 October 2013 15:12:57 Michael Welzl wrote: > Hi, > > I don't understand why you call it a control loop, it's just an API, and I > don't understand why you say it's not in the charter? The charter says: > > "Identify interactions between applications and RTP flows to enable > conveying helpful cross-layer information such as per-packet priorities, > flow elasticity, etc. This information might be used to populate an API, > but the WG will not define a specific API itself." > > The intention behind this really was an API, conceptually - as far as I c= an > tell the (later added) "anti-API" wording is just there to ensure that > there won't be an API defined in the sense of defining datatypes and such > machine-specific things, but something more abstract. But it's about > defining how applications communicate with the transport layer. > > FWIW, the result on slide 16: > http://www.ietf.org/proceedings/87/slides/slides-87-rmcat-2.pdf > is only possible because we assume that coupled congestion control gets n= ot > only the rate that the congestion controller has calculated, but also the > "desired rate" from the application (which may be smaller than the > congestion controller's rate). > > Now this is the other direction than what you mean - the transport getting > the rate from the application - but it does require at least some > rudimentary communication between applications and the transport. About t= he > rest of your musings, I agree, and I also agree with the concerns that we= re > raised about defining too much, we'd have to be careful here. In your > answer to Piers, you wrote: > > "I would be careful to make the interface too large and too complicated. > The question is which information is really needed for the application to > decide to switch the coding and also (maybe even more important) which > information can be understood by every application designer. I currently > believe that the information, what the estimated largest possible rate is, > might be enough." > > and I agree, probably you won't need more than this, *upward*, and what we > called the application's "desired rate", *downward*. > > As another comment to address Kevin's concern: this would be only about > things that are of definite concern to the application and can't be dealt > with below without involving the application. ECN is in fact a nice examp= le > of a case that doesn't need the application, it could be dealt with below= - > even for TCP, as Mirja et al's related draft shows: > http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback > > Cheers, > Michael > > On 11. okt. 2013, at 13:55, Mirja Kuehlewind wrote: > > Hi Kevin, > > > > sure the congestion control could also be implemented in the applicatio= n. > > I was assuming that the congestion control is part if the transport > > layer. But even if you implement it in the application, you potentially > > would like to define some kind of interface such that the same congesti= on > > control could more easily be implemented (or even code could be re-used) > > by different applications and the application could then implement an > > addition control loop on top to change the coding. This additional high= er > > layer control loop is not part of the rmcat charter thus having a well > > defined interface would be useful form my point of view. > > > > Mirja > > > > On Thursday 10 October 2013 17:05:19 Kevin Gross wrote: > >> I thought the scope of the work for this group was to develop techniqu= es > >> applications can use to avoid congestion. Since this is all being done > >> internal to the application, there's no need for an API to an > >> application. We may need to have interfaces to the network for ECN or > >> whatnot. > >> > >> Kevin Gross > >> +1-303-447-0517 > >> Media Network Consultant > >> AVA Networks - www.AVAnw.com > >> > >> On Thu, Oct 10, 2013 at 8:28 AM, Piers O'Hanlon = =20 wrote: > >>> Hi Mirja, > >>> > >>> You bring up two points: > >>> > >>> - I'd agree we do need to have some sort of communication between the > >>> congestion control and media/codec delivery - probably some API is > >>> needed to communicate current parameters such as operating rate, > >>> latency, and possibly some time limited projections (or confidence) of > >>> such parameters. > >>> > >>> - The issue in your second point as I see is the issue of how deal wi= th > >>> application limited and/or silence periods - which are a tricky area.= I > >>> guess the corresponding concept for TCP is Congestion Window > >>> Validation, and the changes in TFRC from RFC3448 to RFC5348 were > >>> largely down to such data-limited behaviours. For general info Gorry > >>> Fairhurst has a couple of recent papers on the subject: > >>> "TCP-Friendly Rate Control (TFRC) for bursty media flows", ComCom, 20= 11 > >>> And for TCP: > >>> "Enhancing TCP to Support Rate-Limited Traffic", CSWS, 2012 > >>> > >>> But you are suggesting a further addition to this - maybe when CWV > >>> limits are exceed - by adding a probe phase. Although I think it's > >>> possible to monitor the 'available' bandwidth on the link - the probl= em > >>> maybe that other other flows will rapidly take up their 'fair share' = of > >>> the that available capacity. So probably the only way to maintain one= 's > >>> capacity is send some sort of dummy traffic - or if we're WebRTC mode= - > >>> send some HTML/JS/CSS etc in between the lulls of media. > >>> > >>> I guess this mix could be handled via some coupled congestion service > >>> or suitable multi-substream low latency transport with optional > >>> reliability per substream... > >>> > >>> Cheers, > >>> > >>> Piers > >>> > >>> On 10 Oct 2013, at 14:23, Mirja K=FChlewind wrote: > >>>> Hi group, > >>>> > >>>> I have a question as an individual contributor. Looking at the curre= nt > >>>> proposals which are all rate-based (right?), I was wondering if we > >>>> maybe > >>> > >>> need > >>> > >>>> a higher layer interface to announce the current rate to the > >>>> application? > >>>> > >>>> Moreover, if the sending rate is application limited, don't we need a > >>> > >>> way to > >>> > >>>> tell the application that there is more space on the link and e.g. t= he > >>>> quality could be increased? Therefore we would need to know how much > >>>> more capacity would be available. Normally congestion control does > >>>> this by probing/slowly increasing the sending rate, but if the traff= ic > >>>> is > >>> > >>> application > >>> > >>>> limited that's not possible. Thus we maybe need some kind of > >>>> measurement/testing method, that maintains an average rate as provid= ed > >>> > >>> by the > >>> > >>>> application, but can send for very short intervals with a higher and > >>>> respective lower rate, like chirping (see PathChirp or TCP Rapid). > >>>> > >>>> Any opinions on this? > >>>> > >>>> Mirja > > > > -- > > ------------------------------------------------------------------- > > Dipl.-Ing. Mirja K=FChlewind > > Institute of Communication Networks and Computer Engineering (IKR) > > University of Stuttgart, Germany > > Pfaffenwaldring 47, D-70569 Stuttgart > > > > tel: +49(0)711/685-67973 > > email: mirja.kuehlewind@ikr.uni-stuttgart.de > > web: www.ikr.uni-stuttgart.de > > ------------------------------------------------------------------- =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 11 09:14:38 2013 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 9AD0C11E81D5 for ; Fri, 11 Oct 2013 09:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfBw0CUm8N8I for ; Fri, 11 Oct 2013 09:14:34 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 113D711E81B4 for ; Fri, 11 Oct 2013 09:14:32 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id BFA09602DB; Fri, 11 Oct 2013 18:14:30 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id AF95D60174; Fri, 11 Oct 2013 18:14:30 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Fri, 11 Oct 2013 18:14:30 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <31915F4B-827C-4D8E-B34F-67F895C0F5A4@ifi.uio.no> In-Reply-To: <31915F4B-827C-4D8E-B34F-67F895C0F5A4@ifi.uio.no> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310111814.30421.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Michael Welzl Subject: Re: [rmcat] Issues with draft-welzl-rmcat-coupled-cc-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 16:14:38 -0000 Hi Michael, just realized that I never replied to this mail because I was one of the=20 persons who had the feeling that it's complicated... =46irst of all, I did not mean to say that the draft is complicated, but th= e=20 algorithm your are proposing seems quite 'complicated'. Mainly I'm wonderin= g=20 if we can't find a solution that is as most simple as possible and keep mos= t=20 of the complexity in the actual congestion control loop of each single flow= =2E=20 And that's also the point I was concerned about: I would like to avoid that= =20 your mechanism basically disabled or overwrites the congestion control=20 decision itself. Not sure if this feedback is already too late as I know your are working on= a=20 new revision. Anyway I hope that's helpful. Mirja On Thursday 01 August 2013 15:05:27 Michael Welzl wrote: > Hi, > > Thanks to everyone who gave comments on our draft, > draft-welzl-rmcat-coupled-cc-01, in the RMCAT meeting just now. I'm glad = to > see that this raised some interest! > > I think it would be great if we could continue the discussion on the list. > So, if you have specific concerns or questions, please shoot! e.g. the > draft has been called "confusing" and "complicated"; we actually tried ha= rd > to make this as easy to read as possible, so we'd greatly appreciate > getting more concrete hints about what parts should be improved. > > At the end of the presentation, Lars raised a concern about the complexity > about what he called "another control loop interacting with the control > loops". Here I have to agree, obviously our mechanism changes the dynamics > of the controllers involved, and we're doing our best to evaluate what th= is > really entails; this work is only just beginning. As you have seen, in > simple scenarios with TFRC (which we used because we didn't have code of a > more suitable RMCAT mechanism available to simulate,, plus its dynamics a= re > relatively well known), the overall effect seems to be pretty positive.=20 > But yes, it will have to be evaluated with every new mechanism to really > see the dynamic behaviour arising from it. In theory, it should even be > possible to couple different congestion controllers with our scheme, and > then the dynamics are even less obvious :) > > Cheers, > Michael =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From michawe@ifi.uio.no Fri Oct 11 23:01:45 2013 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 C64A011E8200 for ; Fri, 11 Oct 2013 23:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRf4YlYDD3s0 for ; Fri, 11 Oct 2013 23:01:41 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 8E29521F9C42 for ; Fri, 11 Oct 2013 23:01:34 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VUsGb-0003Lu-BB; Sat, 12 Oct 2013 08:01:33 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUsGa-0003Dv-OQ; Sat, 12 Oct 2013 08:01:33 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <201310111619.02743.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Sat, 12 Oct 2013 08:01:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de> <201310111355.32264.mirja.kuehlewind@ikr.uni-stuttgart.de> <201310111619.02743.mirja.kuehlewind@ikr.uni-stuttgart.de> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 3 total rcpts 8434 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9B1075CF5997F3C3532E83B7F88ED0FE6AA5233B X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 280 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 06:01:45 -0000 On 11. okt. 2013, at 16:19, Mirja Kuehlewind = wrote: > Hi Michael, >=20 > To clarify this: the API is in charter! I was talking about the = control loop=20 > on the application layer that might decide to change codec based on=20 > information provided by this API.=20 >=20 > In fact, my original question was explicitly about how this API should = look=20 > like. As you mention correctly, we also have this milestone on = "Interactions=20 > between applications and RTP flows as an Informational RFC". As a = chair, I=20 > believe (and I hope that this discussion will help) we should focus = next on=20 > actually writing a first draft to specify the API. Because my feeling = that=20 > this is also needed for the people designing/proposing an congestion = control=20 > scheme to orientate.=20 I agree; > Moreover, what I also took from the on-going discussion is, that it = might be=20 > important to get an application model (this is also related to the = evaluation=20 > design team though). I was always having in mind, that die audio/video=20= > applications can switch rates only in discrete steps. But I guess but = adding=20 > more or less FEC, the rate spectrum can be more continuously as = well...? > I think we as a working group need to have a clear view, what a RT = application=20 > can do and where the limits are, before designing and evaluation the=20= > congestion control. So eventhough we will not design and standardize = this =20 > application layer control loop, I was talking about, we should at = least be=20 > aware what applications are doing or what should/would be possible in = future. One aspect is that there is the possibility of either doing FEC, as has = been brought up, or content-based ARQ in the application. What you = choose, or how much of each you do, is a non-trivial design application = question - I have advised a Ph.D. thesis on that, see: = http://heim.ifi.uio.no/michawe//research/students/michael_schier-diss_fina= l.pdf I'm pointing to this thesis because I think that the video coding = introduction in this document is a very nice read - easy to understand, = yet going beyond what most "networkers" normally understand about video = (I think). Whether an application uses FEC or ARQ, such decisions are based on = knowledge about the importance of parts of the media stream. This = extends beyond simply I- vs. P- vs. B-Frame, as each frame consists of = metablocks and blocks, of different types, with different = dependencies... the importance of a network packet can be derived at = run-time, and if the transport layer could make use of that information, = then that would be a useful part of the API. This brings me to another, more general network question, for which I'll = cc tsv-area, in a separate email. Cheers, Michael From michawe@ifi.uio.no Fri Oct 11 23:12:08 2013 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 D1D5221E80B7; Fri, 11 Oct 2013 23:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qw+LmZ9TbKV; Fri, 11 Oct 2013 23:12:03 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id AC60511E81D5; Fri, 11 Oct 2013 23:12:02 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VUsQi-00010m-2d; Sat, 12 Oct 2013 08:12:00 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUsQh-0005Xd-KV; Sat, 12 Oct 2013 08:12:00 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 12 Oct 2013 08:11:59 +0200 Message-Id: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> To: rmcat WG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 7 sum msgs/h 4 total rcpts 8436 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D35624419EDDA9708629759ED8D7E35D3C519F53 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 281 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: "tsv-area@ietf.org" Subject: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 06:12:09 -0000 Hi, I'll begin by apologizing for asking what I'm quite sure is a terribly = stupid question to many of you. The question is: It has long been known that media data can have different levels of = importance. Simply put, if packet #1 from a single source contains parts = of a video's I-Frame and packet #2 contains only parts of B-Frames, and = both end up in the same queue, controlled by an AQM (for instance), it = would be better for the video stream if packet #2 would be dropped = rather than packet #1. There is nothing new with this story; it's not hard to find research = papers that document various variations of this theme, showing benefits = in video quality. My question is, why is none of this happening? Is it because DSCP values are typically associated with sources, and = hence, marking packet #2 as "less" important would put the source at the = risk of having its packets less important than not only its own other = packets, but anybody else's? But there is equipment that does = per-connection stuff, and such things could probably better be done near = the edges, where the bottleneck typically is... so if that's the whole = issue, we could define DSCP values that mean relative importance *within = the same five-tuple only*. Surely that has been thought about and = probably proposed by folks before, so what happened? Why isn't it done? Or is it because per-five-tuple-functionality in the network is regarded = as being too costly, and not encouraged, and hence not standardized? I'm just trying to understand the reasons for this particular = long-standing difference between research an reality. Cheers, Michael From michawe@ifi.uio.no Fri Oct 11 23:28:58 2013 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 3F44121E80C6 for ; Fri, 11 Oct 2013 23:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsWTqqvlRqvk for ; Fri, 11 Oct 2013 23:28:52 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id EBBB221F9BEF for ; Fri, 11 Oct 2013 23:28:51 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VUsgo-0004bi-O5; Sat, 12 Oct 2013 08:28:38 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUsgo-0001Av-6M; Sat, 12 Oct 2013 08:28:38 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <201310111814.30421.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Sat, 12 Oct 2013 08:28:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E1493CE-AD23-4361-9BB8-D720CB78E0DC@ifi.uio.no> References: <31915F4B-827C-4D8E-B34F-67F895C0F5A4@ifi.uio.no> <201310111814.30421.mirja.kuehlewind@ikr.uni-stuttgart.de> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 9 sum msgs/h 5 total rcpts 8438 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3EE8C0B73020DA545D3DB673E3EED34F87368DEB X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 282 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org Subject: Re: [rmcat] Issues with draft-welzl-rmcat-coupled-cc-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 06:28:58 -0000 On 11. okt. 2013, at 18:14, Mirja Kuehlewind = wrote: > Hi Michael, >=20 > just realized that I never replied to this mail because I was one of = the=20 > persons who had the feeling that it's complicated... We're thankful for this general "it's complicated" feedback that we got, = because it put us on what we think is the right track: the only way we = saw to simplify things was to devise an active variant, which is = conceptually closer to RFC 2140. There will be a trade-off between using = an active or passive variant, so it's good to have both. I don't want to = go into more details now because we're just finishing it, and it's = potentially a waste of time to discuss details of a moving target. > First of all, I did not mean to say that the draft is complicated, but = the=20 > algorithm your are proposing seems quite 'complicated'. Mainly I'm = wondering=20 > if we can't find a solution that is as most simple as possible and = keep most=20 > of the complexity in the actual congestion control loop of each single = flow.=20 > And that's also the point I was concerned about: I would like to avoid = that=20 > your mechanism basically disabled or overwrites the congestion control=20= > decision itself. >=20 > Not sure if this feedback is already too late as I know your are = working on a=20 > new revision. Anyway I hope that's helpful. It's not too late, as you already gave this feedback in Berlin too (not = sure this specific details are in the minutes, perhaps - but anyway I = remember you saying that). I understand that the complexity concern isn't so much the algorithm = itself, but the arising dynamics. I don't think it's correct to say that = our mechanism disables the congestion control decision, but yes it = overwrites it, and I think overwriting is inevitable (that's also what's = done in RFC 2140). Somehow, the rate decision must be influenced by = knowledge about other flows sharing the same bottleneck, that's the = whole point. The only alternatives I see for doing that are to #1 = directly embed such knowledge in the congestion control algorithm (which = is what MPTCP does), or to #2 do "split connections" as in some TCP = middleboxes and play around with the congestion control in the splitter. #1 doesn't seem any simpler to me, it also requires understanding the = resulting dynamics per mechanism (the mechanism that you changed). Our = goal was to be more flexible, and minimize the changes that have to be = done to congestion controllers. And I don't see how #2 could be done = efficiently here, or be any better than what we propose. Actually the dynamics aren't so complex if we remove the dust of all the = features that we had added to get the mechanism we showed in Berlin. = Essentially, if you have 2 flows at equal priority, and one sends at 1/4 = the capacity and one sends at 1/2 of the capacity, what our scheme does = is to say: the total rate is 3/4 of the capacity, and each one of you = gets half of that. When it's their turn, they will still continue trying = to probe for the bandwidth, and they will still react to congestion, but = their behavior is coupled by considering the total rate of all flows and = not only the single flow's rate as input. Cheers, Michael From vsingh.ietf@gmail.com Fri Oct 11 23:53:43 2013 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 6194E21F9EAD; Fri, 11 Oct 2013 23:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3M-yEt7B8XB; Fri, 11 Oct 2013 23:53:42 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B387A21E80BB; Fri, 11 Oct 2013 23:53:34 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id e14so4840588iej.39 for ; Fri, 11 Oct 2013 23:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3MS3M2BXlcVhqUQil2nW0r/9rI2Sz7Rw+f/r3r5SELA=; b=O4qeRQHGi+UHgjq5MCrwh+ZOsltH+MlbSdHIco106brvhN8RoTXpY9JN7c4OuJN30k 5FoAbBSBYMIdZtlrgMOyJCnVl3MYqwHCD/UmuqojbGdlq/vbM7IKTupvSQPqRNqFbRb2 EH31m+Nkr0f/SpDewCHxZSit/oGZD98McEiYEWfq5L3777Jjxhe7Da+qK341BvqMMNaX MnSpCc9Fn2a5+i5LBHuNl0GfywE5Nqmao+dAPmXn7HCLoXqRDNDT/inzO3OhGmHJlBww 5wcIiJt6lbhH4NRdszr6DNV53enAEAEBF0od9b0o57HJtMhvPvnNK8KoZvu58z64lpf+ FpJQ== X-Received: by 10.43.154.18 with SMTP id lc18mr437942icc.41.1381560813623; Fri, 11 Oct 2013 23:53:33 -0700 (PDT) References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> From: Varun Singh Mime-Version: 1.0 (1.0) In-Reply-To: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> Date: Sat, 12 Oct 2013 09:53:31 +0300 Message-ID: <-774420348401733698@unknownmsgid> To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 06:53:43 -0000 Hi Michael, In my experience, Video telephony applications do not generate any b-frames. So #2 packets do not exist. Secondly some generate I-frames only when they really have to (scene change or decoding packet chain is corrupted) otherwise their GOP is set to infinity. For sending I-frames, there are many tricks that a sending endpoint can play, it doesn't need to burst the whole frame immediately, it can pace out (there are 10s of milliseconds) before the next frames is generated. Alternatively, if the frame is too large, they can send parts of the I-frame with the subsequent frames, this potentially delays rendering. I don't know if any of these have been standardized. If a part of a frame is lost, the receiver can send a NACK or packet loss indication Or reference picture selection. Another way is that the sending point uses unequal level of protection (ULP) ie., not all packets or frames are FEC'ed. Lastly it can vary the packet size, ie., it may do this by varying the size of slices (combinations of macro blocks). Applicability of ARQ typically depends on observed end-to-end delay and observed losses. The endpoint won't send a nack or a retransmission if there are too many losses or if it thinks it won't reach in time for decoding. Regards, Varun ---- http://www.netlab.tkk.fi/~varun > On 12.10.2013, at 9.12, Michael Welzl wrote: > > Hi, > > I'll begin by apologizing for asking what I'm quite sure is a terribly st= upid question to many of you. > > The question is: > > It has long been known that media data can have different levels of impor= tance. Simply put, if packet #1 from a single source contains parts of a vi= deo's I-Frame and packet #2 contains only parts of B-Frames, and both end u= p in the same queue, controlled by an AQM (for instance), it would be bette= r for the video stream if packet #2 would be dropped rather than packet #1. > > There is nothing new with this story; it's not hard to find research pape= rs that document various variations of this theme, showing benefits in vide= o quality. > > My question is, why is none of this happening? > > Is it because DSCP values are typically associated with sources, and henc= e, marking packet #2 as "less" important would put the source at the risk o= f having its packets less important than not only its own other packets, bu= t anybody else's? But there is equipment that does per-connection stuff, a= nd such things could probably better be done near the edges, where the bott= leneck typically is... so if that's the whole issue, we could define DSCP v= alues that mean relative importance *within the same five-tuple only*. Sure= ly that has been thought about and probably proposed by folks before, so wh= at happened? Why isn't it done? > > Or is it because per-five-tuple-functionality in the network is regarded = as being too costly, and not encouraged, and hence not standardized? > > I'm just trying to understand the reasons for this particular long-standi= ng difference between research an reality. > > Cheers, > Michael > From michawe@ifi.uio.no Sat Oct 12 01:29:07 2013 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 BE29D21E80D0; Sat, 12 Oct 2013 01:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axd6OxY+a2bn; Sat, 12 Oct 2013 01:29:01 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id AB21B21E80AF; Sat, 12 Oct 2013 01:28:52 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VUuZ7-0000Bp-Bq; Sat, 12 Oct 2013 10:28:49 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUuZ6-0003YZ-Sy; Sat, 12 Oct 2013 10:28:49 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Sat, 12 Oct 2013 10:28:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E213C3D-56F2-4F8F-8D96-E7D9A29C6F75@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 8442 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AF1ADC95C82C10E2545DEB4A2FC146267BD5AE56 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 284 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 08:29:07 -0000 On 12. okt. 2013, at 08:28, Mikael Abrahamsson wrote: > On Sat, 12 Oct 2013, Michael Welzl wrote: >=20 >> My question is, why is none of this happening? >=20 > My guess is that the rule to always deliver packets within a stream in = order. If packets within the same stream have different DCSP values, = there is a risk that they will go into different queues and they might = be delivered out of order. A lot of applications that do real-time will = have a PDV buffer, but won't have much of a out-of-order buffer. If a = packet with sequence number 10 arrives after sequence number 8, packet = number 9 is often assumed to be lost. >=20 > AQM is not widely deployed at all on the Internet as it is today, and = a lot of devices will just have 4 different queues. Also as you say = below, putting packets into different queues might mean they compete = with other traffic and you might get packet loss due to that. >=20 > It would of course be of interest going forward to look into your = proposal. AQM/Bufferbloat movement could perhaps benefit from this, but = the current thinking is to make sure that all streams get equal access = to the media with minimal influence between them, not that much to = decide what packets within a stream to select for drop. Thanks, that's about what I guessed... strange, a bit, given that it's = not hard to show quite large quality gains if packet priorities within a = stream (five-tuple) are honored, and doing per-5-tuple things near the = edge doesn't seem all too unusual to me... So indeed it wasn't a proposal, I was just wondering why it's not done. = Maybe not enough interest from the parties involved (because application = developers are not usually the same people that build middle-boxes) Cheers, Michael From michawe@ifi.uio.no Sat Oct 12 01:33:01 2013 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 BA3C521E80E8; Sat, 12 Oct 2013 01:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcQpkXNYF+ji; Sat, 12 Oct 2013 01:32:56 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 2221821E80D0; Sat, 12 Oct 2013 01:32:53 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VUud1-0001ik-KH; Sat, 12 Oct 2013 10:32:51 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUud1-0001xp-53; Sat, 12 Oct 2013 10:32:51 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <-774420348401733698@unknownmsgid> Date: Sat, 12 Oct 2013 10:32:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <-774420348401733698@unknownmsgid> To: Varun Singh X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 11 sum msgs/h 4 total rcpts 8445 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6C80E2B009EE2E4532F607025C6F7F7A7ED78849 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 285 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 08:33:01 -0000 On 12. okt. 2013, at 08:53, Varun Singh wrote: > Hi Michael, >=20 > In my experience, Video telephony applications do not generate any > b-frames. So #2 packets do not exist. Secondly some generate I-frames > only when they really have to (scene change or decoding packet chain > is corrupted) otherwise their GOP is set to infinity. But packet importance is more than just I- vs. P- vs. B-Frames - there = are blocks that depend on each other, and the more data depends on data = in a packet, the more important that packet gets. > For sending I-frames, there are many tricks that a sending endpoint > can play, it doesn't need to burst the whole frame immediately, it can > pace out (there are 10s of milliseconds) before the next frames is > generated. Alternatively, if the frame is too large, they can send > parts of the I-frame with the subsequent frames, this potentially > delays rendering. I don't know if any of these have been standardized. Probably no need to standardize this? > If a part of a frame is lost, the receiver can send a NACK or packet > loss indication Or reference picture selection. >=20 > Another way is that the sending point uses unequal level of protection > (ULP) ie., not all packets or frames are FEC'ed. > Lastly it can vary the packet size, ie., it may do this by varying the > size of slices (combinations of macro blocks). >=20 > Applicability of ARQ typically depends on observed end-to-end delay > and observed losses. The endpoint won't send a nack or a > retransmission if there are too many losses or if it thinks it won't > reach in time for decoding. Yes - the choices are really: 1. add FEC for the more important packets 2. do ARQ when applicable for the more important packets 3. somehow tell the network about the more important packets (but you = can't, normally) and there are trade-offs between these choices. I just wonder if we need = 3. as a part of the API to transport? Cheers, Michael From vsingh.ietf@gmail.com Sat Oct 12 01:49:44 2013 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 EB4F721E80EA; Sat, 12 Oct 2013 01:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF37lB+C1epr; Sat, 12 Oct 2013 01:49:42 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B6B6921E80AF; Sat, 12 Oct 2013 01:49:42 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id x13so10822525ief.3 for ; Sat, 12 Oct 2013 01:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6dpTTqMw+xk0w8uCDtq8+2MQKOckcMsfAa2fpEetDSs=; b=pCHX118ZWOpJQ6DPsY3myRZpkv8UejeM+9wLOEfUfRX+QwEepYTRHI4ZsNhE+pT454 ZhnL0PmFZOUExzu+zGABejJ/AY4QgvyhrDbBIb+mN9cs6HW6Ny+9E/Muh0ZC5bwtdkmd r/O/Y1J4y48fn7plhBymhEzWjwVybsZB6zSoVgRMvzTHXAsCCJwKWCN6oqME2MCVDx4V xkeEcKvYzK6cISXIxdUbKIfjBBUzk3JCXv12uUc2URWo8RQeXcsI7wF5jJosYPTKNaXm MYMDu/BuuS0zKB+ao9+BdBu1vqKJ6Y7a17E9ULwo++6n/wR++4K64iJ5o4JDqF0xKlU1 xLfg== X-Received: by 10.42.208.211 with SMTP id gd19mr14084694icb.15.1381567782092; Sat, 12 Oct 2013 01:49:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sat, 12 Oct 2013 01:49:22 -0700 (PDT) In-Reply-To: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <-774420348401733698@unknownmsgid> From: Varun Singh Date: Sat, 12 Oct 2013 11:49:22 +0300 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 08:49:44 -0000 Hi Michael, On Sat, Oct 12, 2013 at 11:32 AM, Michael Welzl wrote: > > On 12. okt. 2013, at 08:53, Varun Singh wrote: > >> Hi Michael, >> >> In my experience, Video telephony applications do not generate any >> b-frames. So #2 packets do not exist. Secondly some generate I-frames >> only when they really have to (scene change or decoding packet chain >> is corrupted) otherwise their GOP is set to infinity. > > But packet importance is more than just I- vs. P- vs. B-Frames - there are blocks that depend on each other, and the more data depends on data in a packet, the more important that packet gets. > At the moment, some systems use unequal level of protection (UEP) to protect the packets they think are more important, I suppose what you are proposing is to add a kill bit in the packets that are less important. I think there is a tradeoff, redundancy causes overhead (which the endpoint should control) and adding priorities pushes the responsibility to the middlebox and in both the mechanisms, the sender should probably adapt its rate based on input from the receiver. > >> For sending I-frames, there are many tricks that a sending endpoint >> can play, it doesn't need to burst the whole frame immediately, it can >> pace out (there are 10s of milliseconds) before the next frames is >> generated. Alternatively, if the frame is too large, they can send >> parts of the I-frame with the subsequent frames, this potentially >> delays rendering. I don't know if any of these have been standardized. > > Probably no need to standardize this? > Depends where this is done, at the RTP level or elsewhere. If at the RTP level there probably needs to be some guidance on how the bits are fed to the decoding pipeline from the RTP layer. > >> If a part of a frame is lost, the receiver can send a NACK or packet >> loss indication Or reference picture selection. >> >> Another way is that the sending point uses unequal level of protection >> (ULP) ie., not all packets or frames are FEC'ed. >> Lastly it can vary the packet size, ie., it may do this by varying the >> size of slices (combinations of macro blocks). >> >> Applicability of ARQ typically depends on observed end-to-end delay >> and observed losses. The endpoint won't send a nack or a >> retransmission if there are too many losses or if it thinks it won't >> reach in time for decoding. > > Yes - the choices are really: > 1. add FEC for the more important packets > 2. do ARQ when applicable for the more important packets > 3. somehow tell the network about the more important packets (but you can't, normally) > > and there are trade-offs between these choices. I just wonder if we need 3. as a part of the API to transport? > when you say transport, you mean DSCP codepoint to indicate to the middleboxes along the path or an API from the codec to the transport (RTP/UDP) at the sending endpoint? > Cheers, > Michael > -- http://www.netlab.tkk.fi/~varun/ From michawe@ifi.uio.no Sat Oct 12 02:43:28 2013 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 CA29921F9D65; Sat, 12 Oct 2013 02:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj792OaEwbpc; Sat, 12 Oct 2013 02:43:22 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id A9B2321F8EB5; Sat, 12 Oct 2013 02:43:21 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VUvj8-0003E6-Df; Sat, 12 Oct 2013 11:43:14 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUvj7-0000Bv-OA; Sat, 12 Oct 2013 11:43:14 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Sat, 12 Oct 2013 11:43:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <-774420348401733698@unknownmsgid> To: Varun Singh X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 8448 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F3B681F77563BE6099B8CCEC2897B9B04430B1D3 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 286 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 09:43:28 -0000 On 12. okt. 2013, at 10:49, Varun Singh wrote: > Hi Michael, >=20 > On Sat, Oct 12, 2013 at 11:32 AM, Michael Welzl = wrote: >>=20 >> On 12. okt. 2013, at 08:53, Varun Singh = wrote: >>=20 >>> Hi Michael, >>>=20 >>> In my experience, Video telephony applications do not generate any >>> b-frames. So #2 packets do not exist. Secondly some generate = I-frames >>> only when they really have to (scene change or decoding packet chain >>> is corrupted) otherwise their GOP is set to infinity. >>=20 >> But packet importance is more than just I- vs. P- vs. B-Frames - = there are blocks that depend on each other, and the more data depends on = data in a packet, the more important that packet gets. >>=20 >=20 > At the moment, some systems use unequal level of protection (UEP) to = protect > the packets they think are more important, I suppose what you are = proposing is > to add a kill bit in the packets that are less important. Exactly... > I think there is a tradeoff, redundancy causes overhead (which the > endpoint should > control) and adding priorities pushes the responsibility to the > middlebox and in both > the mechanisms, the sender should probably adapt its rate based on > input from the receiver. Exactly >>> For sending I-frames, there are many tricks that a sending endpoint >>> can play, it doesn't need to burst the whole frame immediately, it = can >>> pace out (there are 10s of milliseconds) before the next frames is >>> generated. Alternatively, if the frame is too large, they can send >>> parts of the I-frame with the subsequent frames, this potentially >>> delays rendering. I don't know if any of these have been = standardized. >>=20 >> Probably no need to standardize this? >>=20 >=20 > Depends where this is done, at the RTP level or elsewhere. If at the = RTP level > there probably needs to be some guidance on how the bits are fed to = the decoding > pipeline from the RTP layer. >>> If a part of a frame is lost, the receiver can send a NACK or packet >>> loss indication Or reference picture selection. >>>=20 >>> Another way is that the sending point uses unequal level of = protection >>> (ULP) ie., not all packets or frames are FEC'ed. >>> Lastly it can vary the packet size, ie., it may do this by varying = the >>> size of slices (combinations of macro blocks). >>>=20 >>> Applicability of ARQ typically depends on observed end-to-end delay >>> and observed losses. The endpoint won't send a nack or a >>> retransmission if there are too many losses or if it thinks it won't >>> reach in time for decoding. >>=20 >> Yes - the choices are really: >> 1. add FEC for the more important packets >> 2. do ARQ when applicable for the more important packets >> 3. somehow tell the network about the more important packets (but = you can't, normally) >>=20 >> and there are trade-offs between these choices. I just wonder if we = need 3. as a part of the API to transport? >>=20 >=20 > when you say transport, you mean DSCP codepoint to indicate to the > middleboxes along the path or > an API from the codec to the transport (RTP/UDP) at the sending = endpoint? I was really only thinking aloud - but what I was thinking about was = indeed a DSCP codepoint that is set because the codec has told the = transport about it, in the API, defined by RMCAT. Cheers, Michael From bernard_aboba@hotmail.com Sat Oct 12 13:41:03 2013 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 5716221E80FA for ; Sat, 12 Oct 2013 13:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlIbEK92cIZg for ; Sat, 12 Oct 2013 13:40:58 -0700 (PDT) Received: from blu0-omc4-s3.blu0.hotmail.com (blu0-omc4-s3.blu0.hotmail.com [65.55.111.142]) by ietfa.amsl.com (Postfix) with ESMTP id A1FFC21E808E for ; Sat, 12 Oct 2013 13:40:58 -0700 (PDT) Received: from BLU169-W53 ([65.55.111.136]) by blu0-omc4-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Oct 2013 13:40:58 -0700 X-TMN: [7dWyMaibraoXbcYm1BLsWxBfFwLefoj5] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_15b90d36-66b7-41fe-9684-c72e71f51132_" From: Bernard Aboba To: Michael Welzl , Mirja Kuehlewind Date: Sat, 12 Oct 2013 13:40:58 -0700 Importance: Normal In-Reply-To: References: <201310101523.42971.mirja.kuehlewind@ikr.uni-stuttgart.de>, <201310111355.32264.mirja.kuehlewind@ikr.uni-stuttgart.de>, , <201310111619.02743.mirja.kuehlewind@ikr.uni-stuttgart.de>, MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2013 20:40:58.0887 (UTC) FILETIME=[5B718170:01CEC78B] Cc: rmcat WG Subject: Re: [rmcat] application interface X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 20:41:03 -0000 --_15b90d36-66b7-41fe-9684-c72e71f51132_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > One aspect is that there is the possibility of either doing FEC=2C as has= been brought up=2C or content-based ARQ in the application. What you choos= e=2C or how much of each you do=2C is a non-trivial design application ques= tion - I have advised a Ph.D. thesis on that=2C see: > http://heim.ifi.uio.no/michawe//research/students/michael_schier-diss_fin= al.pdf > I'm pointing to this thesis because I think that the video coding introdu= ction in this document is a very nice read - easy to understand=2C yet goin= g beyond what most "networkers" normally understand about video (I think). > Whether an application uses FEC or ARQ=2C such decisions are based on kno= wledge about the importance of parts of the media stream. This extends beyo= nd simply I- vs. P- vs. B-Frame=2C as each frame consists of metablocks and= blocks=2C of different types=2C with different dependencies... the importa= nce of a network packet can be derived at run-time=2C and if the transport = layer could make use of that information=2C then that would be a useful par= t of the API. [BA] I couldn't agree more. Indeed=2C the linkage between cc and video cod= ing is critical =0A= - particularly when dealing with simulcast and scalable video coding=2C wh= ich is becoming increasingly popular. This has important implications for = the congestion control (and circuit breaker) algorithms. Here is a refer= ence to one of the early papers on the subject (2006)=2C which=2C while aus= tensibly about streaming with SVC=2C has many aspects (such as a critique o= f TFRC drawbacks) that apply to interactive use as well:=20 http://www.zju.edu.cn/jzus/2006/A0605/A060510.htm = --_15b90d36-66b7-41fe-9684-c72e71f51132_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B One aspect is that there = is the possibility of either doing FEC=2C as has been brought up=2C or cont= ent-based ARQ in the application. What you choose=2C or how much of each yo= u do=2C is a non-trivial design application question - I have advised a Ph.= D. thesis on that=2C see:
>=3B http://heim.ifi.uio.no/michawe//re= search/students/michael_schier-diss_final.pdf
>=3B I'm pointing to thi= s thesis because I think that the video coding introduction in this documen= t is a very nice read - easy to understand=2C yet going beyond what most "n= etworkers" normally understand about video (I think).
>=3B Whether an = application uses FEC or ARQ=2C such decisions are based on knowledge about = the importance of parts of the media stream. This extends beyond simply I- = vs. P- vs. B-Frame=2C as each frame consists of metablocks and blocks=2C of= different types=2C with different dependencies... the importance of a netw= ork packet can be derived at run-time=2C and if the transport layer could m= ake use of that information=2C then that would be a useful part of the API.=

[BA] I couldn't agree more. =3B Indeed=2C the linkage between c= c and video coding is critical =0A= - =3B particularly when dealing with simulcast and scalable video codin= g=2C which is becoming increasingly popular. =3B This has important imp= lications for the congestion control =3B (and circuit breaker) algorith= ms.  =3B Here is a reference to one of the early papers on the subject = (2006)=2C which=2C while austensibly about streaming with SVC=2C has many a= spects (such as a critique of TFRC drawbacks) that apply to interactive use= as well:
http://www.zju.edu.cn/jzus/2006/A0605/A060510.htm


=
= --_15b90d36-66b7-41fe-9684-c72e71f51132_-- From bernard_aboba@hotmail.com Sat Oct 12 14:00:11 2013 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 D22CD21E8137; Sat, 12 Oct 2013 14:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5tbUqC4m0mr; Sat, 12 Oct 2013 14:00:06 -0700 (PDT) Received: from blu0-omc4-s2.blu0.hotmail.com (blu0-omc4-s2.blu0.hotmail.com [65.55.111.141]) by ietfa.amsl.com (Postfix) with ESMTP id B53CB21E81C3; Sat, 12 Oct 2013 14:00:05 -0700 (PDT) Received: from BLU169-W46 ([65.55.111.136]) by blu0-omc4-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Oct 2013 14:00:06 -0700 X-TMN: [8BLiVc2k5TxJTgeOO65mB6OqATvsFV+2] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c9a6c95a-89e3-4bad-bba3-de0589ac572d_" From: Bernard Aboba To: Michael Welzl , rmcat WG Date: Sat, 12 Oct 2013 14:00:05 -0700 Importance: Normal In-Reply-To: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2013 21:00:06.0587 (UTC) FILETIME=[0786A0B0:01CEC78E] Cc: "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 21:00:12 -0000 --_c9a6c95a-89e3-4bad-bba3-de0589ac572d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] A few points:=20 a. No B-frames in interactive uses=2C as others have said.=20 b. With SVC=2C you can apply FEC or RTX only to the base layer. So if the= re is loss in the base=2C you can recover. Loss in enhancement layers may = be "lived with" by dropping down to base frame rate/resolution/quality. So= not essential to apply FEC=2C RTX (or QoS) to enhancement layers=2C especi= ally since if there is high loss in enhancement layers a logical response i= s to stop sending them (duh).=20 Michael said:=20 > I'll begin by apologizing for asking what I'm quite sure is a terribly st= upid question to many of you. >=20 > The question is: >=20 > It has long been known that media data can have different levels of impor= tance. Simply put=2C if packet #1 from a single source contains parts of a = video's I-Frame and packet #2 contains only parts of B-Frames=2C and both e= nd up in the same queue=2C controlled by an AQM (for instance)=2C it would = be better for the video stream if packet #2 would be dropped rather than pa= cket #1. >=20 > There is nothing new with this story=3B it's not hard to find research pa= pers that document various variations of this theme=2C showing benefits in = video quality. >=20 > My question is=2C why is none of this happening? >=20 > Is it because DSCP values are typically associated with sources=2C and he= nce=2C marking packet #2 as "less" important would put the source at the ri= sk of having its packets less important than not only its own other packets= =2C but anybody else's? But there is equipment that does per-connection st= uff=2C and such things could probably better be done near the edges=2C wher= e the bottleneck typically is... so if that's the whole issue=2C we could d= efine DSCP values that mean relative importance *within the same five-tuple= only*. Surely that has been thought about and probably proposed by folks b= efore=2C so what happened? Why isn't it done? >=20 > Or is it because per-five-tuple-functionality in the network is regarded = as being too costly=2C and not encouraged=2C and hence not standardized? >=20 > I'm just trying to understand the reasons for this particular long-standi= ng difference between research an reality. >=20 > Cheers=2C > Michael >=20 = --_c9a6c95a-89e3-4bad-bba3-de0589ac572d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] A few points:

a. No= B-frames in interactive uses=2C as others =3B have said.
b. With S= VC=2C you can apply FEC or RTX only to the base layer. =3B =3B So i= f there is loss in the base=2C you can recover. =3B Loss in enhancement= layers may be "lived with" by dropping down to base frame rate/resolution/= quality. =3B So not essential to apply FEC=2C RTX (or QoS) to enhanceme= nt layers=2C especially since if there is high loss in enhancement layers a= logical response is to stop sending them (duh).



Michael sa= id:

>=3B I'll begin by apologizing for asking what I'm quite= sure is a terribly stupid question to many of you.
>=3B
>=3B Th= e question is:
>=3B
>=3B It has long been known that media data = can have different levels of importance. Simply put=2C if packet #1 from a = single source contains parts of a video's I-Frame and packet #2 contains on= ly parts of B-Frames=2C and both end up in the same queue=2C controlled by = an AQM (for instance)=2C it would be better for the video stream if packet = #2 would be dropped rather than packet #1.
>=3B
>=3B There is no= thing new with this story=3B it's not hard to find research papers that doc= ument various variations of this theme=2C showing benefits in video quality= .
>=3B
>=3B My question is=2C why is none of this happening?
= >=3B
>=3B Is it because DSCP values are typically associated with s= ources=2C and hence=2C marking packet #2 as "less" important would put the = source at the risk of having its packets less important than not only its o= wn other packets=2C but anybody else's? But there is equipment that does p= er-connection stuff=2C and such things could probably better be done near t= he edges=2C where the bottleneck typically is... so if that's the whole iss= ue=2C we could define DSCP values that mean relative importance *within the= same five-tuple only*. Surely that has been thought about and probably pro= posed by folks before=2C so what happened? Why isn't it done?
>=3B >=3B Or is it because per-five-tuple-functionality in the network is reg= arded as being too costly=2C and not encouraged=2C and hence not standardiz= ed?
>=3B
>=3B I'm just trying to understand the reasons for this= particular long-standing difference between research an reality.
>=3B=
>=3B Cheers=2C
>=3B Michael
>=3B
= --_c9a6c95a-89e3-4bad-bba3-de0589ac572d_-- From michawe@ifi.uio.no Sun Oct 13 01:01:46 2013 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 F156A21E80BB; Sun, 13 Oct 2013 01:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZhtp5qrTlSb; Sun, 13 Oct 2013 01:01:40 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 3917021E8088; Sun, 13 Oct 2013 01:01:38 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VVGcJ-0006IQ-Uj; Sun, 13 Oct 2013 10:01:35 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VVGcJ-0007Sw-9R; Sun, 13 Oct 2013 10:01:35 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_5703C864-91C5-4267-85E6-10BCBA20A217" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Sun, 13 Oct 2013 10:01:33 +0200 Message-Id: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> To: Bernard Aboba X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 8453 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 26BA31724B96B2B454720E293C2CA2F8047778A8 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 289 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 08:01:46 -0000 --Apple-Mail=_5703C864-91C5-4267-85E6-10BCBA20A217 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 12. okt. 2013, at 23:00, Bernard Aboba = wrote: > [BA] A few points:=20 >=20 > a. No B-frames in interactive uses, as others have said.=20 > b. With SVC, you can apply FEC or RTX only to the base layer. So if = there is loss in the base, you can recover. Loss in enhancement layers = may be "lived with" by dropping down to base frame = rate/resolution/quality. So not essential to apply FEC, RTX (or QoS) to = enhancement layers, especially since if there is high loss in = enhancement layers a logical response is to stop sending them (duh).=20 I see. Well, should we perhaps really suggest a = "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP then? Cheers, Michael >=20 >=20 >=20 > Michael said:=20 >=20 > > I'll begin by apologizing for asking what I'm quite sure is a = terribly stupid question to many of you. > >=20 > > The question is: > >=20 > > It has long been known that media data can have different levels of = importance. Simply put, if packet #1 from a single source contains parts = of a video's I-Frame and packet #2 contains only parts of B-Frames, and = both end up in the same queue, controlled by an AQM (for instance), it = would be better for the video stream if packet #2 would be dropped = rather than packet #1. > >=20 > > There is nothing new with this story; it's not hard to find research = papers that document various variations of this theme, showing benefits = in video quality. > >=20 > > My question is, why is none of this happening? > >=20 > > Is it because DSCP values are typically associated with sources, and = hence, marking packet #2 as "less" important would put the source at the = risk of having its packets less important than not only its own other = packets, but anybody else's? But there is equipment that does = per-connection stuff, and such things could probably better be done near = the edges, where the bottleneck typically is... so if that's the whole = issue, we could define DSCP values that mean relative importance *within = the same five-tuple only*. Surely that has been thought about and = probably proposed by folks before, so what happened? Why isn't it done? > >=20 > > Or is it because per-five-tuple-functionality in the network is = regarded as being too costly, and not encouraged, and hence not = standardized? > >=20 > > I'm just trying to understand the reasons for this particular = long-standing difference between research an reality. > >=20 > > Cheers, > > Michael > > --Apple-Mail=_5703C864-91C5-4267-85E6-10BCBA20A217 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 12. okt. 2013, = at 23:00, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

[BA] A few points: 

a. No B-frames in = interactive uses, as others  have said. 
b. With SVC, you can = apply FEC or RTX only to the base layer.   So if there is loss = in the base, you can recover.  Loss in enhancement layers may be = "lived with" by dropping down to base frame = rate/resolution/quality.  So not essential to apply FEC, RTX (or = QoS) to enhancement layers, especially since if there is high loss in = enhancement layers a logical response is to stop sending them = (duh). 
=

I see. Well, should we perhaps really suggest a = "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP = then?

Cheers,
Michael






Michael said: 

> I'll = begin by apologizing for asking what I'm quite sure is a terribly stupid = question to many of you.
> 
> The question = is:
> 
> = It has long been known that media data can have different levels of = importance. Simply put, if packet #1 from a single source contains parts = of a video's I-Frame and packet #2 contains only parts of B-Frames, and = both end up in the same queue, controlled by an AQM (for instance), it = would be better for the video stream if packet #2 would be dropped = rather than packet #1.
> 
> There is nothing = new with this story; it's not hard to find research papers that document = various variations of this theme, showing benefits in video = quality.
> 
> My question is, = why is none of this happening?
> 
> Is it because DSCP = values are typically associated with sources, and hence, marking packet = #2 as "less" important would put the source at the risk of having its = packets less important than not only its own other packets, but anybody = else's? But there is equipment that does per-connection stuff, and such = things could probably better be done near the edges, where the = bottleneck typically is... so if that's the whole issue, we could define = DSCP values that mean relative importance *within the same five-tuple = only*. Surely that has been thought about and probably proposed by folks = before, so what happened? Why isn't it done?
> 
> Or is it because = per-five-tuple-functionality in the network is regarded as being too = costly, and not encouraged, and hence not standardized?
> 
> I'm just trying to = understand the reasons for this particular long-standing difference = between research an reality.
> 
> Cheers,
> = Michael
>

= --Apple-Mail=_5703C864-91C5-4267-85E6-10BCBA20A217-- From kevin.gross@avanw.com Sun Oct 13 08:29:21 2013 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 57E1E11E8118 for ; Sun, 13 Oct 2013 08:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.269 X-Spam-Level: ** X-Spam-Status: No, score=2.269 tagged_above=-999 required=5 tests=[AWL=2.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjSLW8XcN1Hi for ; Sun, 13 Oct 2013 08:29:17 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id E472621F9C7D for ; Sun, 13 Oct 2013 08:29:16 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta12.emeryville.ca.mail.comcast.net with comcast id cfPZ1m0080S2fkC01fVGi6; Sun, 13 Oct 2013 15:29:16 +0000 Received: from mail-wi0-x235.google.com ([IPv6:2a00:1450:400c:c05::235]) by omta09.emeryville.ca.mail.comcast.net with comcast id cfVE1m0041BfBbM8VfVF8u; Sun, 13 Oct 2013 15:29:16 +0000 Received: by mail-wi0-f181.google.com with SMTP id l12so2589781wiv.14 for ; Sun, 13 Oct 2013 08:29:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Se526a/bcmv9L5i3gyd97caEWov4zqrk5e3fg9S0BaY=; b=QywR+cy/frAEyT3BXNjp+eDOAFcVen92Lb4KOjJIbm7aEZTxEfPYT8+qJyyRTZ0Pns QrA7ZdJdE4WMx06rC1dW6TuMdl3tGynywFQkfDnkUYJOy82cwzIziNkjMMs7HEELay4x ytwqwq5zphACfAtaH5KS1KIoq/5rOSVF444FG02Ld9RgbPIAxn2YM51ZrQaJhF1lMgqp OAkPjz4QvdfM1eW0HQpAh5M3tdaFqkAFjTRuLB6nWq/yf/sa177uOqt/qpZY9A7GspFm EQV/s9pwiBScPtn8Lk2tGbaaolj50TNfraxUNlZpMbRlou522zn/RxBhl9rca/qa2gmJ yUPw== MIME-Version: 1.0 X-Received: by 10.180.36.80 with SMTP id o16mr11163712wij.1.1381678153826; Sun, 13 Oct 2013 08:29:13 -0700 (PDT) Received: by 10.216.202.7 with HTTP; Sun, 13 Oct 2013 08:29:13 -0700 (PDT) In-Reply-To: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> Date: Sun, 13 Oct 2013 09:29:13 -0600 Message-ID: From: Kevin Gross To: Michael Welzl Content-Type: multipart/alternative; boundary=e89a8f50350e8d8e3a04e8a1031a DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381678156; bh=Se526a/bcmv9L5i3gyd97caEWov4zqrk5e3fg9S0BaY=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=mielM0fxZ5bLElJL6o0Cg7YwC7ufjLTj+oxOJw43QSnE983jheWMQLZpn/yrdYQez m3yLlwAd/RBS6VIZ/vhKUSu0YIySjLRJHrMcm8Zxw5TgatgMEIZ46IBePDPZwOP7Ao Wnd+Fb3jKSMtpRx8eLii9dYTRKS0zPfdj/8M1Jd/tLTlvg3UNRozweq8Z9ngz+eHhp /Qq88biCsN1LGwyM5O0liyJBdEoA+6eJYbPfziDpMoROHgDWnEVWtbIxloCsqKdBv7 +GWWJWzvqtlgYBPJFnibcDqAuZF0PmY9NhBVIVw/i8yVmjYQKjJsHRnOFWy0vw3TpH IDTie6M+6pI/A== Cc: Bernard Aboba , rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 15:29:21 -0000 --e89a8f50350e8d8e3a04e8a1031a Content-Type: text/plain; charset=ISO-8859-1 There have been mechanisms proposed or implemented to some extent in Ethernet, ATM and IP for indicating drop precedence (as opposed to class). These mechanisms are designed to solve exactly this problem. I'm not sure why this capability has, by and large, not been widely deployed. I think, for one, we network propeller-heads tend to overestimate the importance of QoS or at least the ability of application designers and IT personnel to get their heads around it well enough to be able to configure it so that it actually improves things. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com On Sun, Oct 13, 2013 at 2:01 AM, Michael Welzl wrote: > > On 12. okt. 2013, at 23:00, Bernard Aboba > wrote: > > [BA] A few points: > > a. No B-frames in interactive uses, as others have said. > b. With SVC, you can apply FEC or RTX only to the base layer. So if > there is loss in the base, you can recover. Loss in enhancement layers may > be "lived with" by dropping down to base frame rate/resolution/quality. So > not essential to apply FEC, RTX (or QoS) to enhancement layers, especially > since if there is high loss in enhancement layers a logical response is to > stop sending them (duh). > > > I see. Well, should we perhaps really suggest a > "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP then? > > Cheers, > Michael > > > > > > > Michael said: > > > I'll begin by apologizing for asking what I'm quite sure is a terribly > stupid question to many of you. > > > > The question is: > > > > It has long been known that media data can have different levels of > importance. Simply put, if packet #1 from a single source contains parts of > a video's I-Frame and packet #2 contains only parts of B-Frames, and both > end up in the same queue, controlled by an AQM (for instance), it would be > better for the video stream if packet #2 would be dropped rather than > packet #1. > > > > There is nothing new with this story; it's not hard to find research > papers that document various variations of this theme, showing benefits in > video quality. > > > > My question is, why is none of this happening? > > > > Is it because DSCP values are typically associated with sources, and > hence, marking packet #2 as "less" important would put the source at the > risk of having its packets less important than not only its own other > packets, but anybody else's? But there is equipment that does > per-connection stuff, and such things could probably better be done near > the edges, where the bottleneck typically is... so if that's the whole > issue, we could define DSCP values that mean relative importance *within > the same five-tuple only*. Surely that has been thought about and probably > proposed by folks before, so what happened? Why isn't it done? > > > > Or is it because per-five-tuple-functionality in the network is regarded > as being too costly, and not encouraged, and hence not standardized? > > > > I'm just trying to understand the reasons for this particular > long-standing difference between research an reality. > > > > Cheers, > > Michael > > > > > --e89a8f50350e8d8e3a04e8a1031a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There have been mechanisms proposed or implemented to some= extent in Ethernet, ATM and IP for indicating drop precedence (as opposed = to class). These mechanisms are designed to solve exactly this problem. I&#= 39;m not sure why this capability has, by and large, not been widely deploy= ed. I think, for one, we network propeller-heads tend to overestimate the i= mportance of QoS or at least the ability of application designers and IT pe= rsonnel to get their heads around it well enough to be able to configure it= so that it actually improves things.

Kevin Gr= oss
+1-303-447-0517
Media Network Consultant
AVA = Networks -=A0www.AVAnw.= com


On Sun, Oct 13, 2013 at 2:01 AM, Michael= Welzl <michawe@ifi.uio.no> wrote:

On 12. = okt. 2013, at 23:00, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
[BA] A few points:=A0

a. No B-frames i= n interactive uses, as others=A0 have said.=A0
b. With SVC,= you can apply FEC or RTX only to the base layer.=A0=A0 So if there is loss= in the base, you can recover.=A0 Loss in enhancement layers may be "l= ived with" by dropping down to base frame rate/resolution/quality.=A0 = So not essential to apply FEC, RTX (or QoS) to enhancement layers, especial= ly since if there is high loss in enhancement layers a logical response is = to stop sending them (duh).=A0

I see. Well, should we p= erhaps really suggest a "lower-priority-than-other-packets-in-the-same= -5-tuple" DSCP then?

Cheers,
Michae= l






Michael said:=A0

>= I'll begin by apologizing for asking what I'm quite sure is a terr= ibly stupid question to many of you.
>=A0
> The qu= estion is:
>=A0
> It has long been known that media data can hav= e different levels of importance. Simply put, if packet #1 from a single so= urce contains parts of a video's I-Frame and packet #2 contains only pa= rts of B-Frames, and both end up in the same queue, controlled by an AQM (f= or instance), it would be better for the video stream if packet #2 would be= dropped rather than packet #1.
>=A0
> There is nothing new with this story; it's= not hard to find research papers that document various variations of this = theme, showing benefits in video quality.
>=A0
> M= y question is, why is none of this happening?
>=A0
> Is it because DSCP values are typically associ= ated with sources, and hence, marking packet #2 as "less" importa= nt would put the source at the risk of having its packets less important th= an not only its own other packets, but anybody else's? But there is equ= ipment that does per-connection stuff, and such things could probably bette= r be done near the edges, where the bottleneck typically is... so if that&#= 39;s the whole issue, we could define DSCP values that mean relative import= ance *within the same five-tuple only*. Surely that has been thought about = and probably proposed by folks before, so what happened? Why isn't it d= one?
>=A0
> Or is it because per-five-tuple-functionality = in the network is regarded as being too costly, and not encouraged, and hen= ce not standardized?
>=A0
> I'm just trying to= understand the reasons for this particular long-standing difference betwee= n research an reality.
>=A0
> Cheers,
> Michael
>


--e89a8f50350e8d8e3a04e8a1031a-- From michawe@ifi.uio.no Sun Oct 13 09:28:43 2013 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 9483911E8163; Sun, 13 Oct 2013 09:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MBL8bNatoDa; Sun, 13 Oct 2013 09:28:38 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id F254211E8151; Sun, 13 Oct 2013 09:28:37 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VVOWx-0004vL-N1; Sun, 13 Oct 2013 18:28:35 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.104]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VVOWw-0003E6-RX; Sun, 13 Oct 2013 18:28:35 +0200 References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1B83CF31-F456-46CD-BCFF-EB98A4F07B7F Message-Id: X-Mailer: iPhone Mail (9B206) From: Michael Welzl Date: Sun, 13 Oct 2013 18:28:34 +0200 To: Kevin Gross X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 8460 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 21728D0FC4F17EA0F56CB0E4198F889B32D4DBAE X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 292 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: Bernard Aboba , rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 16:28:43 -0000 --Apple-Mail-1B83CF31-F456-46CD-BCFF-EB98A4F07B7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IP? with a clear "per-5-tuple-only" rule? Sent from my iPhone On 13. okt. 2013, at 17:29, Kevin Gross wrote: > There have been mechanisms proposed or implemented to some extent in Ether= net, ATM and IP for indicating drop precedence (as opposed to class). These m= echanisms are designed to solve exactly this problem. I'm not sure why this c= apability has, by and large, not been widely deployed. I think, for one, we n= etwork propeller-heads tend to overestimate the importance of QoS or at leas= t the ability of application designers and IT personnel to get their heads a= round it well enough to be able to configure it so that it actually improves= things. >=20 > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com >=20 >=20 > On Sun, Oct 13, 2013 at 2:01 AM, Michael Welzl wrote:= >=20 > On 12. okt. 2013, at 23:00, Bernard Aboba wrot= e: >=20 >> [BA] A few points:=20 >>=20 >> a. No B-frames in interactive uses, as others have said.=20 >> b. With SVC, you can apply FEC or RTX only to the base layer. So if the= re is loss in the base, you can recover. Loss in enhancement layers may be "= lived with" by dropping down to base frame rate/resolution/quality. So not e= ssential to apply FEC, RTX (or QoS) to enhancement layers, especially since i= f there is high loss in enhancement layers a logical response is to stop sen= ding them (duh).=20 >=20 > I see. Well, should we perhaps really suggest a "lower-priority-than-other= -packets-in-the-same-5-tuple" DSCP then? >=20 > Cheers, > Michael >=20 >=20 >=20 >>=20 >>=20 >>=20 >> Michael said:=20 >>=20 >> > I'll begin by apologizing for asking what I'm quite sure is a terribly s= tupid question to many of you. >> >=20 >> > The question is: >> >=20 >> > It has long been known that media data can have different levels of imp= ortance. Simply put, if packet #1 from a single source contains parts of a v= ideo's I-Frame and packet #2 contains only parts of B-Frames, and both end u= p in the same queue, controlled by an AQM (for instance), it would be better= for the video stream if packet #2 would be dropped rather than packet #1. >> >=20 >> > There is nothing new with this story; it's not hard to find research pa= pers that document various variations of this theme, showing benefits in vid= eo quality. >> >=20 >> > My question is, why is none of this happening? >> >=20 >> > Is it because DSCP values are typically associated with sources, and he= nce, marking packet #2 as "less" important would put the source at the risk o= f having its packets less important than not only its own other packets, but= anybody else's? But there is equipment that does per-connection stuff, and s= uch things could probably better be done near the edges, where the bottlenec= k typically is... so if that's the whole issue, we could define DSCP values t= hat mean relative importance *within the same five-tuple only*. Surely that h= as been thought about and probably proposed by folks before, so what happene= d? Why isn't it done? >> >=20 >> > Or is it because per-five-tuple-functionality in the network is regarde= d as being too costly, and not encouraged, and hence not standardized? >> >=20 >> > I'm just trying to understand the reasons for this particular long-stan= ding difference between research an reality. >> >=20 >> > Cheers, >> > Michael >> > >=20 >=20 --Apple-Mail-1B83CF31-F456-46CD-BCFF-EB98A4F07B7F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
IP? with a clear "per-5-tuple-only" rule?

Sent from my iPhone

On 13. okt. 2013, at 17:29, Kevin Gross <kevin.gross@avanw.com> wrote:

There have been mechanisms proposed or implemented to some extent in Ethernet, ATM and IP for indicating drop precedence (as opposed to class). These mechanisms are designed to solve exactly this problem. I'm not sure why this capability has, by and large, not been widely deployed. I think, for one, we network propeller-heads tend to overestimate the importance of QoS or at least the ability of application designers and IT personnel to get their heads around it well enough to be able to configure it so that it actually improves things.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com


On Sun, Oct 13, 2013 at 2:01 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

On 12. okt. 2013, at 23:00, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

[BA] A few points: 

a. No B-frames in interactive uses, as others  have said. 
b. With SVC, you can apply FEC or RTX only to the base layer.   So if there is loss in the base, you can recover.  Loss in enhancement layers may be "lived with" by dropping down to base frame rate/resolution/quality.  So not essential to apply FEC, RTX (or QoS) to enhancement layers, especially since if there is high loss in enhancement layers a logical response is to stop sending them (duh). 

I see. Well, should we perhaps really suggest a "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP then?

Cheers,
Michael






Michael said: 

> I'll begin by apologizing for asking what I'm quite sure is a terribly stupid question to many of you.
> 
> The question is:
> 
> It has long been known that media data can have different levels of importance. Simply put, if packet #1 from a single source contains parts of a video's I-Frame and packet #2 contains only parts of B-Frames, and both end up in the same queue, controlled by an AQM (for instance), it would be better for the video stream if packet #2 would be dropped rather than packet #1.
> 
> There is nothing new with this story; it's not hard to find research papers that document various variations of this theme, showing benefits in video quality.
> 
> My question is, why is none of this happening?
> 
> Is it because DSCP values are typically associated with sources, and hence, marking packet #2 as "less" important would put the source at the risk of having its packets less important than not only its own other packets, but anybody else's? But there is equipment that does per-connection stuff, and such things could probably better be done near the edges, where the bottleneck typically is... so if that's the whole issue, we could define DSCP values that mean relative importance *within the same five-tuple only*. Surely that has been thought about and probably proposed by folks before, so what happened? Why isn't it done?
> 
> Or is it because per-five-tuple-functionality in the network is regarded as being too costly, and not encouraged, and hence not standardized?
> 
> I'm just trying to understand the reasons for this particular long-standing difference between research an reality.
> 
> Cheers,
> Michael
>


--Apple-Mail-1B83CF31-F456-46CD-BCFF-EB98A4F07B7F-- From eckert@cisco.com Sun Oct 13 23:39:19 2013 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 433A521F9E3B; Sun, 13 Oct 2013 23:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.747 X-Spam-Level: X-Spam-Status: No, score=-6.747 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgzSlQz-zbDz; Sun, 13 Oct 2013 23:39:14 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0806B21F9A44; Sun, 13 Oct 2013 23:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5005; q=dns/txt; s=iport; t=1381732754; x=1382942354; h=date:from:to:cc:subject:message-id:mime-version; bh=gL7VOQGGt8nLCHbcwgBqTbp+kgerFaWi5glWU33LiWY=; b=WcfhHEq1BOku/NVGVYEG8oPzgJlLODZEaAJckNzsjKSnTAxXeZ6BU8DM QRs5qODs3xsfuzbLOxdgVxTN0HKppCgGSLmrTRCLJvbjbdvIdZLxn6DDN /Gy0Kon7tQPnTWaLvZdX0wOcl5ewHxBRJkucbqRQqFRg1fA2srM4bX63e c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAD+QW1KrRDoH/2dsb2JhbABZgwfCcYEaFnSCJQEBAT4xDhsOCgk0BUmIGL09j1KDJoEEA4k8jkgBkgKDRBw X-IronPort-AV: E=Sophos;i="4.93,490,1378857600"; d="scan'208";a="92085630" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 14 Oct 2013 06:39:12 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9E6dBKP016438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Oct 2013 06:39:12 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9E6dB0c002394; Sun, 13 Oct 2013 23:39:11 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9E6dB6q002392; Sun, 13 Oct 2013 23:39:11 -0700 Date: Sun, 13 Oct 2013 23:39:11 -0700 From: Toerless Eckert To: Michael Welzl Message-ID: <20131014063911.GA32524@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 06:39:19 -0000 High level answer: I think it has not been done so far because it is not that easy, and it requires both good thinking of how to do it from the video encoding expert and the network QoS experts. I think it would be great if video flows would give per-packet priority indications. I think most of the reasons brought up so far in this thread are no good reasons not to do it: - Even without B frames, different packets can have different prioties. I/LTR frames vs. P frames for example. Equally in SVC. - FEC is not free but costs quite a bit of overhead. And its not particularily well protecting against burst loss happening during burst collisions when new competing flows cause queue overrun. - Playout buffers in receiver apps can be quite large. STBs supposedly have 100 msec or more. So reordering of different priority packets should not be an issue. Even with low-delay video, the reordering that could happen in the network just means that some packets of the flow arrive earlier than expected under the contention conditions. Besides, you can also have different drop priorities without packet reordering within the same queue. In fact AF4x for example is defined to have that property (no packet reordering). IMHO, the issues why nothing has been done so far are rather: - There may not be enough well understood value analysis, eg: How well could network with differentiated drop policies effectively protect higher priority packets over lower priority packets. Yes, this is widely known at the class level, but not necessarily for packet distributions of different packets in the same flow. We've done some simulations on this that we could show that IMHO looked pretty good. - Why drop if you could do ECN plus rate-adaptive downspeeding. The answer is IMHO a bit more complex. In summary, i think priority dropping is good to deal with short term burst collisions and i think they can become quite likely for RMCAT. For dealing with ongoing congestion you obviously want downspeeding, and ongoing may be as short as maybe >= 2..10 seconds. If you do have priority based drop support in the network, i think that could fare better than ECN because it does resolve the burst collision as good as possibe in addition to a congestion notification. PCN of course would be best to have, in which case the window of applicability for priority dropping shrinks to less likely burst collisions. - How do you maximize the value of priority dropping in the video codec. Ideally you build your codec to have real discardable frames that are not predictor for other frames. But that as PSNR impacts. So this gets into the secret sauce of codecs. - How do you signal packet priority. DSCP is really ugly (TM). Besides, its really ugly to set from application (TM). An RTP header extension field would be IMHO much nicer. - How do you motivate codecs to indicate packet priorities if they have to fear that video flows with some packets marked "low priority" would ultimately see more packets dropped than flows without any "low priority" indications. For that we've got draft-lai-tsvwg-normalizer-02.txt Cheers Toerless On Sat, Oct 12, 2013 at 08:11:59AM +0200, Michael Welzl wrote: > Hi, > > I'll begin by apologizing for asking what I'm quite sure is a terribly stupid question to many of you. > > The question is: > > It has long been known that media data can have different levels of importance. Simply put, if packet #1 from a single source contains parts of a video's I-Frame and packet #2 contains only parts of B-Frames, and both end up in the same queue, controlled by an AQM (for instance), it would be better for the video stream if packet #2 would be dropped rather than packet #1. > > There is nothing new with this story; it's not hard to find research papers that document various variations of this theme, showing benefits in video quality. > > My question is, why is none of this happening? > > Is it because DSCP values are typically associated with sources, and hence, marking packet #2 as "less" important would put the source at the risk of having its packets less important than not only its own other packets, but anybody else's? But there is equipment that does per-connection stuff, and such things could probably better be done near the edges, where the bottleneck typically is... so if that's the whole issue, we could define DSCP values that mean relative importance *within the same five-tuple only*. Surely that has been thought about and probably proposed by folks before, so what happened? Why isn't it done? > > Or is it because per-five-tuple-functionality in the network is regarded as being too costly, and not encouraged, and hence not standardized? > > I'm just trying to understand the reasons for this particular long-standing difference between research an reality. > > Cheers, > Michael > From lars@netapp.com Mon Oct 14 02:44:13 2013 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 E8E8221F9654 for ; Mon, 14 Oct 2013 02:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.996 X-Spam-Level: X-Spam-Status: No, score=-8.996 tagged_above=-999 required=5 tests=[AWL=1.603, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXOmASzf42N6 for ; Mon, 14 Oct 2013 02:44:06 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2279221F9985 for ; Mon, 14 Oct 2013 02:42:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,491,1378882800"; d="asc'?scan'208";a="99988167" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 14 Oct 2013 02:42:08 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 02:42:08 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: draft-vanderauwera-rmcat-video-quality Thread-Index: AQHOyMGl+gLGCv2ZD0SP3S+Z7fqMDg== Date: Mon, 14 Oct 2013 09:42:07 +0000 Message-ID: <6F0A5342-E5EF-44DD-94C2-9EB97FFE3A07@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_96294E55-126A-4B9D-B85F-2BFA7ECE57EE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [rmcat] draft-vanderauwera-rmcat-video-quality X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 09:44:13 -0000 --Apple-Mail=_96294E55-126A-4B9D-B85F-2BFA7ECE57EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi WG, please see = http://trac.tools.ietf.org/html/draft-vanderauwera-rmcat-video-quality-00 = for a new ID describing quality test scenarios. Please discuss. Lars --Apple-Mail=_96294E55-126A-4B9D-B85F-2BFA7ECE57EE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUlu8btZcnpRveo1xAQL77wP9FOhwZBYs28rSqe8aaoorpxL6PNWF2ZDi GWY6eGqiZrZS/LNUQvTQFVilOND1n9YTSVfva5c+Bu2IzkGENgtwcyVrSfD1Ms23 dTncolfGJ8wJC59pj7oycDc6GPDAcvyId4fO9T283ic15kq0aQ4t8uyHwYmIokpA 4svInf0MGSA= =yCXu -----END PGP SIGNATURE----- --Apple-Mail=_96294E55-126A-4B9D-B85F-2BFA7ECE57EE-- From michawe@ifi.uio.no Mon Oct 14 04:17:42 2013 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 EF48C11E8127; Mon, 14 Oct 2013 04:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.826 X-Spam-Level: X-Spam-Status: No, score=-101.826 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awrqPS4xzxK4; Mon, 14 Oct 2013 04:17:26 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id AA99B11E8186; Mon, 14 Oct 2013 04:16:10 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VVg7Z-0007PF-Uu; Mon, 14 Oct 2013 13:15:33 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VVg7Z-0005AW-BW; Mon, 14 Oct 2013 13:15:33 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <20131014063911.GA32524@cisco.com> Date: Mon, 14 Oct 2013 13:15:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> References: <20131014063911.GA32524@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 8485 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 874065BFD50FD5654A75CBE16F11E4533480B0C2 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3318 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 11:17:43 -0000 Hi, That was a very interesting answer, thanks! Comments in line: On 14. okt. 2013, at 08:39, Toerless Eckert wrote: >=20 > High level answer: I think it has not been done so far because it is = not that > easy, and it requires both good thinking of how to do it from the = video encoding > expert and the network QoS experts.=20 >=20 > I think it would be great if video flows would give per-packet = priority > indications. I think most of the reasons brought up so far in this = thread are no good > reasons not to do it: I agree! > - Even without B frames, different packets can have different = prioties. I/LTR > frames vs. P frames for example. Equally in SVC. > - FEC is not free but costs quite a bit of overhead. And its not = particularily > well protecting against burst loss happening during burst collisions = when > new competing flows cause queue overrun. > - Playout buffers in receiver apps can be quite large. STBs supposedly = have > 100 msec or more. So reordering of different priority packets should = not > be an issue. Even with low-delay video, the reordering that could = happen > in the network just means that some packets of the flow arrive = earlier than > expected under the contention conditions. Besides, you can also have = different > drop priorities without packet reordering within the same queue. In = fact > AF4x for example is defined to have that property (no packet = reordering). >=20 > IMHO, the issues why nothing has been done so far are rather: >=20 > - There may not be enough well understood value analysis, eg: How well = could > network with differentiated drop policies effectively protect higher > priority packets over lower priority packets. Yes, this is widely = known at > the class level, but not necessarily for packet distributions of = different > packets in the same flow. We've done some simulations on this that we > could show that IMHO looked pretty good. At least to some degree, this must be a function of the queue length, I = think. The shorter your queue, the less likely it is that you see more = than one packet from the same source... if important packet #1 from = source X and unimportant packet #2 from source X are not in the same = queue together, you probably can't reasonably protect #1 from the impact = of #2. > - Why drop if you could do ECN plus rate-adaptive downspeeding. The = answer is=20 > IMHO a bit more complex. I agree. > In summary, i think priority dropping is good to > deal with short term burst collisions and i think they can become = quite likely > for RMCAT. For dealing with ongoing congestion you obviously want = downspeeding, > and ongoing may be as short as maybe >=3D 2..10 seconds. If you do = have > priority based drop support in the network, i think that could fare = better > than ECN because it does resolve the burst collision as good as = possibe > in addition to a congestion notification. PCN of course would be best = to have, > in which case the window of applicability for priority dropping = shrinks to > less likely burst collisions. >=20 > - How do you maximize the value of priority dropping in the video = codec. > Ideally you build your codec to have real discardable frames that are = not > predictor for other frames. But that as PSNR impacts. So this gets = into > the secret sauce of codecs. There, I think the answer can easily be found in multimedia literature. = There are many papers out there that evaluate such effects, e.g.: Michael Schier, Michael Welzl: "Selective Packet Discard in Mobile Video = Delivery based on Macroblock-Level Distortion Estimation", IEEE Infocom = MoVID 2009 workshop, 24 April 2009, Rio De Janeiro, Brazil. as only one example. > - How do you signal packet priority. DSCP is really ugly (TM). = Besides, its > really ugly to set from application (TM). An RTP header extension = field > would be IMHO much nicer. I agree that DSCP is ugly; I was thinking that one would have to even = reserve bits in DSCP because, despite different priorities *within* a = connection, one might still apply e.g. DiffServ to differentiate between = 5-tuples. Indeed, given that this is functionality that's only meant for = devices that identify 5-tuples, something above IP would make sense. So = I think I agree that an RTP header extension would be a good choice. > - How do you motivate codecs to indicate packet priorities if they = have to > fear that video flows with some packets marked "low priority" would > ultimately see more packets dropped than flows without any "low = priority" > indications. For that we've got draft-lai-tsvwg-normalizer-02.txt Well, but here we're talking about a marking that only means "relative = priority, within the same connection". So there shouldn't be any risk in = setting low priority, really. Cheers, Michael From eckert@cisco.com Mon Oct 14 07:37:31 2013 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 D3AB711E8189; Mon, 14 Oct 2013 07:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.673 X-Spam-Level: X-Spam-Status: No, score=-8.673 tagged_above=-999 required=5 tests=[AWL=1.926, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSFrnsSV2kEb; Mon, 14 Oct 2013 07:37:26 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A272A11E8147; Mon, 14 Oct 2013 07:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2040; q=dns/txt; s=iport; t=1381761446; x=1382971046; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=55KpbIiVIttTvybjx3lqz9Pf/IdvbgK/SpId/md947I=; b=mZflYBdojF70aTkQU2zMv6WddyKC/ySWhvaT5cx4UZ97DHQPD/tIE+IC vrdfErAwKPYKv0q9ys4fcWjNqSzt6E9yo+txAcvxkBs/LZxgSjpSZHEpx ANLamkJeCoMEdV5KFsPTEnoZDTt2+7grCK3e21wGqpcS5Om1pLORQMTkJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAHQAXFKrRDoJ/2dsb2JhbABZgwfCeYEkFnSCJQEBAQMBOj8FCwsOBAYJJQ8FNRQTiAAFvXmPUgeDH4EEA4k8jkgBkgKDRBw X-IronPort-AV: E=Sophos;i="4.93,492,1378857600"; d="scan'208";a="94685395" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 14 Oct 2013 14:37:24 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9EEbN7B026803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Oct 2013 14:37:23 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9EEbNrK023646; Mon, 14 Oct 2013 07:37:23 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9EEbNVr023645; Mon, 14 Oct 2013 07:37:23 -0700 Date: Mon, 14 Oct 2013 07:37:23 -0700 From: Toerless Eckert To: Michael Welzl Message-ID: <20131014143723.GB32524@cisco.com> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> User-Agent: Mutt/1.4.2.2i Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 14:37:32 -0000 On Mon, Oct 14, 2013 at 01:15:31PM +0200, Michael Welzl wrote: > At least to some degree, this must be a function of the queue length, I think. The shorter your queue, the less likely it is that you see more than one packet from the same source... if important packet #1 from source X and unimportant packet #2 from source X are not in the same queue together, you probably can't reasonably protect #1 from the impact of #2. Indeed. IN other words you need some number of multiplexed flows to effectively do intelligent dropping. I think this may be as low as 3..4 flows on a home-gateway, but the more, the better. > There, I think the answer can easily be found in multimedia literature. There are many papers out there that evaluate such effects, e.g.: > Michael Schier, Michael Welzl: "Selective Packet Discard in Mobile Video Delivery based on Macroblock-Level Distortion Estimation", IEEE Infocom MoVID 2009 workshop, 24 April 2009, Rio De Janeiro, Brazil. > as only one example. Thanks for the pointer. > > - How do you motivate codecs to indicate packet priorities if they have to > > fear that video flows with some packets marked "low priority" would > > ultimately see more packets dropped than flows without any "low priority" > > indications. For that we've got draft-lai-tsvwg-normalizer-02.txt > > Well, but here we're talking about a marking that only means "relative priority, within the same connection". So there shouldn't be any risk in setting low priority, really. But you need an intelligent dropping mechanism, and unless you would do a per-flow subqueue, you could not do relative dropping relative within the flow). And per-flow queuing is expensive. So our draft tries to explain a scheme that replaces per-floq queuing with per-flow priority remarking to allow dropping in a common queue. Cheers toerless > Cheers, > Michael > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Oct 14 07:46:57 2013 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 A4D5711E8199 for ; Mon, 14 Oct 2013 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVvrQ4yeLr+f for ; Mon, 14 Oct 2013 07:46:52 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6C111E81B4 for ; Mon, 14 Oct 2013 07:46:48 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 73CEE601DE for ; Mon, 14 Oct 2013 16:46:46 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 6E8EB601DD for ; Mon, 14 Oct 2013 16:46:46 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat@ietf.org Date: Mon, 14 Oct 2013 16:46:46 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201310141646.46179.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [rmcat] send agenda requests! X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 14:46:57 -0000 Hi again, please send agenda requests! We only have two requests so far. We have a 2.5h slot (WEDNESDAY, November 6, 1300-1530). Depending on how much more time is needed for the evaluation criteria discussion, we would appreciate to see further evaluation results of the proposed algorithms! Mirja From kevin.gross@avanw.com Mon Oct 14 14:37:23 2013 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 B208921E80F7 for ; Mon, 14 Oct 2013 14:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFDkLZ3neaLE for ; Mon, 14 Oct 2013 14:37:18 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE7C21E8089 for ; Mon, 14 Oct 2013 14:37:18 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta14.emeryville.ca.mail.comcast.net with comcast id d6NC1m0031afHeLAE9dJe7; Mon, 14 Oct 2013 21:37:18 +0000 Received: from mail-wg0-f49.google.com ([74.125.82.49]) by omta17.emeryville.ca.mail.comcast.net with comcast id d9bG1m00D13qyDW8d9bHz5; Mon, 14 Oct 2013 21:35:18 +0000 Received: by mail-wg0-f49.google.com with SMTP id x12so5053329wgg.28 for ; Mon, 14 Oct 2013 14:35:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zWsoENtQst9E1k/BseMfpeLEjNHtk42KCTS+lV4Dnac=; b=gTqLEaxrqVCA75e7xuY6mbD5etX4c8atwRnnIhigDY02iS+u5wja/Y1Awn49YXWYIt IATPOlX8Dv5OLCvVbjES8EkmwYHq0cTaiXftMr6D1ydXZo3p6mQIH7aXS2BbWnzGw+1s rFIxQ4dn871vx+zRvbMOegJxBp6gu56AbLwLJDuUKqznx5fOLKOz8rfxmQQXOvPjcid7 nWTIHe7l2KHsYW0mk2oOGNB6Jq4Ip56pIJcDE12mcdodyT2iNgwEdl4vtsMDrbG3vjXh 1O/NTQKX7FyvVYVYho39BdI//peC3byDYIOCtuewbMCUphTesuJrfCVVAcCAqUvdcZd8 s+Zg== MIME-Version: 1.0 X-Received: by 10.194.235.138 with SMTP id um10mr31566880wjc.30.1381786515518; Mon, 14 Oct 2013 14:35:15 -0700 (PDT) Received: by 10.216.202.7 with HTTP; Mon, 14 Oct 2013 14:35:15 -0700 (PDT) In-Reply-To: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> Date: Mon, 14 Oct 2013 15:35:15 -0600 Message-ID: From: Kevin Gross To: Michael Welzl Content-Type: multipart/alternative; boundary=089e01419acc69bc7804e8ba3e72 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381786638; bh=zWsoENtQst9E1k/BseMfpeLEjNHtk42KCTS+lV4Dnac=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=CSj4Kum7k7tuthumN7kFs7p6nBNqDCiXXjKo6Syer1FMl3VQw4MjQlQ0XP4sOXWMK OGimIwst/YJQGeM7Km2Lr9mlUXZDgngOfSnccElNdluImZNYQzoA6fs1L02hlg+220 /XrzqBsemxa35dK/mBM7qfqUqVSTADri7qe0lB1bIW+VrF8VfA11n9H5PQuoG0Qlsw mpH1drcG1YfLHu7C3JyKlp7inaAA+wG1p1443/24DiszG2oUuqHgpOFvcNNKeyW0ve b139VDQeX7Dv/X6DRgDhUPdfuFICeCqYH4ZbjFOOHMrjMCtiTT4J6nPWcPhOuBxpdD jQSlXjSvNUxXw== Cc: Bernard Aboba , rmcat WG Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 21:37:23 -0000 --089e01419acc69bc7804e8ba3e72 Content-Type: text/plain; charset=ISO-8859-1 No, not per 5 tuple (per flow). I don't think that is something we should ask of the network. It doesn't sit well with the end-to-end principle and it won't scale. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com On Sun, Oct 13, 2013 at 10:28 AM, Michael Welzl wrote: > IP? with a clear "per-5-tuple-only" rule? > > Sent from my iPhone > > On 13. okt. 2013, at 17:29, Kevin Gross wrote: > > There have been mechanisms proposed or implemented to some extent in > Ethernet, ATM and IP for indicating drop precedence (as opposed to class). > These mechanisms are designed to solve exactly this problem. I'm not sure > why this capability has, by and large, not been widely deployed. I think, > for one, we network propeller-heads tend to overestimate the importance of > QoS or at least the ability of application designers and IT personnel to > get their heads around it well enough to be able to configure it so that it > actually improves things. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com > > > On Sun, Oct 13, 2013 at 2:01 AM, Michael Welzl wrote: > >> >> On 12. okt. 2013, at 23:00, Bernard Aboba >> wrote: >> >> [BA] A few points: >> >> a. No B-frames in interactive uses, as others have said. >> b. With SVC, you can apply FEC or RTX only to the base layer. So if >> there is loss in the base, you can recover. Loss in enhancement layers may >> be "lived with" by dropping down to base frame rate/resolution/quality. So >> not essential to apply FEC, RTX (or QoS) to enhancement layers, especially >> since if there is high loss in enhancement layers a logical response is to >> stop sending them (duh). >> >> >> I see. Well, should we perhaps really suggest a >> "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP then? >> >> Cheers, >> Michael >> >> >> >> >> >> >> Michael said: >> >> > I'll begin by apologizing for asking what I'm quite sure is a terribly >> stupid question to many of you. >> > >> > The question is: >> > >> > It has long been known that media data can have different levels of >> importance. Simply put, if packet #1 from a single source contains parts of >> a video's I-Frame and packet #2 contains only parts of B-Frames, and both >> end up in the same queue, controlled by an AQM (for instance), it would be >> better for the video stream if packet #2 would be dropped rather than >> packet #1. >> > >> > There is nothing new with this story; it's not hard to find research >> papers that document various variations of this theme, showing benefits in >> video quality. >> > >> > My question is, why is none of this happening? >> > >> > Is it because DSCP values are typically associated with sources, and >> hence, marking packet #2 as "less" important would put the source at the >> risk of having its packets less important than not only its own other >> packets, but anybody else's? But there is equipment that does >> per-connection stuff, and such things could probably better be done near >> the edges, where the bottleneck typically is... so if that's the whole >> issue, we could define DSCP values that mean relative importance *within >> the same five-tuple only*. Surely that has been thought about and probably >> proposed by folks before, so what happened? Why isn't it done? >> > >> > Or is it because per-five-tuple-functionality in the network is >> regarded as being too costly, and not encouraged, and hence not >> standardized? >> > >> > I'm just trying to understand the reasons for this particular >> long-standing difference between research an reality. >> > >> > Cheers, >> > Michael >> > >> >> >> > --089e01419acc69bc7804e8ba3e72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No, not per 5 tuple (per flow). I don't think that is = something we should ask of the network. It doesn't sit well with the en= d-to-end principle and it won't scale.

Ke= vin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks -=A0www.= AVAnw.com


On Sun, Oct 13, 2013 at 10:28 AM, Michae= l Welzl <michawe@ifi.uio.no> wrote:
IP? with a clear "per-5-tuple-only"= rule?

Sent from my iPhone

On 1= 3. okt. 2013, at 17:29, Kevin Gross <kevin.gross@avanw.com> wrote:

There = have been mechanisms proposed or implemented to some extent in Ethernet, AT= M and IP for indicating drop precedence (as opposed to class). These mechan= isms are designed to solve exactly this problem. I'm not sure why this = capability has, by and large, not been widely deployed. I think, for one, w= e network propeller-heads tend to overestimate the importance of QoS or at = least the ability of application designers and IT personnel to get their he= ads around it well enough to be able to configure it so that it actually im= proves things.

Kevin Gr= oss
Media Network Consultant
= AVA Networks -=A0www.AV= Anw.com


On Sun, Oct 13, 2013 at 2:01 AM, Michael= Welzl <michawe@ifi.uio.no> wrote:

On 12. okt. 2013, at= 23:00, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

[BA] A few points:=A0

a. No B-frames i= n interactive uses, as others=A0 have said.=A0
b. With SVC,= you can apply FEC or RTX only to the base layer.=A0=A0 So if there is loss= in the base, you can recover.=A0 Loss in enhancement layers may be "l= ived with" by dropping down to base frame rate/resolution/quality.=A0 = So not essential to apply FEC, RTX (or QoS) to enhancement layers, especial= ly since if there is high loss in enhancement layers a logical response is = to stop sending them (duh).=A0

I see. Well, should we p= erhaps really suggest a "lower-priority-than-other-packets-in-the-same= -5-tuple" DSCP then?

Cheers,
Michae= l






Michael said:=A0

>= I'll begin by apologizing for asking what I'm quite sure is a terr= ibly stupid question to many of you.
>=A0
> The qu= estion is:
>=A0
> It has long been known that media data can hav= e different levels of importance. Simply put, if packet #1 from a single so= urce contains parts of a video's I-Frame and packet #2 contains only pa= rts of B-Frames, and both end up in the same queue, controlled by an AQM (f= or instance), it would be better for the video stream if packet #2 would be= dropped rather than packet #1.
>=A0
> There is nothing new with this story; it's= not hard to find research papers that document various variations of this = theme, showing benefits in video quality.
>=A0
> M= y question is, why is none of this happening?
>=A0
> Is it because DSCP values are typically associ= ated with sources, and hence, marking packet #2 as "less" importa= nt would put the source at the risk of having its packets less important th= an not only its own other packets, but anybody else's? But there is equ= ipment that does per-connection stuff, and such things could probably bette= r be done near the edges, where the bottleneck typically is... so if that&#= 39;s the whole issue, we could define DSCP values that mean relative import= ance *within the same five-tuple only*. Surely that has been thought about = and probably proposed by folks before, so what happened? Why isn't it d= one?
>=A0
> Or is it because per-five-tuple-functionality = in the network is regarded as being too costly, and not encouraged, and hen= ce not standardized?
>=A0
> I'm just trying to= understand the reasons for this particular long-standing difference betwee= n research an reality.
>=A0
> Cheers,
> Michael
>



--089e01419acc69bc7804e8ba3e72-- From slblake@petri-meat.com Mon Oct 14 17:58:33 2013 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 1A27121E8140; Mon, 14 Oct 2013 17:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oA7Geykdj-B; Mon, 14 Oct 2013 17:58:28 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id E46BD21E8100; Mon, 14 Oct 2013 17:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=petri-meat.com; s=default; h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID; bh=jeiA0k/5kh7lJbW63xgdv5j7YLChCLrvJ0cszlaBtSo=; b=N8pF99zmYT0i5PF+bJblEtHNrB4D9Ho4GH6RqX+VytrDaJeBb8dj9azciI1z4UU1hqS3dKzdSd9pMXtWqCuo2/f6YILoyTN6JHK/VzxnvtQYGecfWJzRbGQszWSNP7Tu; Received: from cpe-098-027-048-172.nc.res.rr.com ([98.27.48.172]:42817 helo=[192.168.144.50]) by elom.tchmachines.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VVsxo-0001Qq-L0; Mon, 14 Oct 2013 20:58:20 -0400 Message-ID: <1381798705.7804.22.camel@tachyon.blake> From: Steven Blake To: Michael Welzl Date: Mon, 14 Oct 2013 20:58:25 -0400 In-Reply-To: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Get-Message-Sender-Via: elom.tchmachines.com: authenticated_id: slblake+petri-meat.com/only user confirmed/virtual account not confirmed X-Mailman-Approved-At: Tue, 15 Oct 2013 00:17:49 -0700 Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 00:58:33 -0000 On Sat, 2013-10-12 at 08:11 +0200, Michael Welzl wrote: > Hi, > > I'll begin by apologizing for asking what I'm quite sure is a terribly > stupid question to many of you. > > The question is: > > It has long been known that media data can have different levels of > importance. Simply put, if packet #1 from a single source contains > parts of a video's I-Frame and packet #2 contains only parts of > B-Frames, and both end up in the same queue, controlled by an AQM (for > instance), it would be better for the video stream if packet #2 would > be dropped rather than packet #1. > > There is nothing new with this story; it's not hard to find research > papers that document various variations of this theme, showing > benefits in video quality. > > My question is, why is none of this happening? > > Is it because DSCP values are typically associated with sources, and > hence, marking packet #2 as "less" important would put the source at > the risk of having its packets less important than not only its own > other packets, but anybody else's? But there is equipment that does > per-connection stuff, and such things could probably better be done > near the edges, where the bottleneck typically is... so if that's the > whole issue, we could define DSCP values that mean relative importance > *within the same five-tuple only*. Surely that has been thought about > and probably proposed by folks before, so what happened? Why isn't it > done? > > Or is it because per-five-tuple-functionality in the network is > regarded as being too costly, and not encouraged, and hence not > standardized? > > I'm just trying to understand the reasons for this particular > long-standing difference between research an reality. The Assured Forwarding (AF) PHB group (RFC2597) was defined precisely to enable this drop-precedence-without-reordering-packets-within-a-flow behavior. In Diffserv jargon (RFC3260), an instance of an AF behavior aggregate (BA), e.g., AF11/AF12/AF13, would be an ordered aggregate (OA). Packets in a flow DSCP-encoded with either AF11/AF12/AF13 (for example) are guaranteed to be transmitted in the order received, but will have different drop precedences (AF11 highest; AF13 lowest). This is usually achieved by serving all packets on a port with the AF1* DSCP via the same FIFO queue. Regards, // Steve From michawe@ifi.uio.no Tue Oct 15 00:59:37 2013 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 D28CF21E81BA for ; Tue, 15 Oct 2013 00:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.675 X-Spam-Level: X-Spam-Status: No, score=-102.675 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeYgU73u9tAY for ; Tue, 15 Oct 2013 00:59:26 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 8234A21F9AD8 for ; Tue, 15 Oct 2013 00:59:12 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VVzX3-00062b-12; Tue, 15 Oct 2013 09:59:09 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VVzX2-0005yZ-Ib; Tue, 15 Oct 2013 09:59:08 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: Date: Tue, 15 Oct 2013 09:59:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> To: Kevin Gross X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 10 sum msgs/h 4 total rcpts 8550 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9D1CEC94D9538065B661E0AAC32F7AF4FBA6C19C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 3335 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: Bernard Aboba , rmcat WG Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 07:59:37 -0000 Hi, I'll dissect your second and third sentences and tell you what I think = about each part :-) below: On 14. okt. 2013, at 23:35, Kevin Gross wrote: > No, not per 5 tuple (per flow). I don't think that is something we = should ask of the network. I agree that asking this of the network may seem like encouraging = per-flow functionality; in particular, if we'd put this into IP, that = would be ugly. However, it's just a matter of fact that there are = devices that do identify flows, and then, why not give such devices some = guidance? I like Toerless' suggestion of making this an RTP header = extension field: if a device is identifying flows, we can expect such a = device to identify such a field too. Plus, if we think of end systems = playing an intermediate system role in RTP (mixers, ..), these devices = might also benefit from that sort of information. > It doesn't sit well with the end-to-end principle I disagree, this is an all-too-common misunderstanding of the end-to-end = principle: it only says that whatever can be done in the application = should be left up to the application, but it doesn't say that you = mustn't identify application streams inside the network or "keep the = network simple and stupid". If you do "keep the network stupid", you're = definitely in line with the e2e argument, but the argument isn't as = strict as that (a typical example is routing, which can well become as = complex as you wish, without harming the end-to-end principle). Now here = we're discussing a function where the application really can't help you: = when congestion happens inside the network and a packet must be dropped = there, the best the application can do is tell you which packet to drop. > and it won't scale. I agree. But it doesn't have to, just because we introduce the signal we = don't harm scalability - devices at the edges of the network could deal = with it, all other devices could ignore it. Cheers, Michael From michawe@ifi.uio.no Tue Oct 15 01:06:52 2013 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 1924121E8096; Tue, 15 Oct 2013 01:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdNiuvNUXc4f; Tue, 15 Oct 2013 01:06:47 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 6067021E8123; Tue, 15 Oct 2013 01:06:38 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VVzeE-0008CZ-3t; Tue, 15 Oct 2013 10:06:34 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VVzeD-0007kL-If; Tue, 15 Oct 2013 10:06:34 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DEA2E69B-FEA7-499E-8A21-0D65D3CDD50F" From: Michael Welzl In-Reply-To: <20131014143723.GB32524@cisco.com> Date: Tue, 15 Oct 2013 10:06:32 +0200 Message-Id: <289D7CCD-0C73-4596-B6F0-053202C46BA2@ifi.uio.no> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> <20131014143723.GB32524@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 8553 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EE6DEAECFF07644ED798B1FA7AC6CB9D679FBD27 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3336 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 08:06:52 -0000 --Apple-Mail=_DEA2E69B-FEA7-499E-8A21-0D65D3CDD50F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> - How do you motivate codecs to indicate packet priorities if they = have to >>> fear that video flows with some packets marked "low priority" would >>> ultimately see more packets dropped than flows without any "low = priority" >>> indications. For that we've got draft-lai-tsvwg-normalizer-02.txt >>=20 >> Well, but here we're talking about a marking that only means = "relative priority, within the same connection". So there shouldn't be = any risk in setting low priority, really. >=20 > But you need an intelligent dropping mechanism, and unless you would > do a per-flow subqueue, you could not do relative dropping relative = within > the flow). And per-flow queuing is expensive. So our draft tries to = explain a scheme > that replaces per-floq queuing with per-flow priority remarking to = allow > dropping in a common queue. So now I finally read = http://tools.ietf.org/html/draft-lai-tsvwg-normalizer and I must say I = like it a lot! It is indeed exactly what we need - but one issue with it = is compatibility. Actually this could become a show-stopper, as this is = all about getting the incentives right: why would my application ever = set a higher drop precedence for some packets when I don't know if this = normalizer is in place or not? And this decision would have to be taken = by the application... I could imagine a scenario where an application inserts the RTP = extension header that you mentioned, and then a flow-aware edge device = which knows that this traffic is going to traverse a path where your = normalization marker is in place marks packets into an AFx PHB group = based on the RTP extension header. Then we have an architecture that is = incentive-compatible AND scales. Cheers, Michael --Apple-Mail=_DEA2E69B-FEA7-499E-8A21-0D65D3CDD50F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
- How do you motivate codecs to = indicate packet priorities if they have = to
fear that video flows with some packets marked "low = priority" would
ultimately see more packets = dropped than flows without any "low = priority"
indications. For that we've got = draft-lai-tsvwg-normalizer-02.txt

Well, but here = we're talking about a marking that only means "relative priority, within = the same connection". So there shouldn't be any risk in setting low = priority, really.

But you need an intelligent = dropping mechanism, and unless you would
do a per-flow subqueue, you = could not do relative dropping relative within
the flow). And = per-flow queuing is expensive. So our draft tries to explain a = scheme
that replaces per-floq queuing with per-flow priority = remarking to allow
dropping in a common = queue.

So now I finally = read http://tool= s.ietf.org/html/draft-lai-tsvwg-normalizer and I must say I = like it a lot! It is indeed exactly what we need - but one issue with it = is compatibility. Actually this could become a show-stopper, as this is = all about getting the incentives right:  why would my application = ever set a higher drop precedence for some packets when I don't know if = this normalizer is in place or not? And this decision would have to be = taken by the application...

I could imagine a = scenario where an application inserts the RTP extension header that you = mentioned, and then a flow-aware edge device which knows that this = traffic is going to traverse a path where your normalization marker is = in place marks packets into an AFx PHB group based on the RTP extension = header. Then we have an architecture that is incentive-compatible AND = scales.

Cheers,
Michael

<= /div>= --Apple-Mail=_DEA2E69B-FEA7-499E-8A21-0D65D3CDD50F-- From michawe@ifi.uio.no Tue Oct 15 01:15:06 2013 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 D3DF511E812A; Tue, 15 Oct 2013 01:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwZcN16Iwhd6; Tue, 15 Oct 2013 01:15:00 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 802AB21F9FFF; Tue, 15 Oct 2013 01:14:48 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VVzmB-0002Tk-8x; Tue, 15 Oct 2013 10:14:47 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VVzmA-00066A-Bp; Tue, 15 Oct 2013 10:14:47 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_CB058D30-2927-4D5A-BBF1-1B50A1333569" From: Michael Welzl In-Reply-To: <1381798705.7804.22.camel@tachyon.blake> Date: Tue, 15 Oct 2013 10:14:45 +0200 Message-Id: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <1381798705.7804.22.camel@tachyon.blake> To: Steven Blake X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 8556 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 50EEE57544926CF9B7E36361B1D131A02BFFF810 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 3337 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 08:15:06 -0000 --Apple-Mail=_CB058D30-2927-4D5A-BBF1-1B50A1333569 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15. okt. 2013, at 02:58, Steven Blake wrote: > On Sat, 2013-10-12 at 08:11 +0200, Michael Welzl wrote: >=20 >> Hi, >>=20 >> I'll begin by apologizing for asking what I'm quite sure is a = terribly >> stupid question to many of you. >>=20 >> The question is: >>=20 >> It has long been known that media data can have different levels of >> importance. Simply put, if packet #1 from a single source contains >> parts of a video's I-Frame and packet #2 contains only parts of >> B-Frames, and both end up in the same queue, controlled by an AQM = (for >> instance), it would be better for the video stream if packet #2 would >> be dropped rather than packet #1. >>=20 >> There is nothing new with this story; it's not hard to find research >> papers that document various variations of this theme, showing >> benefits in video quality. >>=20 >> My question is, why is none of this happening? >>=20 >> Is it because DSCP values are typically associated with sources, and >> hence, marking packet #2 as "less" important would put the source at >> the risk of having its packets less important than not only its own >> other packets, but anybody else's? But there is equipment that does >> per-connection stuff, and such things could probably better be done >> near the edges, where the bottleneck typically is... so if that's the >> whole issue, we could define DSCP values that mean relative = importance >> *within the same five-tuple only*. Surely that has been thought about >> and probably proposed by folks before, so what happened? Why isn't it >> done? >>=20 >> Or is it because per-five-tuple-functionality in the network is >> regarded as being too costly, and not encouraged, and hence not >> standardized? >>=20 >> I'm just trying to understand the reasons for this particular >> long-standing difference between research an reality. >=20 > The Assured Forwarding (AF) PHB group (RFC2597) was defined precisely = to > enable this drop-precedence-without-reordering-packets-within-a-flow > behavior. In Diffserv jargon (RFC3260), an instance of an AF behavior > aggregate (BA), e.g., AF11/AF12/AF13, would be an ordered aggregate > (OA). Packets in a flow DSCP-encoded with either AF11/AF12/AF13 (for > example) are guaranteed to be transmitted in the order received, but > will have different drop precedences (AF11 highest; AF13 lowest). = This > is usually achieved by serving all packets on a port with the AF1* = DSCP > via the same FIFO queue. No, this is not what I mean. =46rom RFC2597: In a DS node, the level of forwarding assurance of an IP packet thus depends on (1) how much forwarding resources has been allocated to the AF class that the packet belongs to, (2) what is the current load of the AF class, and, in case of congestion within the class, (3) what is the drop precedence of the packet. So while AF PHB groups are indeed meant to address such per-flow drop = precedence, we still have a per-aggregate function, meaning that it's = risky business for an application to decide that some of its packets = have a higher drop precedence (it might put the application at a = disadvantage in comparison with other *users*). If you just look at page 4 of = http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 (Flow A vs. = Flow B) you'll see an example that explains exactly the problem I'm = talking about. Indeed I think that this draft suggests a nice solution, = but as long as an application doesn't know that the mechanism in this = draft is in place everywhere, the incentive for an application to assign = a higher drop precedence to some packets still isn't there. For how I think this could be solved, see my previous email to Toerless. Cheers, Michael --Apple-Mail=_CB058D30-2927-4D5A-BBF1-1B50A1333569 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Sat, 2013-10-12 at 08:11 +0200, Michael Welzl wrote:

Hi,

I'll begin by = apologizing for asking what I'm quite sure is a = terribly
stupid question to = many of you.

The question = is:

It has long been known that media data can have different = levels of
importance. Simply = put, if packet #1 from a single source = contains
parts of a video's = I-Frame and packet #2 contains only parts of
B-Frames, and both end up in the same queue, controlled by = an AQM (for
instance), it = would be better for the video stream if packet #2 = would
be dropped rather than = packet #1.

There is = nothing new with this story; it's not hard to find = research
papers that document = various variations of this theme, showing
benefits in video quality.

My question is, = why is none of this happening?

Is it because = DSCP values are typically associated with sources, = and
hence, marking packet #2 = as "less" important would put the source at
the risk of having its packets less important than not = only its own
other packets, = but anybody else's?  But there is equipment that = does
per-connection stuff, and = such things could probably better be done
near the edges, where the bottleneck typically is... so if = that's the
whole issue, we = could define DSCP values that mean relative = importance
*within the same = five-tuple only*. Surely that has been thought = about
and probably proposed by = folks before, so what happened? Why isn't it
done?

Or is it = because per-five-tuple-functionality in the network = is
regarded as being too = costly, and not encouraged, and hence not
standardized?

I'm just trying = to understand the reasons for this = particular
long-standing = difference between research an reality.

The Assured = Forwarding (AF) PHB group (RFC2597) was defined precisely to
enable = this = drop-precedence-without-reordering-packets-within-a-flow
behavior. =  In Diffserv jargon (RFC3260), an instance of an AF = behavior
aggregate (BA), e.g., AF11/AF12/AF13, would be an ordered = aggregate
(OA).  Packets in a flow DSCP-encoded with either = AF11/AF12/AF13 (for
example) are guaranteed to be transmitted in the = order received, but
will have different drop precedences (AF11 = highest; AF13 lowest).  This
is usually achieved by serving all = packets on a port with the AF1* DSCP
via the same FIFO = queue.

No, this is not what I = mean. =46rom RFC2597:

In a DS node, the = level of forwarding assurance of an IP packet thus
depends on = (1) how much forwarding resources has been allocated to
the AF = class that the packet belongs to, (2) what is the current = load
of the AF class, and, in case of congestion within the = class, (3)
what is the drop precedence of the = packet.

So while AF PHB groups are indeed = meant to address such per-flow drop precedence, we still have a = per-aggregate function, meaning that it's risky business for an = application to decide that some of its packets have a higher drop = precedence (it might put the application at a disadvantage in comparison = with other *users*).

If you just look at page 4 = of http://tool= s.ietf.org/html/draft-lai-tsvwg-normalizer-02 (Flow A vs. Flow = B) you'll see an example that explains exactly the problem I'm talking = about. Indeed I think that this draft suggests a nice solution, but as = long as an application doesn't know that the mechanism in this draft is = in place everywhere, the incentive for an application to assign a higher = drop precedence to some packets still isn't = there.

For how I think this could be solved, = see my previous email to = Toerless.

Cheers,
Michael

= --Apple-Mail=_CB058D30-2927-4D5A-BBF1-1B50A1333569-- From ingemar.s.johansson@ericsson.com Tue Oct 15 02:50:23 2013 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 A00E821E80BE for ; Tue, 15 Oct 2013 02:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmVJjU5qcWCd for ; Tue, 15 Oct 2013 02:50:18 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B5AF721E80AE for ; Tue, 15 Oct 2013 02:50:15 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-8f-525d0fd66cf9 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 58.EA.25272.6DF0D525; Tue, 15 Oct 2013 11:50:14 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.11]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 11:50:13 +0200 From: Ingemar Johansson S To: "geertv@qti.qualcomm.com" Thread-Topic: [rmcat] draft-vanderauwera-rmcat-video-quality Thread-Index: AQHOyRAqZZiBadU22UGKupfsfcenAJn1g/Tw Date: Tue, 15 Oct 2013 09:50:12 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA1C39A74E@ESESSMB205.ericsson.se> References: <6F0A5342-E5EF-44DD-94C2-9EB97FFE3A07@netapp.com> In-Reply-To: <6F0A5342-E5EF-44DD-94C2-9EB97FFE3A07@netapp.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre41/tggg09fxC3OHz/LZPHidQ+L xeqbH9gcmD2WLPnJ5DHj0xc2j0VTnzEGMEdx2aSk5mSWpRbp2yVwZfyYeI6pYC5bxbWTE1gb GNtYuxg5OSQETCQuPL7GCGGLSVy4t56ti5GLQ0jgKKPEjif/WSGcxYwS56+eB+tgE7CRWHno O1iHiIC5xOxnn4FsDg5mAXuJT//KQMLCAtYS62dNhSqxkfi6dyozhG0kcWvhTRaQchYBVYl9 c+xAwrwCvhLd/xeygdhCArYSP66cBbM5Bewk/i3cD7aVUUBW4v73eywgNrOAuMStJ/OZIG4W kFiy5zwzhC0q8fLxP6i/FCXanzYwQtTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJuFZOws JC2zkLTMQtKygJFlFSNHcWpxUm66kcEmRmDcHNzy22IH4+W/NocYpTlYlMR5P751DhISSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXAuOHE6evfLI3zNhnNajW+c186alp95MzWDT8Pf8srsnQM WGxxTUsk81702QQBZc1HEi3Ske//Loq2cnX8XF90XXz+g4jKGQ+OnPg/fcGjo9dfLlHctPuH IudknabUGKcGabsy88B1nKv4U2SVd5te+8CgrKHyQO9wXMXGK5/d1il8mO6s563/VImlOCPR UIu5qDgRAH0dT4RpAgAA Cc: rmcat WG , "Eggert, Lars" Subject: Re: [rmcat] draft-vanderauwera-rmcat-video-quality X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 09:50:24 -0000 Hi I have a question as regards to the size of the tail drop queue (32 packets= ). Given the bandwidth you end up with one way delays up to ~400ms when the= link is loaded with an FTP download. Is the 32 packet value given by some = typical hardware considerations ?.=20 Given the bandwidth delay product (1Mbps, RTT=3D2*10ms) it should be suffic= ient with a much lower queue size ? /Ingemar > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: den 14 oktober 2013 11:42 > To: rmcat WG > Subject: [rmcat] draft-vanderauwera-rmcat-video-quality >=20 > Hi WG, >=20 > please see http://trac.tools.ietf.org/html/draft-vanderauwera-rmcat-video= - > quality-00 for a new ID describing quality test scenarios. >=20 > Please discuss. >=20 > Lars From csp@csperkins.org Tue Oct 15 03:19:47 2013 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 E555D21F9B66; Tue, 15 Oct 2013 03:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuP8ZTDaSUOk; Tue, 15 Oct 2013 03:19:47 -0700 (PDT) Received: from balrog.mythic-beasts.com (outgoingbounces2.mythic-beasts.com [IPv6:2a00:1098:0:82:1000::13]) by ietfa.amsl.com (Postfix) with ESMTP id CF3F321F918C; Tue, 15 Oct 2013 03:19:43 -0700 (PDT) Received: from [130.209.247.112] (port=59203 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VW1iw-0004RJ-Ce; Tue, 15 Oct 2013 11:19:35 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> Date: Tue, 15 Oct 2013 11:19:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rmcat WG , Toerless Eckert , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 10:19:48 -0000 On 14 Oct 2013, at 12:15, Michael Welzl wrote: > On 14. okt. 2013, at 08:39, Toerless Eckert wrote: ... >> - How do you signal packet priority. DSCP is really ugly (TM). = Besides, its really ugly to set from application (TM). An RTP header = extension field would be IMHO much nicer. >=20 > I agree that DSCP is ugly; I was thinking that one would have to even = reserve bits in DSCP because, despite different priorities *within* a = connection, one might still apply e.g. DiffServ to differentiate between = 5-tuples. Indeed, given that this is functionality that's only meant for = devices that identify 5-tuples, something above IP would make sense. So = I think I agree that an RTP header extension would be a good choice. I strongly disagree. An RTP extension header is easy to add from the = application, but difficult to distinguish in the forwarding plane. The = semantics of the RTP header extension can only be inferred by looking at = the signalling channel (e.g., SIP, XMPP, WebRTC, etc.). I don't think we = want to tie the media path to the signalling path, nor should we require = routers to interact with the signalling protocol.=20 I also don't believe deep-packet inspection can usefully be used to find = the RTP header extension. Ignoring the layering violation, recall that = identifying RTP packets is difficult without keeping per-flow state, = that the header extension is at a variable offset into the RTP packet, = that multiple header extensions can be included in each RTP packet in an = arbitrary order, and that header extensions have a dynamically chosen = identifier mapped via the signalling channel with very little fixed text = to identify them. Plus, the RTP header extension may well be encrypted = if SRTP is used. Note also that RTCP, DTLS, or STUN packets are commonly multiplexed onto = the same 5-tuple, and don't have a corresponding header extension but = can use the DSCP field. I would assume we would want to be able to = assign a priority to those packets relative to the media.=20 If something in the UDP payload were considered appropriate to assign = per-packet priority, then I'd suggest that a shim-layer to identify = flows and priorities would be a better approach. That could add a couple = of bytes shim to each packet, to identify both flow priority and flow = type. This would also simplify some of the magic around demultiplexing = RTP, RTCP, STUN, DTLS, etc., that all get multiplexed onto the same port = in many applications. We proposed a shim to address the de-multiplexing = part of this in draft-westerlund-avtcore-transport-multiplexing-06, and = although it doesn't address the per-packet priority, it would be = straight forward to add if it were desirable, and (unlike an RTP header = extension) could place the priority field at a fixed location in the = packet, with a well-known header to help identify the flows. --=20 Colin Perkins http://csperkins.org/ From michawe@ifi.uio.no Tue Oct 15 03:49:05 2013 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 1C72C11E817D; Tue, 15 Oct 2013 03:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.663 X-Spam-Level: X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90T65D-l6yU6; Tue, 15 Oct 2013 03:48:57 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 23DD521F9A72; Tue, 15 Oct 2013 03:48:56 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VW2BK-0005eO-4m; Tue, 15 Oct 2013 12:48:54 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VW2BJ-0004cy-Jq; Tue, 15 Oct 2013 12:48:54 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> Date: Tue, 15 Oct 2013 12:48:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23D31735-B93C-42B8-A1F7-116CEC3B7EA8@ifi.uio.no> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 8564 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D91616F292896ED3354DC15FC8655800A793909F X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3342 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Toerless Eckert , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 10:49:07 -0000 On 15. okt. 2013, at 12:19, Colin Perkins wrote: > On 14 Oct 2013, at 12:15, Michael Welzl wrote: >> On 14. okt. 2013, at 08:39, Toerless Eckert wrote: > ... >>> - How do you signal packet priority. DSCP is really ugly (TM). = Besides, its really ugly to set from application (TM). An RTP header = extension field would be IMHO much nicer. >>=20 >> I agree that DSCP is ugly; I was thinking that one would have to even = reserve bits in DSCP because, despite different priorities *within* a = connection, one might still apply e.g. DiffServ to differentiate between = 5-tuples. Indeed, given that this is functionality that's only meant for = devices that identify 5-tuples, something above IP would make sense. So = I think I agree that an RTP header extension would be a good choice. >=20 >=20 > I strongly disagree. An RTP extension header is easy to add from the = application, but difficult to distinguish in the forwarding plane. The = semantics of the RTP header extension can only be inferred by looking at = the signalling channel (e.g., SIP, XMPP, WebRTC, etc.). I don't think we = want to tie the media path to the signalling path, nor should we require = routers to interact with the signalling protocol.=20 >=20 > I also don't believe deep-packet inspection can usefully be used to = find the RTP header extension. Ignoring the layering violation, recall = that identifying RTP packets is difficult without keeping per-flow = state, that the header extension is at a variable offset into the RTP = packet, that multiple header extensions can be included in each RTP = packet in an arbitrary order, and that header extensions have a = dynamically chosen identifier mapped via the signalling channel with = very little fixed text to identify them. Plus, the RTP header extension = may well be encrypted if SRTP is used. See, I don't know enough about RTP. Sorry... > Note also that RTCP, DTLS, or STUN packets are commonly multiplexed = onto the same 5-tuple, and don't have a corresponding header extension = but can use the DSCP field. I would assume we would want to be able to = assign a priority to those packets relative to the media.=20 >=20 > If something in the UDP payload were considered appropriate to assign = per-packet priority, then I'd suggest that a shim-layer to identify = flows and priorities would be a better approach. That could add a couple = of bytes shim to each packet, to identify both flow priority and flow = type. This would also simplify some of the magic around demultiplexing = RTP, RTCP, STUN, DTLS, etc., that all get multiplexed onto the same port = in many applications. We proposed a shim to address the de-multiplexing = part of this in draft-westerlund-avtcore-transport-multiplexing-06, and = although it doesn't address the per-packet priority, it would be = straight forward to add if it were desirable, and (unlike an RTP header = extension) could place the priority field at a fixed location in the = packet, with a well-known header to help identify the flows. All of that makes sense to me. Cheers, Michael From eckert@cisco.com Tue Oct 15 09:34:30 2013 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 07DBA21E8161; Tue, 15 Oct 2013 09:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.636 X-Spam-Level: X-Spam-Status: No, score=-9.636 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6BLlmNvPJVL; Tue, 15 Oct 2013 09:34:25 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C84D921E815F; Tue, 15 Oct 2013 09:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1371; q=dns/txt; s=iport; t=1381854863; x=1383064463; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=IJP634BLJeKiZWwC5Yv14Q+smsTtBHT1hPFuiX35rgw=; b=CLiinICfYJgI1vBk1SN8Zobcd+IlrGyjiDvwL/ekhzkMPivdG5JB2fbb qse10jMyvrolkw1pgHU3L0wp0aO4AynYeo6lO7SN3NpXLxD1TAKBjBUWE UjlyOQk2lZSpcFix+rTZ87+LRM0CuKscdOI0UIN8wuLki6j32mSZ+UZlo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAB1uXVKrRDoH/2dsb2JhbABagwc4wnuBIhZ0giUBAQEDATo/BQsLDgQGCSUPBTUUiBMFDb1Ij0oHgx+BBgOJPI5HAYEvkFODRBw X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208";a="94716435" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 15 Oct 2013 16:34:06 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FGY5Be013257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 16:34:05 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9FGY55U020920; Tue, 15 Oct 2013 09:34:05 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9FGY59v020919; Tue, 15 Oct 2013 09:34:05 -0700 Date: Tue, 15 Oct 2013 09:34:05 -0700 From: Toerless Eckert To: Michael Welzl Message-ID: <20131015163405.GA20478@cisco.com> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> <20131014143723.GB32524@cisco.com> <289D7CCD-0C73-4596-B6F0-053202C46BA2@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <289D7CCD-0C73-4596-B6F0-053202C46BA2@ifi.uio.no> User-Agent: Mutt/1.4.2.2i Cc: rmcat WG , "tsv-area@ietf.org" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 16:34:30 -0000 On Tue, Oct 15, 2013 at 10:06:32AM +0200, Michael Welzl wrote: > So now I finally read http://tools.ietf.org/html/draft-lai-tsvwg-normalizer and I must say I like it a lot! It is indeed exactly what we need - but one issue with it is compatibility. Actually this could become a show-stopper, as this is all about getting the incentives right: why would my application ever set a higher drop precedence for some packets when I don't know if this normalizer is in place or not? And this decision would have to be taken by the application... if we wouldn't try to stadardize this behavior with DSCP marking but only with RTP markings then that definition could also include the clear requirement that network devices MUST NOT interpret these markings in a way that would penalize a flow against other flows with no or differnt markings. Aka: clear state that these are intra-flow priority markings and must be interpreted by the network as such. > I could imagine a scenario where an application inserts the RTP extension header that you mentioned, and then a flow-aware edge device which knows that this traffic is going to traverse a path where your normalization marker is in place marks packets into an AFx PHB group based on the RTP extension header. Then we have an architecture that is incentive-compatible AND scales. Right. Cheers Toerless From kevin.gross@avanw.com Tue Oct 15 10:04:24 2013 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 0FF3211E8186 for ; Tue, 15 Oct 2013 10:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.227 X-Spam-Level: * X-Spam-Status: No, score=1.227 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uefpMTG0bS7k for ; Tue, 15 Oct 2013 10:04:19 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 78AC411E815A for ; Tue, 15 Oct 2013 10:04:19 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta14.westchester.pa.mail.comcast.net with comcast id dPvw1m0041YDfWL5EV4J0A; Tue, 15 Oct 2013 17:04:18 +0000 Received: from mail-we0-x234.google.com ([IPv6:2a00:1450:400c:c03::234]) by omta20.westchester.pa.mail.comcast.net with comcast id dV4H1m00i2f6EUc3gV4Ja7; Tue, 15 Oct 2013 17:04:18 +0000 Received: by mail-we0-f180.google.com with SMTP id q59so8946555wes.11 for ; Tue, 15 Oct 2013 10:04:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aIc+0tnSWuLYFkduWSahjrVpKLwy/PL47EbXQ/wAzcI=; b=Twb7dPTDfn4+Sc62utPCvJ+l4Hzw5d6lBIjwn2+thPH52V34DWMVZigNxUTfxqO15Z icE2xaoI8an4Nd+pNGCqy5AhHxeu7jw6W8dS/r4uiSZXusYAc2hh7zlbPA78gCJ7mG4f GqR/cWYFQIzO3lTVrkY7mDVkU598GSlM8Xf+OB/uTXqPDoyqHtj5Jh5kKXMQrmT4FsBK Bqg92ZAZLZ1Nd7xJwcRXE2gbuO0g0rkq4i8UcKlp2q551lkZ4uoKojlM8C9dOQRDg5a9 QdluEDJxINoJrFW9yfOZxb/0KAbf+uoJmD/R7IWJayWVE58iGyTyWcLdL63r8AvIinTR 7cGA== MIME-Version: 1.0 X-Received: by 10.194.122.99 with SMTP id lr3mr34476050wjb.21.1381856657440; Tue, 15 Oct 2013 10:04:17 -0700 (PDT) Received: by 10.216.202.7 with HTTP; Tue, 15 Oct 2013 10:04:17 -0700 (PDT) In-Reply-To: <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> Date: Tue, 15 Oct 2013 11:04:17 -0600 Message-ID: From: Kevin Gross To: Michael Welzl Content-Type: multipart/alternative; boundary=089e011779b532878b04e8ca93d7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381856658; bh=aIc+0tnSWuLYFkduWSahjrVpKLwy/PL47EbXQ/wAzcI=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=CsXxWmkUUTTPVC8tR5eNDZ0D/FqunOnbQvvag652EghqmfsUdPVCTa2hS4ty1Trnp nH3rYmQio54HzwdZpvLwrxYti7XxOawreieG7sTqCBIvumO/GC0VpLFCcAz2cY6yoj 5l0gXdTs46DNm6Jol+Of1/S+c772eEEUfbs8ZdmR6WBelom1rYk8ID+Ha4PUEvW8Rj pbf2nxyaMiZixijKLb/BMk8gi2DFaxBY++3Y3lotn748mJHpMief9FySco/KthRQpW 1rbhiJYiQNOMkeN84OHrv+fIXXJgQVMJZVzCfh/3xQOC87P52ik8axJSPc7TVZqXrI WYUo29rfoud4w== Cc: Bernard Aboba , rmcat WG Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 17:04:24 -0000 --089e011779b532878b04e8ca93d7 Content-Type: text/plain; charset=ISO-8859-1 I think you're stretching here. I don't think the balance is right. The proposed information is difficult to retrieve and of little use to much of the network. Even if standardized, it is unlikely to be successful. The ideas in the normalizer draft don't seem to have so many issues and I think it answers your original question and sets out to achieve what you're looking for. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl wrote: > Hi, > > I'll dissect your second and third sentences and tell you what I think > about each part :-) below: > > > On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > > No, not per 5 tuple (per flow). I don't think that is something we > should ask of the network. > > I agree that asking this of the network may seem like encouraging per-flow > functionality; in particular, if we'd put this into IP, that would be ugly. > However, it's just a matter of fact that there are devices that do identify > flows, and then, why not give such devices some guidance? I like Toerless' > suggestion of making this an RTP header extension field: if a device is > identifying flows, we can expect such a device to identify such a field > too. Plus, if we think of end systems playing an intermediate system role > in RTP (mixers, ..), these devices might also benefit from that sort of > information. > > > > It doesn't sit well with the end-to-end principle > > I disagree, this is an all-too-common misunderstanding of the end-to-end > principle: it only says that whatever can be done in the application should > be left up to the application, but it doesn't say that you mustn't identify > application streams inside the network or "keep the network simple and > stupid". If you do "keep the network stupid", you're definitely in line > with the e2e argument, but the argument isn't as strict as that (a typical > example is routing, which can well become as complex as you wish, without > harming the end-to-end principle). Now here we're discussing a function > where the application really can't help you: when congestion happens inside > the network and a packet must be dropped there, the best the application > can do is tell you which packet to drop. > > > > and it won't scale. > > I agree. But it doesn't have to, just because we introduce the signal we > don't harm scalability - devices at the edges of the network could deal > with it, all other devices could ignore it. > > Cheers, > Michael > > --089e011779b532878b04e8ca93d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think you're stretching here. I don't think the = balance is right. The proposed information is difficult to retrieve and of = little use to much of the network. Even if standardized, it is unlikely to = be successful.

The ideas in the normalizer draft don't seem to have so = many issues and I think it answers your original question and sets out to a= chieve what you're looking for.

Kevin Gross
+1-303-447-0517=
Media Network Consultant
AVA Networks -=A0www.AVAnw.com


On Tue, Oct 15, 2013 at 1:59 AM, Michael= Welzl <michawe@ifi.uio.no> wrote:
Hi,

I'll dissect your second and third sentences and tell you what I think = about each part =A0:-) =A0 below:


On 14. okt. 2013, at 23:35, Kevin Gross wrote:

> No, not per 5 tuple (per flow). I don't think that is something we= should ask of the network.

I agree that asking this of the network may seem like encouraging per= -flow functionality; in particular, if we'd put this into IP, that woul= d be ugly. However, it's just a matter of fact that there are devices t= hat do identify flows, and then, why not give such devices some guidance? = =A0I like Toerless' suggestion of making this an RTP header extension f= ield: if a device is identifying flows, we can expect such a device to iden= tify such a field too. Plus, if we think of end systems playing an intermed= iate system role in RTP (mixers, ..), these devices might also benefit from= that sort of information.


> It doesn't sit well with the end-to-end principle

I disagree, this is an all-too-common misunderstanding of the end-to-= end principle: it only says that whatever can be done in the application sh= ould be left up to the application, but it doesn't say that you mustn&#= 39;t identify application streams inside the network or "keep the netw= ork simple and stupid". If you do "keep the network stupid",= you're definitely in line with the e2e argument, but the argument isn&= #39;t as strict as that (a typical example is routing, which can well becom= e as complex as you wish, without harming the end-to-end principle). Now he= re we're discussing a function where the application really can't h= elp you: when congestion happens inside the network and a packet must be dr= opped there, the best the application can do is tell you which packet to dr= op.


> and it won't scale.

I agree. But it doesn't have to, just because we introduce the si= gnal we don't harm scalability - devices at the edges of the network co= uld deal with it, all other devices could ignore it.

Cheers,
Michael


--089e011779b532878b04e8ca93d7-- From eckert@cisco.com Tue Oct 15 10:33:50 2013 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 C53F411E8116; Tue, 15 Oct 2013 10:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.957 X-Spam-Level: X-Spam-Status: No, score=-9.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WurzQ9kvHrE; Tue, 15 Oct 2013 10:33:45 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C063911E81A1; Tue, 15 Oct 2013 10:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3666; q=dns/txt; s=iport; t=1381858423; x=1383068023; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ryLIBbWxtVnbGIzZcfqy4kRL89ocIZyxR5KL9VkrKpU=; b=FacFBjDL0j8t58CmZEd8IY9w1Rv4e4NGcz3wJHHzA4RZuxtPKSDOjxdR rPOrgn9l1Rk5Ot4AcXdDdhq0qlZLim3zSKwnsdlQcZzbSmLb/Qm7YboIP xb7jHrenfzpz/qHd2ZabWOJ8BoQqP+U08LYlbo7kPBp4OaCp/sT4wdv7w 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAG17XVKrRDoH/2dsb2JhbABQCoMHwzSBIxZ0giUBAQEDAScTPwULCw4KCSUPBUmIEwW9eI4HgUMHgx+BBgOJPIprg1wBkgKDRBw X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208";a="91489845" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 15 Oct 2013 17:33:42 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FHXfR2020838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 17:33:42 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9FHXfUg023299; Tue, 15 Oct 2013 10:33:41 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9FHXfYG023298; Tue, 15 Oct 2013 10:33:41 -0700 Date: Tue, 15 Oct 2013 10:33:41 -0700 From: Toerless Eckert To: Colin Perkins Message-ID: <20131015173341.GB20478@cisco.com> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> User-Agent: Mutt/1.4.2.2i Cc: rmcat WG , "tsv-area@ietf.org" , Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 17:33:50 -0000 On Tue, Oct 15, 2013 at 11:19:34AM +0100, Colin Perkins wrote: > I strongly disagree. An RTP extension header is easy to add from the application, but difficult to distinguish in the forwarding plane. The semantics of the RTP header extension can only be inferred by looking at the signalling channel (e.g., SIP, XMPP, WebRTC, etc.). I don't think we want to tie the media path to the signalling path, nor should we require routers to interact with the signalling protocol. Define RTP header extension with well-defined intra-flow priority field. Lets call it "Network-Signaling" RTP header extension. Might have other fields in it too beside priority (heck: even DSCP for poor apps that can't set it via their network stack ;-). Introduce new attribute to the STUN signaled metadata: draft-martinsen-mmusic-malice-00.txt. This attribute is signalled if the RTP packets on the 5-tuple have the network signaling RTP header extension, and its value is the ID of that RTP header extension. > I also don't believe deep-packet inspection can usefully be used to find the RTP header extension. Ignoring the layering violation, recall that identifying RTP packets is difficult without keeping per-flow state, that the header extension is at a variable offset into the RTP packet, that multiple header extensions can be included in each RTP packet in an arbitrary order, and that header extensions have a dynamically chosen identifier mapped via the signalling channel with very little fixed text to identify them. Plus, the RTP header extension may well be encrypted if SRTP is used. > > Note also that RTCP, DTLS, or STUN packets are commonly multiplexed onto the same 5-tuple, and don't have a corresponding header extension but can use the DSCP field. I would assume we would want to be able to assign a priority to those packets relative to the media. [Deleted rant about why we could not even design IPv6 so that useful new onpath header extensions could be placed in there ] I would hope the above proposed design answers those concerns of yours. -> Once the sender of the 5-tuple flow clear indicates to the network via STUN that the network-signaling header is present and what it's ID is, the routre/switches should have all they need. -> Obviously, the sender would not encrypt this paticular header as it specifically intends to signal its content to the network. -> Multiplexing should work fine because DPI in the network would use the sme simple rules to identify RTP vs. non-RTP packets in the flow, and then just find the RTP_header extension with the appropriate ID. > If something in the UDP payload were considered appropriate to assign per-packet priority, then I'd suggest that a shim-layer to identify flows and priorities would be a better approach. Sure. > That could add a couple of bytes shim to each packet, to identify both flow priority and flow type. This would also simplify some of the magic around demultiplexing RTP, RTCP, STUN, DTLS, etc., that all get multiplexed onto the same port in many applications. We proposed a shim to address the de-multiplexing part of this in draft-westerlund-avtcore-transport-multiplexing-06, and although it doesn't address the per-packet priority, it would be straight forward to add if it were desirable, and (unlike an RTP header extension) could place the priority field at a fixed location in the packet, with a well-known header to help identify the flows. I like shim layer, but in the end the design that will succeeed is the one that apps most likely will adopt. How likely would RTCweb use shim-layer ? Cheers Toerless From geertv@qti.qualcomm.com Tue Oct 15 11:50:57 2013 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 18EA511E8201 for ; Tue, 15 Oct 2013 11:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-uz+2alz7Zz for ; Tue, 15 Oct 2013 11:50:53 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7B411E81F4 for ; Tue, 15 Oct 2013 11:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1381863039; x=1413399039; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ve8fHIUU3l/xv8fAgdZHIwcWgvQuVevHcMaNcyw8UFg=; b=gxam7A3iU00SLWqnLvx5rC1clkgOfQ5pBwZF2eGM3bFwWDfhajuIlozB zsmqO5FdApt6RHjwYGegyDcfQcKggBhNqKMvYxcjhd5zwVKooiMOKclEM qwWuZQqq1yHXG7r359tDNwnK/PrQLeYzUgdsAHohh93Ko+xmfpZQrqH7H E=; X-IronPort-AV: E=McAfee;i="5400,1158,7229"; a="54244333" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 15 Oct 2013 11:50:29 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7229"; a="623185759" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Oct 2013 11:50:29 -0700 Received: from NASANEXD02B.na.qualcomm.com ([169.254.2.138]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 11:50:29 -0700 From: "Van Der Auwera, Geert" To: rmcat WG Thread-Topic: [rmcat] draft-vanderauwera-rmcat-video-quality Thread-Index: AQHOyMGl+gLGCv2ZD0SP3S+Z7fqMDpn1+7cAgAAB5TA= Date: Tue, 15 Oct 2013 18:50:28 +0000 Message-ID: <4FC1F85139E6FE4D9A55BD6798B29A4816AD20A5@NASANEXD02B.na.qualcomm.com> References: <6F0A5342-E5EF-44DD-94C2-9EB97FFE3A07@netapp.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39A74E@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA1C39A74E@ESESSMB205.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ingemar Johansson S , "Eggert, Lars" Subject: Re: [rmcat] draft-vanderauwera-rmcat-video-quality X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 18:50:57 -0000 Dear Ingemar, Thank you for your feedback. The queue size parameter in the test scenarios= can be defined smaller as you suggest to reduce delay. I based my estimate= on 1200 byte packets and 1Mbps, which results in a delay of ~300ms. There = are no particular hardware considerations for us, but I verified that for s= ome typical router the queue length can be configured between 0 and 4096 pa= ckets (default seems 75), for example. I would also like to use this opportunity to introduce the document by prov= iding the introduction here and hopefully have some discussions in the RMCA= T WG: "The impact of congestion control on media streams is important in real-wor= ld deployments. Therefore, the purpose of this evaluation is to verify or i= nspect the video quality of RMCAT congestion control solutions under differ= ent test scenarios. RMCAT based rate adaptations should result in expected = or desired video quality when implemented in a state-of-the-art video codin= g and communication framework. In other words, the purpose is to verify tha= t there are no unexpected or undesired video quality problems caused by con= gestion control behaviors, while the main purpose is not to directly compar= e RMCAT solutions against each other. It is proposed to perform such video = quality evaluation of candidate RMCAT solutions in addition to network traf= fic evaluations. An additional test scenario is proposed to evaluate the rate allocation beh= avior of RMCAT solutions when asymmetric flow conditions exist. In this tes= t the video quality is not evaluated." Best regards, Geert -----Original Message----- From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]=20 Sent: Tuesday, October 15, 2013 2:50 AM To: Van Der Auwera, Geert Cc: Eggert, Lars; rmcat WG Subject: RE: [rmcat] draft-vanderauwera-rmcat-video-quality Hi I have a question as regards to the size of the tail drop queue (32 packets= ). Given the bandwidth you end up with one way delays up to ~400ms when the= link is loaded with an FTP download. Is the 32 packet value given by some = typical hardware considerations ?.=20 Given the bandwidth delay product (1Mbps, RTT=3D2*10ms) it should be suffic= ient with a much lower queue size ? /Ingemar > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: den 14 oktober 2013 11:42 > To: rmcat WG > Subject: [rmcat] draft-vanderauwera-rmcat-video-quality >=20 > Hi WG, >=20 > please see http://trac.tools.ietf.org/html/draft-vanderauwera-rmcat-video= - > quality-00 for a new ID describing quality test scenarios. >=20 > Please discuss. >=20 > Lars From michawe@ifi.uio.no Tue Oct 15 13:44:05 2013 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 CB58521F84EF for ; Tue, 15 Oct 2013 13:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JmdFmO10LkO for ; Tue, 15 Oct 2013 13:44:00 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0121F8267 for ; Tue, 15 Oct 2013 13:43:56 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VWBT6-0005Gw-VI; Tue, 15 Oct 2013 22:43:52 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VWBT6-00050x-40; Tue, 15 Oct 2013 22:43:52 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_1EDCFBC3-29DC-48D0-9396-BC7C480718D8" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Tue, 15 Oct 2013 22:43:51 +0200 Message-Id: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> To: Kevin Gross X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 7 sum msgs/h 5 total rcpts 8604 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7D9FD914EEB23F04133503BA5A12917EEC774F5A X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 315 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: Bernard Aboba , rmcat WG Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 20:44:05 -0000 --Apple-Mail=_1EDCFBC3-29DC-48D0-9396-BC7C480718D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hmm. Whether the balance is right or not might depend on how the = signaling is done. Anyway, unless I misunderstood something, the way the = normalizer now stands it won't really make a change: it gives an = incentive to applications to mark some packets with higher drop = precedence, yet requires applications to know that the normalizer is in = place or else the service would be different. Maybe different DSCP values would be needed - but then this can't be = used in combination with "regular" DiffServ usage. It really depends on = the signaling - ideas are now being tossed around by Colin and Toerless, = who clearly both know more about what the right signaling could be than = me. Cheers, Michael On 15. okt. 2013, at 19:04, Kevin Gross wrote: > I think you're stretching here. I don't think the balance is right. = The proposed information is difficult to retrieve and of little use to = much of the network. Even if standardized, it is unlikely to be = successful. >=20 > The ideas in the normalizer draft don't seem to have so many issues = and I think it answers your original question and sets out to achieve = what you're looking for. >=20 > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com >=20 >=20 > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl = wrote: > Hi, >=20 > I'll dissect your second and third sentences and tell you what I think = about each part :-) below: >=20 >=20 > On 14. okt. 2013, at 23:35, Kevin Gross wrote: >=20 > > No, not per 5 tuple (per flow). I don't think that is something we = should ask of the network. >=20 > I agree that asking this of the network may seem like encouraging = per-flow functionality; in particular, if we'd put this into IP, that = would be ugly. However, it's just a matter of fact that there are = devices that do identify flows, and then, why not give such devices some = guidance? I like Toerless' suggestion of making this an RTP header = extension field: if a device is identifying flows, we can expect such a = device to identify such a field too. Plus, if we think of end systems = playing an intermediate system role in RTP (mixers, ..), these devices = might also benefit from that sort of information. >=20 >=20 > > It doesn't sit well with the end-to-end principle >=20 > I disagree, this is an all-too-common misunderstanding of the = end-to-end principle: it only says that whatever can be done in the = application should be left up to the application, but it doesn't say = that you mustn't identify application streams inside the network or = "keep the network simple and stupid". If you do "keep the network = stupid", you're definitely in line with the e2e argument, but the = argument isn't as strict as that (a typical example is routing, which = can well become as complex as you wish, without harming the end-to-end = principle). Now here we're discussing a function where the application = really can't help you: when congestion happens inside the network and a = packet must be dropped there, the best the application can do is tell = you which packet to drop. >=20 >=20 > > and it won't scale. >=20 > I agree. But it doesn't have to, just because we introduce the signal = we don't harm scalability - devices at the edges of the network could = deal with it, all other devices could ignore it. >=20 > Cheers, > Michael >=20 >=20 --Apple-Mail=_1EDCFBC3-29DC-48D0-9396-BC7C480718D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hmm. = Whether the balance is right or not might depend on how the signaling is = done. Anyway, unless I misunderstood something, the way the normalizer = now stands it won't really make a change: it gives an incentive to = applications to mark some packets with higher drop precedence, yet = requires applications to know that the normalizer is in place or else = the service would be different.

Maybe different DSCP = values would be needed - but then this can't be used in combination with = "regular" DiffServ usage. It really depends on the signaling - ideas are = now being tossed around by Colin and Toerless, who clearly both know = more about what the right signaling could be than = me.

Cheers,
Michael


On 15. okt. 2013, at 19:04, Kevin Gross <kevin.gross@avanw.com> = wrote:

I think you're stretching here. I don't = think the balance is right. The proposed information is difficult to = retrieve and of little use to much of the network. Even if standardized, = it is unlikely to be successful.

The ideas in the normalizer draft don't seem to have so = many issues and I think it answers your original question and sets out = to achieve what you're looking for.
=
Kevin = Gross
+1-303-447-0517
Media Network = Consultant
AVA Networks - www.AVAnw.com


On Tue, Oct 15, 2013 at 1:59 AM, = Michael Welzl <michawe@ifi.uio.no> = wrote:
Hi,

I'll dissect your second and third sentences and tell you what I think = about each part  :-)   below:


On 14. okt. 2013, at 23:35, Kevin Gross wrote:

> No, not per 5 tuple (per flow). I don't think that is something we = should ask of the network.

I agree that asking this of the network may seem like encouraging = per-flow functionality; in particular, if we'd put this into IP, that = would be ugly. However, it's just a matter of fact that there are = devices that do identify flows, and then, why not give such devices some = guidance?  I like Toerless' suggestion of making this an RTP header = extension field: if a device is identifying flows, we can expect such a = device to identify such a field too. Plus, if we think of end systems = playing an intermediate system role in RTP (mixers, ..), these devices = might also benefit from that sort of information.


> It doesn't sit well with the end-to-end principle

I disagree, this is an all-too-common misunderstanding of the = end-to-end principle: it only says that whatever can be done in the = application should be left up to the application, but it doesn't say = that you mustn't identify application streams inside the network or = "keep the network simple and stupid". If you do "keep the network = stupid", you're definitely in line with the e2e argument, but the = argument isn't as strict as that (a typical example is routing, which = can well become as complex as you wish, without harming the end-to-end = principle). Now here we're discussing a function where the application = really can't help you: when congestion happens inside the network and a = packet must be dropped there, the best the application can do is tell = you which packet to drop.


> and it won't scale.

I agree. But it doesn't have to, just because we introduce the = signal we don't harm scalability - devices at the edges of the network = could deal with it, all other devices could ignore it.

Cheers,
Michael



= --Apple-Mail=_1EDCFBC3-29DC-48D0-9396-BC7C480718D8-- From kevin.gross@avanw.com Tue Oct 15 15:45:31 2013 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 8EFDB21F8263 for ; Tue, 15 Oct 2013 15:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K8p+ZjHNzRw for ; Tue, 15 Oct 2013 15:45:27 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 6F65521F9951 for ; Tue, 15 Oct 2013 15:45:20 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id dXwt1m00w1GhbT857alDbr; Tue, 15 Oct 2013 22:45:13 +0000 Received: from mail-we0-x22b.google.com ([IPv6:2a00:1450:400c:c03::22b]) by omta07.westchester.pa.mail.comcast.net with comcast id dalC1m00a017m8o3TalCTr; Tue, 15 Oct 2013 22:45:13 +0000 Received: by mail-we0-f171.google.com with SMTP id t60so9343021wes.30 for ; Tue, 15 Oct 2013 15:45:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=25f/rcF9QHIRsESGfn0AGv5PjxCXiYWCfjPA2fJb13E=; b=J9GDBZH36wiYqiChDSwdBN4afSq+/hC27t2ccA3oCgFLhqX2bpxwGbEBsMUc7F4u6p Y7nExhGotd9s1hcNNH90mH+JG6L0r+p396guvGbXnjgsfgWU4ACFDV5LdUQatzhKoHUo UtHqqsyZ5LcK7AhnmMuV/oQiyXmFHn/Eqon3uByny4vN9m0EKsDYUOXwdcraHDoOda/H 07tx3CGTc1XR96mtNHb3W3vUUclIjD7tFBGu4ZyIPJtKh3bf6TQKd20ssO982jCXtY+M 9l95bmJVVvhRdf9enhtwBYgabjo2vt8EqElsBZJa1Kx3w7E3NXKfZh8b5Xe+lrW74SSo HaPg== MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr35851849wjc.7.1381877112021; Tue, 15 Oct 2013 15:45:12 -0700 (PDT) Received: by 10.216.202.7 with HTTP; Tue, 15 Oct 2013 15:45:11 -0700 (PDT) In-Reply-To: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> Date: Tue, 15 Oct 2013 16:45:11 -0600 Message-ID: From: Kevin Gross To: Michael Welzl Content-Type: multipart/alternative; boundary=089e0141a0ae62ab8404e8cf5604 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381877113; bh=25f/rcF9QHIRsESGfn0AGv5PjxCXiYWCfjPA2fJb13E=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=MizklX5j9tE1/qpxUm+sGm3iTEwanyU7QvMu2zebNOgIQ5Tir8I7++VequWq2rCP0 ywoYbifPb9L9axYRB5KIjFY3egpuOLUH6/HFFQOlXCoZrnkSmKle0zx6dueTSEPkRK EFdTnNKY+4J+7BTKKNxyuNLs79543Ow8Kro3VmKhAHUCQXYUhtG9J0T10aJ7kLxvbN 7z4xfiZpKSbYAVVu+oUzkdi4gHAV+/saJb9EqcRNk3QIYv9G8SiUG48i/wvqHGt8H5 1eJI+GbW8EeC/mjZoJFMBvFAavrTyNGuytwbW/GTvFunDWm/g+4y31DoP7/qUD3Vyw 7l8I0pva96Jtg== Cc: Bernard Aboba , rmcat WG Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 22:45:31 -0000 --089e0141a0ae62ab8404e8cf5604 Content-Type: text/plain; charset=ISO-8859-1 Maybe I skimmed it too quickly but my understanding is that the proposal is to remark DSCP values at the ingress point of the network and possibly at other key boundaries too. Such DSCP remapping is already common practice in enterprise networks. The twist here is that the remapper will do the remapping dynamically based on the proportion of AFn1, AFn2 and AFn3 packets received from a sender. A greedy sender that it producing only AF41 markings will get some of those randomly remarked as AF42 and AF43. The proposal uses existing DSCP values and it doesn't look like signaling is necessary nor is it necessary for the application to know that this is happening. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl wrote: > Hmm. Whether the balance is right or not might depend on how the signaling > is done. Anyway, unless I misunderstood something, the way the normalizer > now stands it won't really make a change: it gives an incentive to > applications to mark some packets with higher drop precedence, yet requires > applications to know that the normalizer is in place or else the service > would be different. > > Maybe different DSCP values would be needed - but then this can't be used > in combination with "regular" DiffServ usage. It really depends on the > signaling - ideas are now being tossed around by Colin and Toerless, who > clearly both know more about what the right signaling could be than me. > > Cheers, > Michael > > > On 15. okt. 2013, at 19:04, Kevin Gross wrote: > > I think you're stretching here. I don't think the balance is right. The > proposed information is difficult to retrieve and of little use to much of > the network. Even if standardized, it is unlikely to be successful. > > The ideas in the normalizer draft don't seem to have so many issues and I > think it answers your original question and sets out to achieve what you're > looking for. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl wrote: > >> Hi, >> >> I'll dissect your second and third sentences and tell you what I think >> about each part :-) below: >> >> >> On 14. okt. 2013, at 23:35, Kevin Gross wrote: >> >> > No, not per 5 tuple (per flow). I don't think that is something we >> should ask of the network. >> >> I agree that asking this of the network may seem like encouraging >> per-flow functionality; in particular, if we'd put this into IP, that would >> be ugly. However, it's just a matter of fact that there are devices that do >> identify flows, and then, why not give such devices some guidance? I like >> Toerless' suggestion of making this an RTP header extension field: if a >> device is identifying flows, we can expect such a device to identify such a >> field too. Plus, if we think of end systems playing an intermediate system >> role in RTP (mixers, ..), these devices might also benefit from that sort >> of information. >> >> >> > It doesn't sit well with the end-to-end principle >> >> I disagree, this is an all-too-common misunderstanding of the end-to-end >> principle: it only says that whatever can be done in the application should >> be left up to the application, but it doesn't say that you mustn't identify >> application streams inside the network or "keep the network simple and >> stupid". If you do "keep the network stupid", you're definitely in line >> with the e2e argument, but the argument isn't as strict as that (a typical >> example is routing, which can well become as complex as you wish, without >> harming the end-to-end principle). Now here we're discussing a function >> where the application really can't help you: when congestion happens inside >> the network and a packet must be dropped there, the best the application >> can do is tell you which packet to drop. >> >> >> > and it won't scale. >> >> I agree. But it doesn't have to, just because we introduce the signal we >> don't harm scalability - devices at the edges of the network could deal >> with it, all other devices could ignore it. >> >> Cheers, >> Michael >> >> > > --089e0141a0ae62ab8404e8cf5604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Maybe I skimmed it too quickly but my understanding is tha= t the proposal is to remark DSCP values at the ingress point of the network= and possibly at other key boundaries too. Such DSCP remapping is already c= ommon practice in enterprise networks.

The twist here is that the remapper will do the remapping dy= namically based on the proportion of AFn1, AFn2 and AFn3 packets received f= rom a sender. A greedy sender that it producing only AF41 markings will get= some of those randomly remarked as AF42 and AF43.

The proposal uses existing DSCP values and it doesn't lo= ok like signaling is necessary nor is it necessary for the application to k= now that this is happening.
Kevin Gross
+1-303-447-0517
Media N= etwork Consultant
AVA Networks -=A0www.AVAnw.com


On Tue, Oct 15, 2013 at 2:43 PM, Michael= Welzl <michawe@ifi.uio.no> wrote:
Hmm. Whether the balance is right or no= t might depend on how the signaling is done. Anyway, unless I misunderstood= something, the way the normalizer now stands it won't really make a ch= ange: it gives an incentive to applications to mark some packets with highe= r drop precedence, yet requires applications to know that the normalizer is= in place or else the service would be different.

Maybe different DSCP values would be needed - but then this = can't be used in combination with "regular" DiffServ usage. I= t really depends on the signaling - ideas are now being tossed around by Co= lin and Toerless, who clearly both know more about what the right signaling= could be than me.

Cheers,
Michael
<= div>

On 15. okt. 2013, at 19:04, Kevin Gross &l= t;kevin.gross@av= anw.com> wrote:

I think you're stretchin= g here. I don't think the balance is right. The proposed information is= difficult to retrieve and of little use to much of the network. Even if st= andardized, it is unlikely to be successful.

The ideas in the normalizer draft don't seem to have so = many issues and I think it answers your original question and sets out to a= chieve what you're looking for.

Kevin Gross
Media Network Consultant
AVA Networks -=A0www.AVAnw.com


On Tue, Oct 15, 2013 at 1:59 AM, Michael= Welzl <michawe@ifi.uio.no> wrote:
Hi,

I'll dissect your second and third sentences and tell you what I think = about each part =A0:-) =A0 below:


On 14. okt. 2013, at 23:35, Kevin Gross wrote:

> No, not per 5 tuple (per flow). I don't think that is something we= should ask of the network.

I agree that asking this of the network may seem like encouraging per= -flow functionality; in particular, if we'd put this into IP, that woul= d be ugly. However, it's just a matter of fact that there are devices t= hat do identify flows, and then, why not give such devices some guidance? = =A0I like Toerless' suggestion of making this an RTP header extension f= ield: if a device is identifying flows, we can expect such a device to iden= tify such a field too. Plus, if we think of end systems playing an intermed= iate system role in RTP (mixers, ..), these devices might also benefit from= that sort of information.


> It doesn't sit well with the end-to-end principle

I disagree, this is an all-too-common misunderstanding of the end-to-= end principle: it only says that whatever can be done in the application sh= ould be left up to the application, but it doesn't say that you mustn&#= 39;t identify application streams inside the network or "keep the netw= ork simple and stupid". If you do "keep the network stupid",= you're definitely in line with the e2e argument, but the argument isn&= #39;t as strict as that (a typical example is routing, which can well becom= e as complex as you wish, without harming the end-to-end principle). Now he= re we're discussing a function where the application really can't h= elp you: when congestion happens inside the network and a packet must be dr= opped there, the best the application can do is tell you which packet to dr= op.


> and it won't scale.

I agree. But it doesn't have to, just because we introduce the si= gnal we don't harm scalability - devices at the edges of the network co= uld deal with it, all other devices could ignore it.

Cheers,
Michael




--089e0141a0ae62ab8404e8cf5604-- From eckert@cisco.com Tue Oct 15 17:23:24 2013 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 95CE111E8230 for ; Tue, 15 Oct 2013 17:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.817 X-Spam-Level: X-Spam-Status: No, score=-9.817 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnOrMvQfoLOE for ; Tue, 15 Oct 2013 17:23:19 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC911E80F8 for ; Tue, 15 Oct 2013 17:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6029; q=dns/txt; s=iport; t=1381882995; x=1383092595; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HosO5LzBvs50pfbDuyPc+9uhHOM/NRNPwMU/n1bQF1Q=; b=Y8Gclv0jPZ0kcUdrEHuWqR1eIlGQBD2v66rrPGtkd2B8+0tFCzvqv4oG BMZU+JV6t3J82962hOTh3NKXaAOJe+Fcwhj/L8/NLNugNRDVKNN4WdOp4 4U7g3Hsfdto7MWeO8uceu58ADZ/5XHaqsm9yRyZdDQyqGt9UHEyGUi8AW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAH3bXVKrRDoG/2dsb2JhbABQBwODBzjCfIEjFnSCJQEBAQQOLA8cFBALBwsGCSUPBTUUExuHar4gjgeBMxAHEYMOgQYDiTyORwGSAoNEHA X-IronPort-AV: E=Sophos;i="4.93,503,1378857600"; d="scan'208";a="94809024" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 16 Oct 2013 00:23:04 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9G0N3kF023824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Oct 2013 00:23:04 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9G0N3OJ007757; Tue, 15 Oct 2013 17:23:03 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9G0N23e007755; Tue, 15 Oct 2013 17:23:02 -0700 Date: Tue, 15 Oct 2013 17:23:02 -0700 From: Toerless Eckert To: Kevin Gross Message-ID: <20131016002302.GC20478@cisco.com> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Bernard Aboba , rmcat WG , Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 00:23:24 -0000 The method described in the draft is applicable to whatever marking one wants to use. I wish DSCP was the solution because as you said it would avoid the need for figuring out how to carry a new marking (like RTP header extensions). But: There are no existing DSCP with the PHB of "intra-flow-priority" with a guarantee that flows with different distributions of those priorities would see the same percentage of drops under queue congestion. If we wanted to go the DSCP route, we would need at least 3 new DSCP to indicate high,normal,low intra-flow priority (and just for intelligent dropping, 3 actually might be good enough). But 3 new DSCP is an act of god in the IETF. Then those three new DSCP would not only have to indicate intra-flow priority but also the overall class PHB that the traffic should have even without priority indications. Aka: lets say low loss, low latency, appropriate for RMcat. So when the next class of traffic with different intra-flow priorities comes along, we'd have to redo the whole DSCP exercise again. And again. And then the DSCP still get reset along the path, and apps still have problems setting DSCP across various OSs. Cheers Toerless On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > Maybe I skimmed it too quickly but my understanding is that the proposal is > to remark DSCP values at the ingress point of the network and possibly at > other key boundaries too. Such DSCP remapping is already common practice in > enterprise networks. > > The twist here is that the remapper will do the remapping dynamically based > on the proportion of AFn1, AFn2 and AFn3 packets received from a sender. A > greedy sender that it producing only AF41 markings will get some of those > randomly remarked as AF42 and AF43. > > The proposal uses existing DSCP values and it doesn't look like signaling > is necessary nor is it necessary for the application to know that this is > happening. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com > > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl wrote: > > > Hmm. Whether the balance is right or not might depend on how the signaling > > is done. Anyway, unless I misunderstood something, the way the normalizer > > now stands it won't really make a change: it gives an incentive to > > applications to mark some packets with higher drop precedence, yet requires > > applications to know that the normalizer is in place or else the service > > would be different. > > > > Maybe different DSCP values would be needed - but then this can't be used > > in combination with "regular" DiffServ usage. It really depends on the > > signaling - ideas are now being tossed around by Colin and Toerless, who > > clearly both know more about what the right signaling could be than me. > > > > Cheers, > > Michael > > > > > > On 15. okt. 2013, at 19:04, Kevin Gross wrote: > > > > I think you're stretching here. I don't think the balance is right. The > > proposed information is difficult to retrieve and of little use to much of > > the network. Even if standardized, it is unlikely to be successful. > > > > The ideas in the normalizer draft don't seem to have so many issues and I > > think it answers your original question and sets out to achieve what you're > > looking for. > > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com > > > > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl wrote: > > > >> Hi, > >> > >> I'll dissect your second and third sentences and tell you what I think > >> about each part :-) below: > >> > >> > >> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > >> > >> > No, not per 5 tuple (per flow). I don't think that is something we > >> should ask of the network. > >> > >> I agree that asking this of the network may seem like encouraging > >> per-flow functionality; in particular, if we'd put this into IP, that would > >> be ugly. However, it's just a matter of fact that there are devices that do > >> identify flows, and then, why not give such devices some guidance? I like > >> Toerless' suggestion of making this an RTP header extension field: if a > >> device is identifying flows, we can expect such a device to identify such a > >> field too. Plus, if we think of end systems playing an intermediate system > >> role in RTP (mixers, ..), these devices might also benefit from that sort > >> of information. > >> > >> > >> > It doesn't sit well with the end-to-end principle > >> > >> I disagree, this is an all-too-common misunderstanding of the end-to-end > >> principle: it only says that whatever can be done in the application should > >> be left up to the application, but it doesn't say that you mustn't identify > >> application streams inside the network or "keep the network simple and > >> stupid". If you do "keep the network stupid", you're definitely in line > >> with the e2e argument, but the argument isn't as strict as that (a typical > >> example is routing, which can well become as complex as you wish, without > >> harming the end-to-end principle). Now here we're discussing a function > >> where the application really can't help you: when congestion happens inside > >> the network and a packet must be dropped there, the best the application > >> can do is tell you which packet to drop. > >> > >> > >> > and it won't scale. > >> > >> I agree. But it doesn't have to, just because we introduce the signal we > >> don't harm scalability - devices at the edges of the network could deal > >> with it, all other devices could ignore it. > >> > >> Cheers, > >> Michael > >> > >> > > > > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From kevin.gross@avanw.com Tue Oct 15 18:34:27 2013 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 DFF9711E8122 for ; Tue, 15 Oct 2013 18:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.18 X-Spam-Level: * X-Spam-Status: No, score=1.18 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pbLRTYfP3H8 for ; Tue, 15 Oct 2013 18:34:23 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id E6CCD21F9DF3 for ; Tue, 15 Oct 2013 18:34:20 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta15.westchester.pa.mail.comcast.net with comcast id dbFW1m0071ZXKqc5FdaLgN; Wed, 16 Oct 2013 01:34:20 +0000 Received: from mail-we0-x232.google.com ([IPv6:2a00:1450:400c:c03::232]) by omta21.westchester.pa.mail.comcast.net with comcast id ddaJ1m0121DPoGb3hdaKls; Wed, 16 Oct 2013 01:34:19 +0000 Received: by mail-we0-f178.google.com with SMTP id q59so69779wes.9 for ; Tue, 15 Oct 2013 18:34:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1SA3mMsi4Ebm0u6arf5byoZxW2gn8pFwFvHxpMoebvY=; b=NpY3K7XV1yXYQQPLv6GRAX20zFfgT4UKtXlOtWVwoP2MSjAC+hRU2Pv3lgMtLw7d1w PvAufqm+Q2CxNMbPV1DsQ3n1rO6RkMJKfSsaNlMgZf12xA7IJ0B92bdnCnCxUzMsWY17 hV+JBjt+HiR4MwD83oVacQpVKF2N+Us5UQsH94YJooKf5MT/nuzlirs9N/W1tfLH65J3 oRReXAlL2gbdHFt8PSNWyZw8NdLslCSf2GvVL6H6FB7c68a1K1BtiwDNxRabcivvcP0c GBor0gLoZ7BZ6HMsjYYoHl5Cqeoch+aEk+m5/lAXX4aJSXESlHgWGp9umWjQX2Rx4f/j Ynvg== MIME-Version: 1.0 X-Received: by 10.180.187.51 with SMTP id fp19mr22239448wic.1.1381887258575; Tue, 15 Oct 2013 18:34:18 -0700 (PDT) Received: by 10.216.202.7 with HTTP; Tue, 15 Oct 2013 18:34:18 -0700 (PDT) In-Reply-To: <20131016002302.GC20478@cisco.com> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> Date: Tue, 15 Oct 2013 19:34:18 -0600 Message-ID: From: Kevin Gross To: Toerless Eckert Content-Type: multipart/alternative; boundary=001a11c37ba22aceca04e8d1b334 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381887260; bh=1SA3mMsi4Ebm0u6arf5byoZxW2gn8pFwFvHxpMoebvY=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=j9NBFGeeabyQkkmwNjKkMcntWROExH4nMztNd46qvv9pwO3qPmqUW+tBnD0fEnQSo RzTZQNGfZqm5zuhjnPjtw65nq37JuGWz4YmVX+GucqLXqcsoUBdqHPsMT9GRosA2q2 pfI+KCdCviqhWd+CJTWTFoQ3g+U/5R0rz9Eya0Wavbr9Ry2nS1r4cuGN5pIpI4JKj6 Drwk+KeZTLdPN1wrwrNQxLRPYyeZd/b4ofkaplv+7QxJsArj6sxhaK66PxE2r2ytL0 PCMwHsoebXRQMBfviCx3u1ygpIUUjZL4LwDDcJAxxgSCGSMAmB9BgMgUvqQSMEsy1h tujfkiTR1ugVA== Cc: Bernard Aboba , rmcat WG , Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 01:34:28 -0000 --001a11c37ba22aceca04e8d1b334 Content-Type: text/plain; charset=ISO-8859-1 If we create a situation where all flows are "normalized" (i.e. a certain percentage of their packets are marked with higher drop precedence) by the network then we shouldn't have to deal with things on a per-flow basis. If we're not dealing with things on a per-flow basis, we can use the existing AF codepoints. Dropping according to drop precedence markings on a class basis should be statistically fair to all flows so long as all flows have been normalized. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com On Tue, Oct 15, 2013 at 6:23 PM, Toerless Eckert wrote: > The method described in the draft is applicable to whatever marking one > wants > to use. I wish DSCP was the solution because as you said it would avoid > the need > for figuring out how to carry a new marking (like RTP header extensions). > > But: There are no existing DSCP with the PHB of "intra-flow-priority" with > a > guarantee that flows with different distributions of those priorities > would see > the same percentage of drops under queue congestion. > > If we wanted to go the DSCP route, we would need at least 3 new DSCP to > indicate > high,normal,low intra-flow priority (and just for intelligent dropping, 3 > actually > might be good enough). But 3 new DSCP is an act of god in the IETF. > > Then those three new DSCP would not only have to indicate intra-flow > priority but > also the overall class PHB that the traffic should have even without > priority > indications. Aka: lets say low loss, low latency, appropriate for RMcat. > So when the next class of traffic with different intra-flow priorities > comes > along, we'd have to redo the whole DSCP exercise again. And again. > > And then the DSCP still get reset along the path, and apps still have > problems > setting DSCP across various OSs. > > Cheers > Toerless > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > Maybe I skimmed it too quickly but my understanding is that the proposal > is > > to remark DSCP values at the ingress point of the network and possibly at > > other key boundaries too. Such DSCP remapping is already common practice > in > > enterprise networks. > > > > The twist here is that the remapper will do the remapping dynamically > based > > on the proportion of AFn1, AFn2 and AFn3 packets received from a sender. > A > > greedy sender that it producing only AF41 markings will get some of those > > randomly remarked as AF42 and AF43. > > > > The proposal uses existing DSCP values and it doesn't look like signaling > > is necessary nor is it necessary for the application to know that this is > > happening. > > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com > > > > > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl > wrote: > > > > > Hmm. Whether the balance is right or not might depend on how the > signaling > > > is done. Anyway, unless I misunderstood something, the way the > normalizer > > > now stands it won't really make a change: it gives an incentive to > > > applications to mark some packets with higher drop precedence, yet > requires > > > applications to know that the normalizer is in place or else the > service > > > would be different. > > > > > > Maybe different DSCP values would be needed - but then this can't be > used > > > in combination with "regular" DiffServ usage. It really depends on the > > > signaling - ideas are now being tossed around by Colin and Toerless, > who > > > clearly both know more about what the right signaling could be than me. > > > > > > Cheers, > > > Michael > > > > > > > > > On 15. okt. 2013, at 19:04, Kevin Gross wrote: > > > > > > I think you're stretching here. I don't think the balance is right. The > > > proposed information is difficult to retrieve and of little use to > much of > > > the network. Even if standardized, it is unlikely to be successful. > > > > > > The ideas in the normalizer draft don't seem to have so many issues > and I > > > think it answers your original question and sets out to achieve what > you're > > > looking for. > > > > > > Kevin Gross > > > +1-303-447-0517 > > > Media Network Consultant > > > AVA Networks - www.AVAnw.com > > > > > > > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl > wrote: > > > > > >> Hi, > > >> > > >> I'll dissect your second and third sentences and tell you what I think > > >> about each part :-) below: > > >> > > >> > > >> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > >> > > >> > No, not per 5 tuple (per flow). I don't think that is something we > > >> should ask of the network. > > >> > > >> I agree that asking this of the network may seem like encouraging > > >> per-flow functionality; in particular, if we'd put this into IP, that > would > > >> be ugly. However, it's just a matter of fact that there are devices > that do > > >> identify flows, and then, why not give such devices some guidance? I > like > > >> Toerless' suggestion of making this an RTP header extension field: if > a > > >> device is identifying flows, we can expect such a device to identify > such a > > >> field too. Plus, if we think of end systems playing an intermediate > system > > >> role in RTP (mixers, ..), these devices might also benefit from that > sort > > >> of information. > > >> > > >> > > >> > It doesn't sit well with the end-to-end principle > > >> > > >> I disagree, this is an all-too-common misunderstanding of the > end-to-end > > >> principle: it only says that whatever can be done in the application > should > > >> be left up to the application, but it doesn't say that you mustn't > identify > > >> application streams inside the network or "keep the network simple and > > >> stupid". If you do "keep the network stupid", you're definitely in > line > > >> with the e2e argument, but the argument isn't as strict as that (a > typical > > >> example is routing, which can well become as complex as you wish, > without > > >> harming the end-to-end principle). Now here we're discussing a > function > > >> where the application really can't help you: when congestion happens > inside > > >> the network and a packet must be dropped there, the best the > application > > >> can do is tell you which packet to drop. > > >> > > >> > > >> > and it won't scale. > > >> > > >> I agree. But it doesn't have to, just because we introduce the signal > we > > >> don't harm scalability - devices at the edges of the network could > deal > > >> with it, all other devices could ignore it. > > >> > > >> Cheers, > > >> Michael > > >> > > >> > > > > > > > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > > --001a11c37ba22aceca04e8d1b334 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If we create a situation where all flows are "normali= zed" (i.e. a certain percentage of their packets are marked with highe= r drop precedence) by the network then we shouldn't have to deal with t= hings on a per-flow basis. If we're not dealing with things on a per-fl= ow basis, we can use the existing AF codepoints. Dropping according to drop= precedence markings on a class basis should be statistically fair to all f= lows so long as all flows have been normalized.

Kevin Gr= oss
+1-303-447-0517
Media Network Consultant
AVA = Networks -=A0www.AVAnw.= com


On Tue, Oct 15, 2013 at 6:23 PM, Toerles= s Eckert <eckert@cisco.com> wrote:
The method described in the draft is applicable to whatever marking one wan= ts
to use. I wish DSCP was the solution because as you said it would avoid the= need
for figuring out how to carry a new marking (like RTP header extensions).
But: There are no existing DSCP with the PHB of "intra-flow-priority&q= uot; with a
guarantee that flows with different distributions of those priorities would= see
the same percentage of drops under queue congestion.

If we wanted to go the DSCP route, we would need at least 3 new DSCP to ind= icate
high,normal,low intra-flow priority (and just for intelligent dropping, 3 a= ctually
might be good enough). But 3 new DSCP is an act of god in the IETF.

Then those three new DSCP would not only have to indicate intra-flow priori= ty but
also the overall class PHB that the traffic should have even without priori= ty
indications. Aka: lets say low loss, low latency, appropriate for RMcat. So when the next class of traffic with different intra-flow priorities come= s
along, we'd have to redo the whole DSCP exercise again. And again.

And then the DSCP still get reset along the path, and apps still have probl= ems
setting DSCP across various OSs.

Cheers
=A0 =A0 Toerless

On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote:
> Maybe I skimmed it too quickly but my understanding is that the propos= al is
> to remark DSCP values at the ingress point of the network and possibly= at
> other key boundaries too. Such DSCP remapping is already common practi= ce in
> enterprise networks.
>
> The twist here is that the remapper will do the remapping dynamically = based
> on the proportion of AFn1, AFn2 and AFn3 packets received from a sende= r. A
> greedy sender that it producing only AF41 markings will get some of th= ose
> randomly remarked as AF42 and AF43.
>
> The proposal uses existing DSCP values and it doesn't look like si= gnaling
> is necessary nor is it necessary for the application to know that this= is
> happening.
>
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>
>
>
> On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
>
> > Hmm. Whether the balance is right or not might depend on how the = signaling
> > is done. Anyway, unless I misunderstood something, the way the no= rmalizer
> > now stands it won't really make a change: it gives an incenti= ve to
> > applications to mark some packets with higher drop precedence, ye= t requires
> > applications to know that the normalizer is in place or else the = service
> > would be different.
> >
> > Maybe different DSCP values would be needed - but then this can&#= 39;t be used
> > in combination with "regular" DiffServ usage. It really= depends on the
> > signaling - ideas are now being tossed around by Colin and Toerle= ss, who
> > clearly both know more about what the right signaling could be th= an me.
> >
> > Cheers,
> > Michael
> >
> >
> > On 15. okt. 2013, at 19:04, Kevin Gross <kevin.gross@avanw.com> wrote:
> >
> > I think you're stretching here. I don't think the balance= is right. The
> > proposed information is difficult to retrieve and of little use t= o much of
> > the network. Even if standardized, it is unlikely to be successfu= l.
> >
> > The ideas in the normalizer draft don't seem to have so many = issues and I
> > think it answers your original question and sets out to achieve w= hat you're
> > looking for.
> >
> > Kevin Gross
> > +1-303-4= 47-0517
> > Media Network Consultant
> > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> >
> >
> > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
> >
> >> Hi,
> >>
> >> I'll dissect your second and third sentences and tell you= what I think
> >> about each part =A0:-) =A0 below:
> >>
> >>
> >> On 14. okt. 2013, at 23:35, Kevin Gross wrote:
> >>
> >> > No, not per 5 tuple (per flow). I don't think that i= s something we
> >> should ask of the network.
> >>
> >> I agree that asking this of the network may seem like encoura= ging
> >> per-flow functionality; in particular, if we'd put this i= nto IP, that would
> >> be ugly. However, it's just a matter of fact that there a= re devices that do
> >> identify flows, and then, why not give such devices some guid= ance? =A0I like
> >> Toerless' suggestion of making this an RTP header extensi= on field: if a
> >> device is identifying flows, we can expect such a device to i= dentify such a
> >> field too. Plus, if we think of end systems playing an interm= ediate system
> >> role in RTP (mixers, ..), these devices might also benefit fr= om that sort
> >> of information.
> >>
> >>
> >> > It doesn't sit well with the end-to-end principle > >>
> >> I disagree, this is an all-too-common misunderstanding of the= end-to-end
> >> principle: it only says that whatever can be done in the appl= ication should
> >> be left up to the application, but it doesn't say that yo= u mustn't identify
> >> application streams inside the network or "keep the netw= ork simple and
> >> stupid". If you do "keep the network stupid", = you're definitely in line
> >> with the e2e argument, but the argument isn't as strict a= s that (a typical
> >> example is routing, which can well become as complex as you w= ish, without
> >> harming the end-to-end principle). Now here we're discuss= ing a function
> >> where the application really can't help you: when congest= ion happens inside
> >> the network and a packet must be dropped there, the best the = application
> >> can do is tell you which packet to drop.
> >>
> >>
> >> > and it won't scale.
> >>
> >> I agree. But it doesn't have to, just because we introduc= e the signal we
> >> don't harm scalability - devices at the edges of the netw= ork could deal
> >> with it, all other devices could ignore it.
> >>
> >> Cheers,
> >> Michael
> >>
> >>
> >
> >

--
---
Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!


--001a11c37ba22aceca04e8d1b334-- From eckert@cisco.com Tue Oct 15 19:13:33 2013 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 6E93C11E8122 for ; Tue, 15 Oct 2013 19:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHkkKyBQOYS2 for ; Tue, 15 Oct 2013 19:13:28 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8739211E80FB for ; Tue, 15 Oct 2013 19:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8151; q=dns/txt; s=iport; t=1381889608; x=1383099208; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=BldBUgT7G0EWEVDZ/ueAgZSLOTtuH3V8/Q8ESBOYF24=; b=QjJanhBEsrYYfO5D9QdQ29fvz+f47Gsmfcc08+/9pz+tbmCSUKxjS+ZY sGWoSrXp1Z4ODMP5B5GSCKnC/yKf8OzThHma09/zfNY7z2lVSvft3Z9S4 FFJZW0EuQYEXc276mOSwDGuuzhrD8GBApSOHHkYAqgy0CrUMaC4ysQtUf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJr1XVKrRDoJ/2dsb2JhbABQBwODBzjDCIEoFnSCJQEBAQQOLA8cFBALBwsGCSUPBTUUExuHar4kjgeBMxAHEYMOgQYDiTyORwGSAoNEHA X-IronPort-AV: E=Sophos;i="4.93,504,1378857600"; d="scan'208";a="92241671" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 16 Oct 2013 02:13:26 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9G2DP2b027184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Oct 2013 02:13:25 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9G2DPIb013084; Tue, 15 Oct 2013 19:13:25 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9G2DOx6013083; Tue, 15 Oct 2013 19:13:24 -0700 Date: Tue, 15 Oct 2013 19:13:24 -0700 From: Toerless Eckert To: Kevin Gross Message-ID: <20131016021324.GA11683@cisco.com> References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Bernard Aboba , rmcat WG , Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 02:13:33 -0000 Partially true IMHO. Yes, if we could have all flows agree to have a marking let's say 20% high, 60% normal and 20% low prio bits (long term average), then we would not need normalization. If there is any chance to establish such a standard, that would be gret. It just doesn't change the problem of DSCP. It would change the PHB though by making it much more strict. Which makes it more questionable whether it would be accepted. Cheers Toerless On Tue, Oct 15, 2013 at 07:34:18PM -0600, Kevin Gross wrote: > If we create a situation where all flows are "normalized" (i.e. a certain > percentage of their packets are marked with higher drop precedence) by the > network then we shouldn't have to deal with things on a per-flow basis. If > we're not dealing with things on a per-flow basis, we can use the existing > AF codepoints. Dropping according to drop precedence markings on a class > basis should be statistically fair to all flows so long as all flows have > been normalized. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com > > > On Tue, Oct 15, 2013 at 6:23 PM, Toerless Eckert wrote: > > > The method described in the draft is applicable to whatever marking one > > wants > > to use. I wish DSCP was the solution because as you said it would avoid > > the need > > for figuring out how to carry a new marking (like RTP header extensions). > > > > But: There are no existing DSCP with the PHB of "intra-flow-priority" with > > a > > guarantee that flows with different distributions of those priorities > > would see > > the same percentage of drops under queue congestion. > > > > If we wanted to go the DSCP route, we would need at least 3 new DSCP to > > indicate > > high,normal,low intra-flow priority (and just for intelligent dropping, 3 > > actually > > might be good enough). But 3 new DSCP is an act of god in the IETF. > > > > Then those three new DSCP would not only have to indicate intra-flow > > priority but > > also the overall class PHB that the traffic should have even without > > priority > > indications. Aka: lets say low loss, low latency, appropriate for RMcat. > > So when the next class of traffic with different intra-flow priorities > > comes > > along, we'd have to redo the whole DSCP exercise again. And again. > > > > And then the DSCP still get reset along the path, and apps still have > > problems > > setting DSCP across various OSs. > > > > Cheers > > Toerless > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > > Maybe I skimmed it too quickly but my understanding is that the proposal > > is > > > to remark DSCP values at the ingress point of the network and possibly at > > > other key boundaries too. Such DSCP remapping is already common practice > > in > > > enterprise networks. > > > > > > The twist here is that the remapper will do the remapping dynamically > > based > > > on the proportion of AFn1, AFn2 and AFn3 packets received from a sender. > > A > > > greedy sender that it producing only AF41 markings will get some of those > > > randomly remarked as AF42 and AF43. > > > > > > The proposal uses existing DSCP values and it doesn't look like signaling > > > is necessary nor is it necessary for the application to know that this is > > > happening. > > > > > > Kevin Gross > > > +1-303-447-0517 > > > Media Network Consultant > > > AVA Networks - www.AVAnw.com > > > > > > > > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl > > wrote: > > > > > > > Hmm. Whether the balance is right or not might depend on how the > > signaling > > > > is done. Anyway, unless I misunderstood something, the way the > > normalizer > > > > now stands it won't really make a change: it gives an incentive to > > > > applications to mark some packets with higher drop precedence, yet > > requires > > > > applications to know that the normalizer is in place or else the > > service > > > > would be different. > > > > > > > > Maybe different DSCP values would be needed - but then this can't be > > used > > > > in combination with "regular" DiffServ usage. It really depends on the > > > > signaling - ideas are now being tossed around by Colin and Toerless, > > who > > > > clearly both know more about what the right signaling could be than me. > > > > > > > > Cheers, > > > > Michael > > > > > > > > > > > > On 15. okt. 2013, at 19:04, Kevin Gross wrote: > > > > > > > > I think you're stretching here. I don't think the balance is right. The > > > > proposed information is difficult to retrieve and of little use to > > much of > > > > the network. Even if standardized, it is unlikely to be successful. > > > > > > > > The ideas in the normalizer draft don't seem to have so many issues > > and I > > > > think it answers your original question and sets out to achieve what > > you're > > > > looking for. > > > > > > > > Kevin Gross > > > > +1-303-447-0517 > > > > Media Network Consultant > > > > AVA Networks - www.AVAnw.com > > > > > > > > > > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl > > wrote: > > > > > > > >> Hi, > > > >> > > > >> I'll dissect your second and third sentences and tell you what I think > > > >> about each part :-) below: > > > >> > > > >> > > > >> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > > >> > > > >> > No, not per 5 tuple (per flow). I don't think that is something we > > > >> should ask of the network. > > > >> > > > >> I agree that asking this of the network may seem like encouraging > > > >> per-flow functionality; in particular, if we'd put this into IP, that > > would > > > >> be ugly. However, it's just a matter of fact that there are devices > > that do > > > >> identify flows, and then, why not give such devices some guidance? I > > like > > > >> Toerless' suggestion of making this an RTP header extension field: if > > a > > > >> device is identifying flows, we can expect such a device to identify > > such a > > > >> field too. Plus, if we think of end systems playing an intermediate > > system > > > >> role in RTP (mixers, ..), these devices might also benefit from that > > sort > > > >> of information. > > > >> > > > >> > > > >> > It doesn't sit well with the end-to-end principle > > > >> > > > >> I disagree, this is an all-too-common misunderstanding of the > > end-to-end > > > >> principle: it only says that whatever can be done in the application > > should > > > >> be left up to the application, but it doesn't say that you mustn't > > identify > > > >> application streams inside the network or "keep the network simple and > > > >> stupid". If you do "keep the network stupid", you're definitely in > > line > > > >> with the e2e argument, but the argument isn't as strict as that (a > > typical > > > >> example is routing, which can well become as complex as you wish, > > without > > > >> harming the end-to-end principle). Now here we're discussing a > > function > > > >> where the application really can't help you: when congestion happens > > inside > > > >> the network and a packet must be dropped there, the best the > > application > > > >> can do is tell you which packet to drop. > > > >> > > > >> > > > >> > and it won't scale. > > > >> > > > >> I agree. But it doesn't have to, just because we introduce the signal > > we > > > >> don't harm scalability - devices at the edges of the network could > > deal > > > >> with it, all other devices could ignore it. > > > >> > > > >> Cheers, > > > >> Michael > > > >> > > > >> > > > > > > > > > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > Cisco NSSTG Systems & Technology Architecture > > SDN: Let me play with the network, mommy! > > > > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From kevin.gross@avanw.com Tue Oct 15 20:32:01 2013 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 27F8911E8105 for ; Tue, 15 Oct 2013 20:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.124 X-Spam-Level: * X-Spam-Status: No, score=1.124 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGZRAHRpRww3 for ; Tue, 15 Oct 2013 20:31:56 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id A71E111E816B for ; Tue, 15 Oct 2013 20:31:56 -0700 (PDT) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta01.emeryville.ca.mail.comcast.net with comcast id dfRs1m0021vN32cA1fXwPf; Wed, 16 Oct 2013 03:31:56 +0000 Received: from mail-ob0-x233.google.com ([IPv6:2607:f8b0:4003:c01::233]) by omta22.emeryville.ca.mail.comcast.net with comcast id dfXv1m00E3E9SZX8ifXvfW; Wed, 16 Oct 2013 03:31:56 +0000 Received: by mail-ob0-f179.google.com with SMTP id wp18so126200obc.38 for ; Tue, 15 Oct 2013 20:31:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rz7z5I8VB9b8opilNW3QY/uSC2xkVlco7RZ0BxmuRjQ=; b=bSO7OqZ6vmq3ait7R4UlFosE7K6UsFmtAgzVLpFKcF97dczckAGRDJsX3VYxUmAVA+ rfDhZ66DGzLgB5Cc8NM5wmXtLk5Ev3zGVvzFn9qk3iU69GUTOiQEo20+jYTm0BtEvD88 CfhWxeHdLVJuSlfq7sdbohgz4qIh39C6tAv90xRIH3RhOfOad/+nMxpJ4kNmNnM+TGGk GVsRx5EcPP9usYvko4XhBey2jswZjp6H1c9hSbRUQsovF+xSd3KiEzSbl09tKtIHbWwl M0dEEDz1HqmPId7td30N5oAIFPTRqLr8YeQvJmhezb2TUYkI81pesTOJiwbJhJ3a1wkM RSDw== MIME-Version: 1.0 X-Received: by 10.182.22.5 with SMTP id z5mr854939obe.42.1381894315138; Tue, 15 Oct 2013 20:31:55 -0700 (PDT) Received: by 10.182.128.136 with HTTP; Tue, 15 Oct 2013 20:31:55 -0700 (PDT) In-Reply-To: <20131016021324.GA11683@cisco.com> References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> Date: Tue, 15 Oct 2013 21:31:55 -0600 Message-ID: From: Kevin Gross To: Toerless Eckert Content-Type: multipart/alternative; boundary=001a1133232ec56e8804e8d3575a DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381894316; bh=rz7z5I8VB9b8opilNW3QY/uSC2xkVlco7RZ0BxmuRjQ=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=AulcDBDSjXIw80TA5LHkfXyVb8pc19UqXB0xyUYrX6V9nxcEafPTYE+kkjxTsQMKm E6vuk+GmRTbJECu01kmvtyZqq3Tr7EDxGmSh3MYhP1ro3raHgK3rDsoTD7wfqZ8Di+ Gj3+0CufDUBj6fJxi9tmt6kkizMWUc+clDejgcHIxkFahgqO15qeGeIHz2JS09+9XH ayJObFiTBokd6pbgQNFknGpuXmLIunv+oop4dqQmV5X3Dfeis91ul3zPBuw2uRZvqJ NVnjIqYCreOJ8WExljWy8ODk52WBUZNX48CFATHXMWSMjsKdx+lNd10W7G7mloaFDt q+nVPB9gccV2g== Cc: Bernard Aboba , rmcat WG , Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 03:32:01 -0000 --001a1133232ec56e8804e8d3575a Content-Type: text/plain; charset=ISO-8859-1 As I read it, the proposal in the draft is to have network equipment tweak DSCP values at ingress points so that drop precedence proportions are normalized in some way. This does not require that all senders produce normalized streams. The only thing that needs to be accepted is common normalization profiles for all the ingress points in the network. Under the proposal, useful drop precedence behavior becomes a network configuration issue, not a standards compliance issue. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com On Tue, Oct 15, 2013 at 8:13 PM, Toerless Eckert wrote: > Partially true IMHO. > > Yes, if we could have all flows agree to have a marking let's say 20% high, > 60% normal and 20% low prio bits (long term average), then we would not > need normalization. If there is any chance to establish such a standard, > that > would be gret. > > It just doesn't change the problem of DSCP. It would change the PHB though > by making it much more strict. Which makes it more questionable whether it > would be accepted. > > > Cheers > Toerless > > > On Tue, Oct 15, 2013 at 07:34:18PM -0600, Kevin Gross wrote: > > If we create a situation where all flows are "normalized" (i.e. a certain > > percentage of their packets are marked with higher drop precedence) by > the > > network then we shouldn't have to deal with things on a per-flow basis. > If > > we're not dealing with things on a per-flow basis, we can use the > existing > > AF codepoints. Dropping according to drop precedence markings on a class > > basis should be statistically fair to all flows so long as all flows have > > been normalized. > > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com > > > > > > On Tue, Oct 15, 2013 at 6:23 PM, Toerless Eckert > wrote: > > > > > The method described in the draft is applicable to whatever marking one > > > wants > > > to use. I wish DSCP was the solution because as you said it would avoid > > > the need > > > for figuring out how to carry a new marking (like RTP header > extensions). > > > > > > But: There are no existing DSCP with the PHB of "intra-flow-priority" > with > > > a > > > guarantee that flows with different distributions of those priorities > > > would see > > > the same percentage of drops under queue congestion. > > > > > > If we wanted to go the DSCP route, we would need at least 3 new DSCP to > > > indicate > > > high,normal,low intra-flow priority (and just for intelligent > dropping, 3 > > > actually > > > might be good enough). But 3 new DSCP is an act of god in the IETF. > > > > > > Then those three new DSCP would not only have to indicate intra-flow > > > priority but > > > also the overall class PHB that the traffic should have even without > > > priority > > > indications. Aka: lets say low loss, low latency, appropriate for > RMcat. > > > So when the next class of traffic with different intra-flow priorities > > > comes > > > along, we'd have to redo the whole DSCP exercise again. And again. > > > > > > And then the DSCP still get reset along the path, and apps still have > > > problems > > > setting DSCP across various OSs. > > > > > > Cheers > > > Toerless > > > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > > > Maybe I skimmed it too quickly but my understanding is that the > proposal > > > is > > > > to remark DSCP values at the ingress point of the network and > possibly at > > > > other key boundaries too. Such DSCP remapping is already common > practice > > > in > > > > enterprise networks. > > > > > > > > The twist here is that the remapper will do the remapping dynamically > > > based > > > > on the proportion of AFn1, AFn2 and AFn3 packets received from a > sender. > > > A > > > > greedy sender that it producing only AF41 markings will get some of > those > > > > randomly remarked as AF42 and AF43. > > > > > > > > The proposal uses existing DSCP values and it doesn't look like > signaling > > > > is necessary nor is it necessary for the application to know that > this is > > > > happening. > > > > > > > > Kevin Gross > > > > +1-303-447-0517 > > > > Media Network Consultant > > > > AVA Networks - www.AVAnw.com > > > > > > > > > > > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl > > > wrote: > > > > > > > > > Hmm. Whether the balance is right or not might depend on how the > > > signaling > > > > > is done. Anyway, unless I misunderstood something, the way the > > > normalizer > > > > > now stands it won't really make a change: it gives an incentive to > > > > > applications to mark some packets with higher drop precedence, yet > > > requires > > > > > applications to know that the normalizer is in place or else the > > > service > > > > > would be different. > > > > > > > > > > Maybe different DSCP values would be needed - but then this can't > be > > > used > > > > > in combination with "regular" DiffServ usage. It really depends on > the > > > > > signaling - ideas are now being tossed around by Colin and > Toerless, > > > who > > > > > clearly both know more about what the right signaling could be > than me. > > > > > > > > > > Cheers, > > > > > Michael > > > > > > > > > > > > > > > On 15. okt. 2013, at 19:04, Kevin Gross > wrote: > > > > > > > > > > I think you're stretching here. I don't think the balance is > right. The > > > > > proposed information is difficult to retrieve and of little use to > > > much of > > > > > the network. Even if standardized, it is unlikely to be successful. > > > > > > > > > > The ideas in the normalizer draft don't seem to have so many issues > > > and I > > > > > think it answers your original question and sets out to achieve > what > > > you're > > > > > looking for. > > > > > > > > > > Kevin Gross > > > > > +1-303-447-0517 > > > > > Media Network Consultant > > > > > AVA Networks - www.AVAnw.com > > > > > > > > > > > > > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl > > > > wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I'll dissect your second and third sentences and tell you what I > think > > > > >> about each part :-) below: > > > > >> > > > > >> > > > > >> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > > > >> > > > > >> > No, not per 5 tuple (per flow). I don't think that is something > we > > > > >> should ask of the network. > > > > >> > > > > >> I agree that asking this of the network may seem like encouraging > > > > >> per-flow functionality; in particular, if we'd put this into IP, > that > > > would > > > > >> be ugly. However, it's just a matter of fact that there are > devices > > > that do > > > > >> identify flows, and then, why not give such devices some > guidance? I > > > like > > > > >> Toerless' suggestion of making this an RTP header extension > field: if > > > a > > > > >> device is identifying flows, we can expect such a device to > identify > > > such a > > > > >> field too. Plus, if we think of end systems playing an > intermediate > > > system > > > > >> role in RTP (mixers, ..), these devices might also benefit from > that > > > sort > > > > >> of information. > > > > >> > > > > >> > > > > >> > It doesn't sit well with the end-to-end principle > > > > >> > > > > >> I disagree, this is an all-too-common misunderstanding of the > > > end-to-end > > > > >> principle: it only says that whatever can be done in the > application > > > should > > > > >> be left up to the application, but it doesn't say that you mustn't > > > identify > > > > >> application streams inside the network or "keep the network > simple and > > > > >> stupid". If you do "keep the network stupid", you're definitely in > > > line > > > > >> with the e2e argument, but the argument isn't as strict as that (a > > > typical > > > > >> example is routing, which can well become as complex as you wish, > > > without > > > > >> harming the end-to-end principle). Now here we're discussing a > > > function > > > > >> where the application really can't help you: when congestion > happens > > > inside > > > > >> the network and a packet must be dropped there, the best the > > > application > > > > >> can do is tell you which packet to drop. > > > > >> > > > > >> > > > > >> > and it won't scale. > > > > >> > > > > >> I agree. But it doesn't have to, just because we introduce the > signal > > > we > > > > >> don't harm scalability - devices at the edges of the network could > > > deal > > > > >> with it, all other devices could ignore it. > > > > >> > > > > >> Cheers, > > > > >> Michael > > > > >> > > > > >> > > > > > > > > > > > > > > > > -- > > > --- > > > Toerless Eckert, eckert@cisco.com > > > Cisco NSSTG Systems & Technology Architecture > > > SDN: Let me play with the network, mommy! > > > > > > > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > > --001a1133232ec56e8804e8d3575a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As I read it, the proposal in the draft is to have network= equipment tweak DSCP values at ingress points so that drop precedence prop= ortions are normalized in some way. This does not require that all senders = produce normalized streams. The only thing that needs to be accepted is com= mon normalization profiles for all the ingress points in the network. Under= the proposal, useful drop precedence behavior becomes a network configurat= ion issue, not a standards compliance issue.

Kevin Gr= oss
+1-303-447-0517
Media Network Consultant
AVA = Networks -=A0www.AVAnw.= com


On Tue, Oct 15, 2013 at 8:13 PM, Toerles= s Eckert <eckert@cisco.com> wrote:
Partially true IMHO.

Yes, if we could have all flows agree to have a marking let's say 20% h= igh,
60% normal and 20% low prio bits (long term average), then we would not
need normalization. If there is any chance to establish such a standard, th= at
would be gret.

It just doesn't change the problem of DSCP. It would change the PHB tho= ugh
by making it much more strict. Which makes it more questionable whether it<= br> would be accepted.


Cheers
=A0 =A0 Toerless


On Tue, Oct 15, 2013 at 07:34:18PM -0600, Kevin Gross wrote:
> If we create a situation where all flows are "normalized" (i= .e. a certain
> percentage of their packets are marked with higher drop precedence) by= the
> network then we shouldn't have to deal with things on a per-flow b= asis. If
> we're not dealing with things on a per-flow basis, we can use the = existing
> AF codepoints. Dropping according to drop precedence markings on a cla= ss
> basis should be statistically fair to all flows so long as all flows h= ave
> been normalized.
>
> Kevin Gross
> +1-303-447-05= 17
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/><= br> >
>
> On Tue, Oct 15, 2013 at 6:23 PM, Toerless Eckert <eckert@cisco.com> wrote:
>
> > The method described in the draft is applicable to whatever marki= ng one
> > wants
> > to use. I wish DSCP was the solution because as you said it would= avoid
> > the need
> > for figuring out how to carry a new marking (like RTP header exte= nsions).
> >
> > But: There are no existing DSCP with the PHB of "intra-flow-= priority" with
> > a
> > guarantee that flows with different distributions of those priori= ties
> > would see
> > the same percentage of drops under queue congestion.
> >
> > If we wanted to go the DSCP route, we would need at least 3 new D= SCP to
> > indicate
> > high,normal,low intra-flow priority (and just for intelligent dro= pping, 3
> > actually
> > might be good enough). But 3 new DSCP is an act of god in the IET= F.
> >
> > Then those three new DSCP would not only have to indicate intra-f= low
> > priority but
> > also the overall class PHB that the traffic should have even with= out
> > priority
> > indications. Aka: lets say low loss, low latency, appropriate for= RMcat.
> > So when the next class of traffic with different intra-flow prior= ities
> > comes
> > along, we'd have to redo the whole DSCP exercise again. And a= gain.
> >
> > And then the DSCP still get reset along the path, and apps still = have
> > problems
> > setting DSCP across various OSs.
> >
> > Cheers
> > =A0 =A0 Toerless
> >
> > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote:
> > > Maybe I skimmed it too quickly but my understanding is that = the proposal
> > is
> > > to remark DSCP values at the ingress point of the network an= d possibly at
> > > other key boundaries too. Such DSCP remapping is already com= mon practice
> > in
> > > enterprise networks.
> > >
> > > The twist here is that the remapper will do the remapping dy= namically
> > based
> > > on the proportion of AFn1, AFn2 and AFn3 packets received fr= om a sender.
> > A
> > > greedy sender that it producing only AF41 markings will get = some of those
> > > randomly remarked as AF42 and AF43.
> > >
> > > The proposal uses existing DSCP values and it doesn't lo= ok like signaling
> > > is necessary nor is it necessary for the application to know= that this is
> > > happening.
> > >
> > > Kevin Gross
> > > +1-303-447-0517
> > > Media Network Consultant
> > > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> > >
> > >
> > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl <michawe@ifi.uio.no>
> > wrote:
> > >
> > > > Hmm. Whether the balance is right or not might depend o= n how the
> > signaling
> > > > is done. Anyway, unless I misunderstood something, the = way the
> > normalizer
> > > > now stands it won't really make a change: it gives = an incentive to
> > > > applications to mark some packets with higher drop prec= edence, yet
> > requires
> > > > applications to know that the normalizer is in place or= else the
> > service
> > > > would be different.
> > > >
> > > > Maybe different DSCP values would be needed - but then = this can't be
> > used
> > > > in combination with "regular" DiffServ usage.= It really depends on the
> > > > signaling - ideas are now being tossed around by Colin = and Toerless,
> > who
> > > > clearly both know more about what the right signaling c= ould be than me.
> > > >
> > > > Cheers,
> > > > Michael
> > > >
> > > >
> > > > On 15. okt. 2013, at 19:04, Kevin Gross <kevin.gross@avanw.com> wrote:
> > > >
> > > > I think you're stretching here. I don't think t= he balance is right. The
> > > > proposed information is difficult to retrieve and of li= ttle use to
> > much of
> > > > the network. Even if standardized, it is unlikely to be= successful.
> > > >
> > > > The ideas in the normalizer draft don't seem to hav= e so many issues
> > and I
> > > > think it answers your original question and sets out to= achieve what
> > you're
> > > > looking for.
> > > >
> > > > Kevin Gross
> > > > +1-303-447-0517
> > > > Media Network Consultant
> > > > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> > > >
> > > >
> > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl <michawe@ifi.uio.no>
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I'll dissect your second and third sentences an= d tell you what I think
> > > >> about each part =A0:-) =A0 below:
> > > >>
> > > >>
> > > >> On 14. okt. 2013, at 23:35, Kevin Gross wrote:
> > > >>
> > > >> > No, not per 5 tuple (per flow). I don't th= ink that is something we
> > > >> should ask of the network.
> > > >>
> > > >> I agree that asking this of the network may seem li= ke encouraging
> > > >> per-flow functionality; in particular, if we'd = put this into IP, that
> > would
> > > >> be ugly. However, it's just a matter of fact th= at there are devices
> > that do
> > > >> identify flows, and then, why not give such devices= some guidance? =A0I
> > like
> > > >> Toerless' suggestion of making this an RTP head= er extension field: if
> > a
> > > >> device is identifying flows, we can expect such a d= evice to identify
> > such a
> > > >> field too. Plus, if we think of end systems playing= an intermediate
> > system
> > > >> role in RTP (mixers, ..), these devices might also = benefit from that
> > sort
> > > >> of information.
> > > >>
> > > >>
> > > >> > It doesn't sit well with the end-to-end pr= inciple
> > > >>
> > > >> I disagree, this is an all-too-common misunderstand= ing of the
> > end-to-end
> > > >> principle: it only says that whatever can be done i= n the application
> > should
> > > >> be left up to the application, but it doesn't s= ay that you mustn't
> > identify
> > > >> application streams inside the network or "kee= p the network simple and
> > > >> stupid". If you do "keep the network stup= id", you're definitely in
> > line
> > > >> with the e2e argument, but the argument isn't a= s strict as that (a
> > typical
> > > >> example is routing, which can well become as comple= x as you wish,
> > without
> > > >> harming the end-to-end principle). Now here we'= re discussing a
> > function
> > > >> where the application really can't help you: wh= en congestion happens
> > inside
> > > >> the network and a packet must be dropped there, the= best the
> > application
> > > >> can do is tell you which packet to drop.
> > > >>
> > > >>
> > > >> > and it won't scale.
> > > >>
> > > >> I agree. But it doesn't have to, just because w= e introduce the signal
> > we
> > > >> don't harm scalability - devices at the edges o= f the network could
> > deal
> > > >> with it, all other devices could ignore it.
> > > >>
> > > >> Cheers,
> > > >> Michael
> > > >>
> > > >>
> > > >
> > > >
> >
> > --
> > ---
> > Toerless Eckert, eckert@cisco= .com
> > Cisco NSSTG Systems & Technology Architecture
> > SDN: Let me play with the network, mommy!
> >
> >

--
---
Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!


--001a1133232ec56e8804e8d3575a-- From ingemar.s.johansson@ericsson.com Tue Oct 15 23:42:11 2013 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 E122C21F9E52 for ; Tue, 15 Oct 2013 23:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg-HXFfCQeZi for ; Tue, 15 Oct 2013 23:42:06 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 25BB111E8101 for ; Tue, 15 Oct 2013 23:42:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-13-525e353bafc2 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 03.F0.16099.B353E525; Wed, 16 Oct 2013 08:42:03 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.11]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 08:42:02 +0200 From: Ingemar Johansson S To: "Van Der Auwera, Geert" , rmcat WG Thread-Topic: [rmcat] draft-vanderauwera-rmcat-video-quality Thread-Index: AQHOyRAqZZiBadU22UGKupfsfcenAJn1g/TwgAB3OQCAANlI8A== Date: Wed, 16 Oct 2013 06:42:02 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA1C39B113@ESESSMB205.ericsson.se> References: <6F0A5342-E5EF-44DD-94C2-9EB97FFE3A07@netapp.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39A74E@ESESSMB205.ericsson.se> <4FC1F85139E6FE4D9A55BD6798B29A4816AD20A5@NASANEXD02B.na.qualcomm.com> In-Reply-To: <4FC1F85139E6FE4D9A55BD6798B29A4816AD20A5@NASANEXD02B.na.qualcomm.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvra61aVyQwY+tMhbnj59lsnjxuofF YvXND2wOzB5Llvxk8pjx6Qubx6KpzxgDmKO4bFJSczLLUov07RK4Mnac5S44o1Rx/sw0pgbG 99JdjJwcEgImEk/P/GSGsMUkLtxbz9bFyMUhJHCYUeLZwwOsEM5iRokZJz8wgVSxCdhIrDz0 nbGLkYNDRCBIYuZhdZAws4CKxM+jc1lAbGEBa4n1s6YygtgiQOVf905lhrCdJM6/3g9WwyKg KnHt2iqwkbwCvhLTpz2BWnyKUeLLnV9sIAlOgWCJL0fvgg1iFJCVuP/9HgvEMnGJW0/mM0Fc LSCxZM95qA9EJV4+/scKYStKtD9tYISo15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2C8nY WUhaZiFpmYWkZQEjyypG9tzEzJz0csNNjMC4Objlt+4OxlPnRA4xSnOwKInzfnjrHCQkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBMV2wPKbGbkPZx09ltxhnb2qQi2+Zm6PW+aNqE69fwq7z pgcaWXrNhO+pWK12S+QR36bwpthli+nbD0H+LgYByWbm3AvKvO+eL1d++fuS0hH7hQ9T9Gdx K0Rkn3ln3s6YuXr/z1tXmtwvnN2YsUmTN7rvrfMD2/NPrpaHbvobXZ0qxHjvTkGWEktxRqKh FnNRcSIAsGC3DGkCAAA= Cc: "Eggert, Lars" Subject: Re: [rmcat] draft-vanderauwera-rmcat-video-quality X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 06:42:12 -0000 Hi Thanks for the reply. I assumed 1500byte packeys which gives almost 400ms delay.=20 As I see it it seems a bit pessimistic with a ratio 30-40 between latency u= nder load and min RTT.=20 I am fully aware of the bufferbloat problem but isn't there a risk that thi= s becomes a corner case and that it might drive designs in a direction that= makes them suboptimal for the main operating conditions. To take an example: In order for the RMCAT flow to be able to compete with = an FTP using TCP Reno or Cubic over this bottleneck, it becomes necessary t= hat the RMCAT flow contributes to the bufferbloat for instance by increasin= g a target delay or whatever. Unless the RMCAT flow gets some magic informa= tion from the network, it needs to infer information about the existence of= competing flows, it can work more or less well and I see before be a lot o= f special code to do this, some of it actually becomes engineered to solve = this particular test case.=20 The problem with this is that this added intelligence can actually increase= the risk that the RMCAT flow it self creates self-inflicted congestion due= to faulty decisions, meaning that the RMCAT flow it self locks it self in = 400ms RTT even though there is no competing traffic. I leave to others to comment, perhaps I outline a corner problem :-). /Ingemar > -----Original Message----- > From: Van Der Auwera, Geert [mailto:geertv@qti.qualcomm.com] > Sent: den 15 oktober 2013 20:50 > To: rmcat WG > Cc: Ingemar Johansson S; Eggert, Lars > Subject: RE: [rmcat] draft-vanderauwera-rmcat-video-quality >=20 > Dear Ingemar, >=20 > Thank you for your feedback. The queue size parameter in the test scenari= os > can be defined smaller as you suggest to reduce delay. I based my estimat= e > on 1200 byte packets and 1Mbps, which results in a delay of ~300ms. There > are no particular hardware considerations for us, but I verified that for= some > typical router the queue length can be configured between 0 and 4096 > packets (default seems 75), for example. >=20 > I would also like to use this opportunity to introduce the document by > providing the introduction here and hopefully have some discussions in th= e > RMCAT WG: >=20 > "The impact of congestion control on media streams is important in real- > world deployments. Therefore, the purpose of this evaluation is to verify= or > inspect the video quality of RMCAT congestion control solutions under > different test scenarios. RMCAT based rate adaptations should result in > expected or desired video quality when implemented in a state-of-the-art > video coding and communication framework. In other words, the purpose is > to verify that there are no unexpected or undesired video quality problem= s > caused by congestion control behaviors, while the main purpose is not to > directly compare RMCAT solutions against each other. It is proposed to > perform such video quality evaluation of candidate RMCAT solutions in > addition to network traffic evaluations. >=20 > An additional test scenario is proposed to evaluate the rate allocation > behavior of RMCAT solutions when asymmetric flow conditions exist. In thi= s > test the video quality is not evaluated." >=20 > Best regards, >=20 > Geert >=20 > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: Tuesday, October 15, 2013 2:50 AM > To: Van Der Auwera, Geert > Cc: Eggert, Lars; rmcat WG > Subject: RE: [rmcat] draft-vanderauwera-rmcat-video-quality >=20 > Hi >=20 > I have a question as regards to the size of the tail drop queue (32 packe= ts). > Given the bandwidth you end up with one way delays up to ~400ms when > the link is loaded with an FTP download. Is the 32 packet value given by = some > typical hardware considerations ?. > Given the bandwidth delay product (1Mbps, RTT=3D2*10ms) it should be > sufficient with a much lower queue size ? >=20 > /Ingemar > > -----Original Message----- > > From: Eggert, Lars [mailto:lars@netapp.com] > > Sent: den 14 oktober 2013 11:42 > > To: rmcat WG > > Subject: [rmcat] draft-vanderauwera-rmcat-video-quality > > > > Hi WG, > > > > please see http://trac.tools.ietf.org/html/draft-vanderauwera-rmcat- > video- > > quality-00 for a new ID describing quality test scenarios. > > > > Please discuss. > > > > Lars From michawe@ifi.uio.no Wed Oct 16 00:06:54 2013 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 7039711E80F5 for ; Wed, 16 Oct 2013 00:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.659 X-Spam-Level: X-Spam-Status: No, score=-102.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmyF0nY2jq7Z for ; Wed, 16 Oct 2013 00:06:49 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 5E20011E8171 for ; Wed, 16 Oct 2013 00:06:38 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VWLBl-0000Ju-AG; Wed, 16 Oct 2013 09:06:37 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VWLBk-0000FW-Nv; Wed, 16 Oct 2013 09:06:37 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA1C39B113@ESESSMB205.ericsson.se> Date: Wed, 16 Oct 2013 09:06:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F0A5342-E5EF-44DD-94C2-9EB97FFE3A07@netapp.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39A74E@ESESSMB205.ericsson.se> <4FC1F85139E6FE4D9A55BD6798B29A4816AD20A5@NASANEXD02B.na.qualcomm.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39B113@ESESSMB205.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 8611 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A959B0C69C4758A965AF22C8A0B7D79A3B9290C1 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3361 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: "Van Der Auwera, Geert" , rmcat WG , "Eggert, Lars" Subject: Re: [rmcat] draft-vanderauwera-rmcat-video-quality X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 07:06:54 -0000 On 16. okt. 2013, at 08:42, Ingemar Johansson S wrote: > Hi >=20 > Thanks for the reply. > I assumed 1500byte packeys which gives almost 400ms delay.=20 > As I see it it seems a bit pessimistic with a ratio 30-40 between = latency under load and min RTT.=20 > I am fully aware of the bufferbloat problem but isn't there a risk = that this becomes a corner case and that it might drive designs in a = direction that makes them suboptimal for the main operating conditions. >=20 > To take an example: In order for the RMCAT flow to be able to compete = with an FTP using TCP Reno or Cubic over this bottleneck, it becomes = necessary that the RMCAT flow contributes to the bufferbloat for = instance by increasing a target delay or whatever. Unless the RMCAT flow = gets some magic information from the network, it needs to infer = information about the existence of competing flows, it can work more or = less well and I see before be a lot of special code to do this, some of = it actually becomes engineered to solve this particular test case.=20 Measured delay can serve as this "magic information"... > The problem with this is that this added intelligence can actually = increase the risk that the RMCAT flow it self creates self-inflicted = congestion due to faulty decisions, meaning that the RMCAT flow it self = locks it self in 400ms RTT even though there is no competing traffic. That would be the result of a badly designed congestion controller. I = don't think that this naturally follows from trying to minimize delay, = yet compete with TCP when it is present. > I leave to others to comment, perhaps I outline a corner problem :-). >=20 > /Ingemar Cheers, Michael >=20 >> -----Original Message----- >> From: Van Der Auwera, Geert [mailto:geertv@qti.qualcomm.com] >> Sent: den 15 oktober 2013 20:50 >> To: rmcat WG >> Cc: Ingemar Johansson S; Eggert, Lars >> Subject: RE: [rmcat] draft-vanderauwera-rmcat-video-quality >>=20 >> Dear Ingemar, >>=20 >> Thank you for your feedback. The queue size parameter in the test = scenarios >> can be defined smaller as you suggest to reduce delay. I based my = estimate >> on 1200 byte packets and 1Mbps, which results in a delay of ~300ms. = There >> are no particular hardware considerations for us, but I verified that = for some >> typical router the queue length can be configured between 0 and 4096 >> packets (default seems 75), for example. >>=20 >> I would also like to use this opportunity to introduce the document = by >> providing the introduction here and hopefully have some discussions = in the >> RMCAT WG: >>=20 >> "The impact of congestion control on media streams is important in = real- >> world deployments. Therefore, the purpose of this evaluation is to = verify or >> inspect the video quality of RMCAT congestion control solutions under >> different test scenarios. RMCAT based rate adaptations should result = in >> expected or desired video quality when implemented in a = state-of-the-art >> video coding and communication framework. In other words, the purpose = is >> to verify that there are no unexpected or undesired video quality = problems >> caused by congestion control behaviors, while the main purpose is not = to >> directly compare RMCAT solutions against each other. It is proposed = to >> perform such video quality evaluation of candidate RMCAT solutions in >> addition to network traffic evaluations. >>=20 >> An additional test scenario is proposed to evaluate the rate = allocation >> behavior of RMCAT solutions when asymmetric flow conditions exist. In = this >> test the video quality is not evaluated." >>=20 >> Best regards, >>=20 >> Geert >>=20 >> -----Original Message----- >> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >> Sent: Tuesday, October 15, 2013 2:50 AM >> To: Van Der Auwera, Geert >> Cc: Eggert, Lars; rmcat WG >> Subject: RE: [rmcat] draft-vanderauwera-rmcat-video-quality >>=20 >> Hi >>=20 >> I have a question as regards to the size of the tail drop queue (32 = packets). >> Given the bandwidth you end up with one way delays up to ~400ms when >> the link is loaded with an FTP download. Is the 32 packet value given = by some >> typical hardware considerations ?. >> Given the bandwidth delay product (1Mbps, RTT=3D2*10ms) it should be >> sufficient with a much lower queue size ? >>=20 >> /Ingemar >>> -----Original Message----- >>> From: Eggert, Lars [mailto:lars@netapp.com] >>> Sent: den 14 oktober 2013 11:42 >>> To: rmcat WG >>> Subject: [rmcat] draft-vanderauwera-rmcat-video-quality >>>=20 >>> Hi WG, >>>=20 >>> please see http://trac.tools.ietf.org/html/draft-vanderauwera-rmcat- >> video- >>> quality-00 for a new ID describing quality test scenarios. >>>=20 >>> Please discuss. >>>=20 >>> Lars From michawe@ifi.uio.no Wed Oct 16 00:22:28 2013 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 6DF6A11E80F9 for ; Wed, 16 Oct 2013 00:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6Ejb7rU-go7 for ; Wed, 16 Oct 2013 00:22:21 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 64FD111E810F for ; Wed, 16 Oct 2013 00:22:08 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VWLQh-0001X8-CV; Wed, 16 Oct 2013 09:22:03 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VWLQf-000148-VN; Wed, 16 Oct 2013 09:22:03 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_AFABCE9E-3C47-47DD-A4BE-5A9E45725320" From: Michael Welzl In-Reply-To: <20131016002302.GC20478@cisco.com> Date: Wed, 16 Oct 2013 09:22:00 +0200 Message-Id: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 10 sum msgs/h 4 total rcpts 8615 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BA3BF75C2C1C97B6BA666182F5065130757237C3 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 3362 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: Bernard Aboba , rmcat WG , Kevin Gross Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 07:22:28 -0000 --Apple-Mail=_AFABCE9E-3C47-47DD-A4BE-5A9E45725320 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16. okt. 2013, at 02:23, Toerless Eckert wrote: > The method described in the draft is applicable to whatever marking = one wants > to use. I wish DSCP was the solution because as you said it would = avoid the need > for figuring out how to carry a new marking (like RTP header = extensions). >=20 > But: There are no existing DSCP with the PHB of "intra-flow-priority" = with a > guarantee that flows with different distributions of those priorities = would see > the same percentage of drops under queue congestion. >=20 > If we wanted to go the DSCP route, we would need at least 3 new DSCP = to indicate > high,normal,low intra-flow priority (and just for intelligent = dropping, 3 actually Exactly. > might be good enough). But 3 new DSCP is an act of god in the IETF. >=20 > Then those three new DSCP would not only have to indicate intra-flow = priority but > also the overall class PHB that the traffic should have even without = priority=20 > indications. Aka: lets say low loss, low latency, appropriate for = RMcat. > So when the next class of traffic with different intra-flow priorities = comes > along, we'd have to redo the whole DSCP exercise again. And again. ....so we'd really need "intra-flow drop precedence" bits, to inter-work = with existing DSCP values and get the expected PHB, right? (or do as you say, define the PHB + precedence, for all possible = combinations) > And then the DSCP still get reset along the path, and apps still have = problems > setting DSCP across various OSs. There is also an architectural side to it: Kevin rightfully started this = conversation by saying: "No, not per 5 tuple (per flow). I don't think = that is something we should ask of the network." Indeed, doing this right *requires* routers (or whatever box does that) = to identify flows and keep track of them. Such per-flow functionality = isn't what we want "normal" routers to do, I think, and so binding DSCP = values to such a functionality just seems wrong to me. In a way, it = makes the IP header less self-contained: in order to implement all the = functions encoded in it, you need to look beyond the IP header. This = doesn't strike me as good design. I think it's not too much to ask of devices that identify flows to look = beyond the IP header for a shim, RTP-something, or whatever we define. = Then, this device can aggregate flows into the right DSCPs if it knows = that traffic's going to traverse a path where the normalizer is present = - and the normalizing devices again only need to look at the IP header, = where it's all per-aggregate. (sorry for repeating myself, I thought I'd say this again here just for = context, but I did say this before) Cheers, Michael >=20 > Cheers > Toerless >=20 > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: >> Maybe I skimmed it too quickly but my understanding is that the = proposal is >> to remark DSCP values at the ingress point of the network and = possibly at >> other key boundaries too. Such DSCP remapping is already common = practice in >> enterprise networks. >>=20 >> The twist here is that the remapper will do the remapping dynamically = based >> on the proportion of AFn1, AFn2 and AFn3 packets received from a = sender. A >> greedy sender that it producing only AF41 markings will get some of = those >> randomly remarked as AF42 and AF43. >>=20 >> The proposal uses existing DSCP values and it doesn't look like = signaling >> is necessary nor is it necessary for the application to know that = this is >> happening. >>=20 >> Kevin Gross >> +1-303-447-0517 >> Media Network Consultant >> AVA Networks - www.AVAnw.com >>=20 >>=20 >> On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl = wrote: >>=20 >>> Hmm. Whether the balance is right or not might depend on how the = signaling >>> is done. Anyway, unless I misunderstood something, the way the = normalizer >>> now stands it won't really make a change: it gives an incentive to >>> applications to mark some packets with higher drop precedence, yet = requires >>> applications to know that the normalizer is in place or else the = service >>> would be different. >>>=20 >>> Maybe different DSCP values would be needed - but then this can't be = used >>> in combination with "regular" DiffServ usage. It really depends on = the >>> signaling - ideas are now being tossed around by Colin and Toerless, = who >>> clearly both know more about what the right signaling could be than = me. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>> On 15. okt. 2013, at 19:04, Kevin Gross = wrote: >>>=20 >>> I think you're stretching here. I don't think the balance is right. = The >>> proposed information is difficult to retrieve and of little use to = much of >>> the network. Even if standardized, it is unlikely to be successful. >>>=20 >>> The ideas in the normalizer draft don't seem to have so many issues = and I >>> think it answers your original question and sets out to achieve what = you're >>> looking for. >>>=20 >>> Kevin Gross >>> +1-303-447-0517 >>> Media Network Consultant >>> AVA Networks - www.AVAnw.com >>>=20 >>>=20 >>> On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I'll dissect your second and third sentences and tell you what I = think >>>> about each part :-) below: >>>>=20 >>>>=20 >>>> On 14. okt. 2013, at 23:35, Kevin Gross wrote: >>>>=20 >>>>> No, not per 5 tuple (per flow). I don't think that is something we >>>> should ask of the network. >>>>=20 >>>> I agree that asking this of the network may seem like encouraging >>>> per-flow functionality; in particular, if we'd put this into IP, = that would >>>> be ugly. However, it's just a matter of fact that there are devices = that do >>>> identify flows, and then, why not give such devices some guidance? = I like >>>> Toerless' suggestion of making this an RTP header extension field: = if a >>>> device is identifying flows, we can expect such a device to = identify such a >>>> field too. Plus, if we think of end systems playing an intermediate = system >>>> role in RTP (mixers, ..), these devices might also benefit from = that sort >>>> of information. >>>>=20 >>>>=20 >>>>> It doesn't sit well with the end-to-end principle >>>>=20 >>>> I disagree, this is an all-too-common misunderstanding of the = end-to-end >>>> principle: it only says that whatever can be done in the = application should >>>> be left up to the application, but it doesn't say that you mustn't = identify >>>> application streams inside the network or "keep the network simple = and >>>> stupid". If you do "keep the network stupid", you're definitely in = line >>>> with the e2e argument, but the argument isn't as strict as that (a = typical >>>> example is routing, which can well become as complex as you wish, = without >>>> harming the end-to-end principle). Now here we're discussing a = function >>>> where the application really can't help you: when congestion = happens inside >>>> the network and a packet must be dropped there, the best the = application >>>> can do is tell you which packet to drop. >>>>=20 >>>>=20 >>>>> and it won't scale. >>>>=20 >>>> I agree. But it doesn't have to, just because we introduce the = signal we >>>> don't harm scalability - devices at the edges of the network could = deal >>>> with it, all other devices could ignore it. >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>>=20 >>>=20 >>>=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 --Apple-Mail=_AFABCE9E-3C47-47DD-A4BE-5A9E45725320 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The = method described in the draft is applicable to whatever marking one = wants
to use. I wish DSCP was the solution because as you said it = would avoid the need
for figuring out how to carry a new marking = (like RTP header extensions).

But: There are no existing DSCP = with the PHB of "intra-flow-priority" with a
guarantee that flows = with different distributions of those priorities would see
the same = percentage of drops under queue congestion.

If we wanted to go = the DSCP route, we would need at least 3 new DSCP to = indicate
high,normal,low intra-flow priority (and just for = intelligent dropping, 3 = actually

Exactly.

=

might be good enough). But 3 = new DSCP is an act of god in the IETF.

Then those three new DSCP = would not only have to indicate intra-flow priority but
also the = overall class PHB that the traffic should have even without priority =
indications. Aka: lets say low loss, low latency, appropriate for = RMcat.
So when the next class of traffic with different intra-flow = priorities comes
along, we'd have to redo the whole DSCP exercise = again. And again.

....so we'd = really need "intra-flow drop precedence" bits, to inter-work with = existing DSCP values and get the expected PHB, right?
(or do = as you say, define the PHB + precedence, for all possible = combinations)


And = then the DSCP still get reset along the path, and apps still have = problems
setting DSCP across various = OSs.

There is also an = architectural side to it: Kevin rightfully started this conversation by = saying: "No, not per 5 tuple (per flow). I don't think that is something = we should ask of the network."
Indeed, doing this = right *requires* routers (or whatever box does that) to identify flows = and keep track of them. Such per-flow functionality isn't what we want = "normal" routers to do, I think, and so binding  DSCP values to = such a functionality just seems wrong to me. In a way, it makes the IP = header less self-contained: in order to implement all the functions = encoded in it, you need to look beyond the IP header. This doesn't = strike me as good design.

I think it's not too = much to ask of devices that identify flows to look beyond the IP header = for a shim, RTP-something, or whatever we define. Then, this device can = aggregate flows into the right DSCPs if it knows that traffic's going to = traverse a path where the normalizer is present - and the normalizing = devices again only need to look at the IP header, where it's all = per-aggregate.
(sorry for repeating myself, I thought I'd say = this again here just for context, but I did say this = before)

Cheers,
Michael

<= /div>




Cheers
   Toerless

On = Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote:
Maybe I skimmed it too quickly but my understanding is = that the proposal is
to remark = DSCP values at the ingress point of the network and possibly = at
other key boundaries too. = Such DSCP remapping is already common practice = in
enterprise = networks.

The twist here = is that the remapper will do the remapping dynamically = based
on the proportion of = AFn1, AFn2 and AFn3 packets received from a sender. = A
greedy sender that it = producing only AF41 markings will get some of = those
randomly remarked as = AF42 and AF43.

The proposal = uses existing DSCP values and it doesn't look like = signaling
is necessary nor is = it necessary for the application to know that this = is
happening.

Kevin = Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>


On Tue, Oct 15, = 2013 at 2:43 PM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hmm. Whether the balance is right or not might depend on = how the signaling
is done. Anyway, unless I = misunderstood something, the way the = normalizer
now stands it won't really make = a change: it gives an incentive = to
applications to mark some packets with higher drop = precedence, yet requires
applications to know that the = normalizer is in place or else the = service
would be = different.

Maybe different DSCP values = would be needed - but then this can't be = used
in combination with "regular" DiffServ usage. It really = depends on the
signaling - ideas are now being = tossed around by Colin and Toerless, = who
clearly both know more about what the right signaling = could be than me.

Cheers,
Michael


On 15. okt. 2013, at 19:04, = Kevin Gross <kevin.gross@avanw.com> = wrote:

I think you're stretching here. = I don't think the balance is right. = The
proposed information is difficult to retrieve and of = little use to much of
the network. Even if = standardized, it is unlikely to be = successful.

The ideas in the normalizer = draft don't seem to have so many issues and = I
think it answers your original question and sets out to = achieve what you're
looking = for.

Kevin = Gross
+1-303-447-0517
Media Network = Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>


On Tue, Oct 15, 2013 at 1:59 AM, = Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

I'll = dissect your second and third sentences and tell you what I = think
about = each part  :-) =   below:


On 14. = okt. 2013, at 23:35, Kevin Gross = wrote:

No, not per 5 tuple (per flow). = I don't think that is something = we
should = ask of the = network.

I = agree that asking this of the network may seem like = encouraging
per-flow= functionality; in particular, if we'd put this into IP, that = would
be = ugly. However, it's just a matter of fact that there are devices that = do
identify= flows, and then, why not give such devices some guidance?  I = like
Toerless' suggestion of making this an RTP header = extension field: if = a
device = is identifying flows, we can expect such a device to identify such = a
field = too. Plus, if we think of end systems playing an intermediate = system
role = in RTP (mixers, ..), these devices might also benefit from that = sort
of = information.


It doesn't sit well with the = end-to-end = principle

I = disagree, this is an all-too-common misunderstanding of the = end-to-end
principle: it only says that whatever can be done in the = application should
be = left up to the application, but it doesn't say that you mustn't = identify
application streams inside the network or "keep the = network simple and
stupid".= If you do "keep the network stupid", you're definitely in = line
with = the e2e argument, but the argument isn't as strict as that (a = typical
example = is routing, which can well become as complex as you wish, = without
harming = the end-to-end principle). Now here we're discussing a = function
where = the application really can't help you: when congestion happens = inside
the = network and a packet must be dropped there, the best the = application
can do = is tell you which packet to = drop.


and it won't = scale.

I = agree. But it doesn't have to, just because we introduce the signal = we
don't = harm scalability - devices at the edges of the network could = deal
with = it, all other devices could ignore = it.

Cheers,
Michael





--
---
Toerless = Eckert, eckert@cisco.com
Cisco = NSSTG Systems & Technology Architecture
SDN: Let me play with the = network, mommy!


= --Apple-Mail=_AFABCE9E-3C47-47DD-A4BE-5A9E45725320-- From michawe@ifi.uio.no Wed Oct 16 00:36:37 2013 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 8E1CF11E810F; Wed, 16 Oct 2013 00:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Etpx4AUZfdm0; Wed, 16 Oct 2013 00:36:32 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 3337211E810B; Wed, 16 Oct 2013 00:36:17 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VWLeK-0001vP-SD; Wed, 16 Oct 2013 09:36:08 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VWLeJ-0002P2-La; Wed, 16 Oct 2013 09:36:08 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DE58D3AC-4F90-431D-95C7-97CA61F043DC" From: Michael Welzl In-Reply-To: Date: Wed, 16 Oct 2013 09:36:06 +0200 Message-Id: <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> To: Kevin Gross X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 3 sum rcpts/h 15 sum msgs/h 5 total rcpts 8620 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1136063B67F332C0EA27393680B552E9AED70268 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 3363 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: Bernard Aboba , rmcat WG , Toerless Eckert , tsv-area@ietf.org Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 07:36:37 -0000 --Apple-Mail=_DE58D3AC-4F90-431D-95C7-97CA61F043DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 [I'm adding tsv-area: I noticed it was dropped from some part of this = thread, but I think unintentionally? BTW I hope tsv-area is appropriate, = and not tsvwg? I started off to rmcat and tsv-area because I had a = general DiffServ'ish question, yet related to rmcat, and so I thought = this would fit.] Hi, Imagine that you write an application and based on the intra-flow = priorities of your packets you decide that this would be your profile: (copy+paste from the draft) *** Flow B 40% or 2Mbps in AF41 40% or 2Mbps in AF42 20% or 1Mbps in AF43 *** ...and the normalizer is not present in the network, and you get = "normal" DiffServ behavior (because we're using the standard AF = codepoints). Now, if someone else uses: *** Flow A 80% or 4Mbps in AF41 20% or 1Mbps in AF42 0% or 0Mbps in AF43 *** ...then this someone (flow A) would be better off in the presence of = congestion, as described in the draft. This means that you'll never = decide for a profile as in Flow B in your application because you could = hurt yourself, you might be treated worse than some other users. This is what the normalizer fixes, but as long as you don't know it's = there, going for a profile as in Flow B is still risky business. "You" in my story here is the application programmer, and it really has = to be the application programmer doing this - the priorities would be = derived from knowledge about the codec, FEC usage etc. What the = application programmer needs is a signal that is definitely going to be = ignored unless it hits a normalizing ingress device. Cheers, Michael On 16. okt. 2013, at 05:31, Kevin Gross wrote: > As I read it, the proposal in the draft is to have network equipment = tweak DSCP values at ingress points so that drop precedence proportions = are normalized in some way. This does not require that all senders = produce normalized streams. The only thing that needs to be accepted is = common normalization profiles for all the ingress points in the network. = Under the proposal, useful drop precedence behavior becomes a network = configuration issue, not a standards compliance issue. >=20 > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com >=20 >=20 > On Tue, Oct 15, 2013 at 8:13 PM, Toerless Eckert = wrote: > Partially true IMHO. >=20 > Yes, if we could have all flows agree to have a marking let's say 20% = high, > 60% normal and 20% low prio bits (long term average), then we would = not > need normalization. If there is any chance to establish such a = standard, that > would be gret. >=20 > It just doesn't change the problem of DSCP. It would change the PHB = though > by making it much more strict. Which makes it more questionable = whether it > would be accepted. >=20 >=20 > Cheers > Toerless >=20 >=20 > On Tue, Oct 15, 2013 at 07:34:18PM -0600, Kevin Gross wrote: > > If we create a situation where all flows are "normalized" (i.e. a = certain > > percentage of their packets are marked with higher drop precedence) = by the > > network then we shouldn't have to deal with things on a per-flow = basis. If > > we're not dealing with things on a per-flow basis, we can use the = existing > > AF codepoints. Dropping according to drop precedence markings on a = class > > basis should be statistically fair to all flows so long as all flows = have > > been normalized. > > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com > > > > > > On Tue, Oct 15, 2013 at 6:23 PM, Toerless Eckert = wrote: > > > > > The method described in the draft is applicable to whatever = marking one > > > wants > > > to use. I wish DSCP was the solution because as you said it would = avoid > > > the need > > > for figuring out how to carry a new marking (like RTP header = extensions). > > > > > > But: There are no existing DSCP with the PHB of = "intra-flow-priority" with > > > a > > > guarantee that flows with different distributions of those = priorities > > > would see > > > the same percentage of drops under queue congestion. > > > > > > If we wanted to go the DSCP route, we would need at least 3 new = DSCP to > > > indicate > > > high,normal,low intra-flow priority (and just for intelligent = dropping, 3 > > > actually > > > might be good enough). But 3 new DSCP is an act of god in the = IETF. > > > > > > Then those three new DSCP would not only have to indicate = intra-flow > > > priority but > > > also the overall class PHB that the traffic should have even = without > > > priority > > > indications. Aka: lets say low loss, low latency, appropriate for = RMcat. > > > So when the next class of traffic with different intra-flow = priorities > > > comes > > > along, we'd have to redo the whole DSCP exercise again. And again. > > > > > > And then the DSCP still get reset along the path, and apps still = have > > > problems > > > setting DSCP across various OSs. > > > > > > Cheers > > > Toerless > > > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > > > Maybe I skimmed it too quickly but my understanding is that the = proposal > > > is > > > > to remark DSCP values at the ingress point of the network and = possibly at > > > > other key boundaries too. Such DSCP remapping is already common = practice > > > in > > > > enterprise networks. > > > > > > > > The twist here is that the remapper will do the remapping = dynamically > > > based > > > > on the proportion of AFn1, AFn2 and AFn3 packets received from a = sender. > > > A > > > > greedy sender that it producing only AF41 markings will get some = of those > > > > randomly remarked as AF42 and AF43. > > > > > > > > The proposal uses existing DSCP values and it doesn't look like = signaling > > > > is necessary nor is it necessary for the application to know = that this is > > > > happening. > > > > > > > > Kevin Gross > > > > +1-303-447-0517 > > > > Media Network Consultant > > > > AVA Networks - www.AVAnw.com > > > > > > > > > > > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl = > > > wrote: > > > > > > > > > Hmm. Whether the balance is right or not might depend on how = the > > > signaling > > > > > is done. Anyway, unless I misunderstood something, the way the > > > normalizer > > > > > now stands it won't really make a change: it gives an = incentive to > > > > > applications to mark some packets with higher drop precedence, = yet > > > requires > > > > > applications to know that the normalizer is in place or else = the > > > service > > > > > would be different. > > > > > > > > > > Maybe different DSCP values would be needed - but then this = can't be > > > used > > > > > in combination with "regular" DiffServ usage. It really = depends on the > > > > > signaling - ideas are now being tossed around by Colin and = Toerless, > > > who > > > > > clearly both know more about what the right signaling could be = than me. > > > > > > > > > > Cheers, > > > > > Michael > > > > > > > > > > > > > > > On 15. okt. 2013, at 19:04, Kevin Gross = wrote: > > > > > > > > > > I think you're stretching here. I don't think the balance is = right. The > > > > > proposed information is difficult to retrieve and of little = use to > > > much of > > > > > the network. Even if standardized, it is unlikely to be = successful. > > > > > > > > > > The ideas in the normalizer draft don't seem to have so many = issues > > > and I > > > > > think it answers your original question and sets out to = achieve what > > > you're > > > > > looking for. > > > > > > > > > > Kevin Gross > > > > > +1-303-447-0517 > > > > > Media Network Consultant > > > > > AVA Networks - www.AVAnw.com > > > > > > > > > > > > > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl = > > > wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I'll dissect your second and third sentences and tell you = what I think > > > > >> about each part :-) below: > > > > >> > > > > >> > > > > >> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > > > >> > > > > >> > No, not per 5 tuple (per flow). I don't think that is = something we > > > > >> should ask of the network. > > > > >> > > > > >> I agree that asking this of the network may seem like = encouraging > > > > >> per-flow functionality; in particular, if we'd put this into = IP, that > > > would > > > > >> be ugly. However, it's just a matter of fact that there are = devices > > > that do > > > > >> identify flows, and then, why not give such devices some = guidance? I > > > like > > > > >> Toerless' suggestion of making this an RTP header extension = field: if > > > a > > > > >> device is identifying flows, we can expect such a device to = identify > > > such a > > > > >> field too. Plus, if we think of end systems playing an = intermediate > > > system > > > > >> role in RTP (mixers, ..), these devices might also benefit = from that > > > sort > > > > >> of information. > > > > >> > > > > >> > > > > >> > It doesn't sit well with the end-to-end principle > > > > >> > > > > >> I disagree, this is an all-too-common misunderstanding of the > > > end-to-end > > > > >> principle: it only says that whatever can be done in the = application > > > should > > > > >> be left up to the application, but it doesn't say that you = mustn't > > > identify > > > > >> application streams inside the network or "keep the network = simple and > > > > >> stupid". If you do "keep the network stupid", you're = definitely in > > > line > > > > >> with the e2e argument, but the argument isn't as strict as = that (a > > > typical > > > > >> example is routing, which can well become as complex as you = wish, > > > without > > > > >> harming the end-to-end principle). Now here we're discussing = a > > > function > > > > >> where the application really can't help you: when congestion = happens > > > inside > > > > >> the network and a packet must be dropped there, the best the > > > application > > > > >> can do is tell you which packet to drop. > > > > >> > > > > >> > > > > >> > and it won't scale. > > > > >> > > > > >> I agree. But it doesn't have to, just because we introduce = the signal > > > we > > > > >> don't harm scalability - devices at the edges of the network = could > > > deal > > > > >> with it, all other devices could ignore it. > > > > >> > > > > >> Cheers, > > > > >> Michael > > > > >> > > > > >> > > > > > > > > > > > > > > > > -- > > > --- > > > Toerless Eckert, eckert@cisco.com > > > Cisco NSSTG Systems & Technology Architecture > > > SDN: Let me play with the network, mommy! > > > > > > >=20 > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 >=20 --Apple-Mail=_DE58D3AC-4F90-431D-95C7-97CA61F043DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

***
      = Flow A

         80% or = 4Mbps in AF41

        =  20% or 1Mbps in AF42

      =     0% or 0Mbps in = AF43
***

...then this someone (flow = A) would be better off in the presence of congestion, as described in = the draft. This means that you'll never decide for a profile as in Flow = B in your application because you could hurt yourself, you might be = treated worse than some other users.

This is = what the normalizer fixes, but as long as you don't know it's there, = going for a profile as in Flow B is still risky = business.

"You" in my story here is the = application programmer, and it really has to be the application = programmer doing this - the priorities would be derived from knowledge = about the codec, FEC usage etc. What the application programmer needs is = a signal that is definitely going to be ignored unless it hits a = normalizing ingress = device.

Cheers,
Michael
=


On 16. okt. 2013, at 05:31, = Kevin Gross wrote:

As I read it, the proposal in the draft is to have network = equipment tweak DSCP values at ingress points so that drop precedence = proportions are normalized in some way. This does not require that all = senders produce normalized streams. The only thing that needs to be = accepted is common normalization profiles for all the ingress points in = the network. Under the proposal, useful drop precedence behavior becomes = a network configuration issue, not a standards compliance issue.

Kevin = Gross
+1-303-447-0517
Media Network = Consultant
AVA Networks - www.AVAnw.com


On Tue, Oct 15, 2013 at 8:13 PM, = Toerless Eckert <eckert@cisco.com> wrote:
Partially true IMHO.

Yes, if we could have all flows agree to have a marking let's say 20% = high,
60% normal and 20% low prio bits (long term average), then we would = not
need normalization. If there is any chance to establish such a standard, = that
would be gret.

It just doesn't change the problem of DSCP. It would change the PHB = though
by making it much more strict. Which makes it more questionable whether = it
would be accepted.


Cheers
    = Toerless


On Tue, Oct 15, 2013 at 07:34:18PM -0600, Kevin Gross wrote:
> If we create a situation where all flows are "normalized" (i.e. a = certain
> percentage of their packets are marked with higher drop precedence) = by the
> network then we shouldn't have to deal with things on a per-flow = basis. If
> we're not dealing with things on a per-flow basis, we can use the = existing
> AF codepoints. Dropping according to drop precedence markings on a = class
> basis should be statistically fair to all flows so long as all = flows have
> been normalized.
>
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com = <http://www.avanw.com/>
>
>
> On Tue, Oct 15, 2013 at 6:23 PM, Toerless Eckert <eckert@cisco.com> wrote:
>
> > The method described in the draft is applicable to whatever = marking one
> > wants
> > to use. I wish DSCP was the solution because as you said it = would avoid
> > the need
> > for figuring out how to carry a new marking (like RTP header = extensions).
> >
> > But: There are no existing DSCP with the PHB of = "intra-flow-priority" with
> > a
> > guarantee that flows with different distributions of those = priorities
> > would see
> > the same percentage of drops under queue congestion.
> >
> > If we wanted to go the DSCP route, we would need at least 3 = new DSCP to
> > indicate
> > high,normal,low intra-flow priority (and just for intelligent = dropping, 3
> > actually
> > might be good enough). But 3 new DSCP is an act of god in the = IETF.
> >
> > Then those three new DSCP would not only have to indicate = intra-flow
> > priority but
> > also the overall class PHB that the traffic should have even = without
> > priority
> > indications. Aka: lets say low loss, low latency, appropriate = for RMcat.
> > So when the next class of traffic with different intra-flow = priorities
> > comes
> > along, we'd have to redo the whole DSCP exercise again. And = again.
> >
> > And then the DSCP still get reset along the path, and apps = still have
> > problems
> > setting DSCP across various OSs.
> >
> > Cheers
> >     Toerless
> >
> > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross = wrote:
> > > Maybe I skimmed it too quickly but my understanding is = that the proposal
> > is
> > > to remark DSCP values at the ingress point of the network = and possibly at
> > > other key boundaries too. Such DSCP remapping is already = common practice
> > in
> > > enterprise networks.
> > >
> > > The twist here is that the remapper will do the remapping = dynamically
> > based
> > > on the proportion of AFn1, AFn2 and AFn3 packets received = from a sender.
> > A
> > > greedy sender that it producing only AF41 markings will = get some of those
> > > randomly remarked as AF42 and AF43.
> > >
> > > The proposal uses existing DSCP values and it doesn't = look like signaling
> > > is necessary nor is it necessary for the application to = know that this is
> > > happening.
> > >
> > > Kevin Gross
> > > +1-303-447-0517
> > > Media Network Consultant
> > > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> > >
> > >
> > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl <michawe@ifi.uio.no>
> > wrote:
> > >
> > > > Hmm. Whether the balance is right or not might = depend on how the
> > signaling
> > > > is done. Anyway, unless I misunderstood something, = the way the
> > normalizer
> > > > now stands it won't really make a change: it gives = an incentive to
> > > > applications to mark some packets with higher drop = precedence, yet
> > requires
> > > > applications to know that the normalizer is in place = or else the
> > service
> > > > would be different.
> > > >
> > > > Maybe different DSCP values would be needed - but = then this can't be
> > used
> > > > in combination with "regular" DiffServ usage. It = really depends on the
> > > > signaling - ideas are now being tossed around by = Colin and Toerless,
> > who
> > > > clearly both know more about what the right = signaling could be than me.
> > > >
> > > > Cheers,
> > > > Michael
> > > >
> > > >
> > > > On 15. okt. 2013, at 19:04, Kevin Gross <kevin.gross@avanw.com> = wrote:
> > > >
> > > > I think you're stretching here. I don't think the = balance is right. The
> > > > proposed information is difficult to retrieve and of = little use to
> > much of
> > > > the network. Even if standardized, it is unlikely to = be successful.
> > > >
> > > > The ideas in the normalizer draft don't seem to have = so many issues
> > and I
> > > > think it answers your original question and sets out = to achieve what
> > you're
> > > > looking for.
> > > >
> > > > Kevin Gross
> > > > +1-303-447-0517
> > > > Media Network Consultant
> > > > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> > > >
> > > >
> > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl = <michawe@ifi.uio.no>
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I'll dissect your second and third sentences and = tell you what I think
> > > >> about each part  :-)   below:
> > > >>
> > > >>
> > > >> On 14. okt. 2013, at 23:35, Kevin Gross = wrote:
> > > >>
> > > >> > No, not per 5 tuple (per flow). I don't = think that is something we
> > > >> should ask of the network.
> > > >>
> > > >> I agree that asking this of the network may seem = like encouraging
> > > >> per-flow functionality; in particular, if we'd = put this into IP, that
> > would
> > > >> be ugly. However, it's just a matter of fact = that there are devices
> > that do
> > > >> identify flows, and then, why not give such = devices some guidance?  I
> > like
> > > >> Toerless' suggestion of making this an RTP = header extension field: if
> > a
> > > >> device is identifying flows, we can expect such = a device to identify
> > such a
> > > >> field too. Plus, if we think of end systems = playing an intermediate
> > system
> > > >> role in RTP (mixers, ..), these devices might = also benefit from that
> > sort
> > > >> of information.
> > > >>
> > > >>
> > > >> > It doesn't sit well with the end-to-end = principle
> > > >>
> > > >> I disagree, this is an all-too-common = misunderstanding of the
> > end-to-end
> > > >> principle: it only says that whatever can be = done in the application
> > should
> > > >> be left up to the application, but it doesn't = say that you mustn't
> > identify
> > > >> application streams inside the network or "keep = the network simple and
> > > >> stupid". If you do "keep the network stupid", = you're definitely in
> > line
> > > >> with the e2e argument, but the argument isn't as = strict as that (a
> > typical
> > > >> example is routing, which can well become as = complex as you wish,
> > without
> > > >> harming the end-to-end principle). Now here = we're discussing a
> > function
> > > >> where the application really can't help you: = when congestion happens
> > inside
> > > >> the network and a packet must be dropped there, = the best the
> > application
> > > >> can do is tell you which packet to drop.
> > > >>
> > > >>
> > > >> > and it won't scale.
> > > >>
> > > >> I agree. But it doesn't have to, just because we = introduce the signal
> > we
> > > >> don't harm scalability - devices at the edges of = the network could
> > deal
> > > >> with it, all other devices could ignore it.
> > > >>
> > > >> Cheers,
> > > >> Michael
> > > >>
> > > >>
> > > >
> > > >
> >
> > --
> > ---
> > Toerless Eckert, eckert@cisco.com
> > Cisco NSSTG Systems & Technology Architecture
> > SDN: Let me play with the network, mommy!
> >
> >

--
---
Toerless Eckert, eckert@cisco.com
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!



= --Apple-Mail=_DE58D3AC-4F90-431D-95C7-97CA61F043DC-- From roland.bless@kit.edu Wed Oct 16 01:22:33 2013 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 D506B21F9A6A; Wed, 16 Oct 2013 01:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKNZAQSBYNqL; Wed, 16 Oct 2013 01:22:25 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 893AF21F9E7E; Wed, 16 Oct 2013 01:21:53 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1VWMML-0004vz-Ju; Wed, 16 Oct 2013 10:21:41 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 611ACA80445; Wed, 16 Oct 2013 10:21:42 +0200 (CEST) Message-ID: <525E4C96.2010102@kit.edu> Date: Wed, 16 Oct 2013 10:21:42 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Michael Welzl , Kevin Gross References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> In-Reply-To: <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1381911701. X-Mailman-Approved-At: Wed, 16 Oct 2013 01:38:03 -0700 Cc: Bernard Aboba , rmcat WG , tsv-area@ietf.org Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 08:22:33 -0000 Hi Michael, On 16.10.2013 09:36, Michael Welzl wrote: > [I'm adding tsv-area: I noticed it was dropped from some part of this > thread, but I think unintentionally? BTW I hope tsv-area is appropriate, > and not tsvwg? I started off to rmcat and tsv-area because I had a > general DiffServ'ish question, yet related to rmcat, and so I thought > this would fit.] Yes, I'm following this on TSVAREA since I'm not subscribed on rmcat yet. > ...then this someone (flow A) would be better off in the presence of > congestion, as described in the draft. This means that you'll never > decide for a profile as in Flow B in your application because you could > hurt yourself, you might be treated worse than some other users. > > This is what the normalizer fixes, but as long as you don't know it's > there, going for a profile as in Flow B is still risky business. > > "You" in my story here is the application programmer, and it really has > to be the application programmer doing this - the priorities would be > derived from knowledge about the codec, FEC usage etc. What the > application programmer needs is a signal that is definitely going to be > ignored unless it hits a normalizing ingress device. Just some few observations from my point of view: - DiffServ doesn't distinguish between individual flows within a behavior aggregate - it was intentionally designed that way. Per micro-flow unfairness within the same class is not prevented by DiffServ - conceptionally you should only use the first-hop router for this kind of traffic conditioning measures. However, this doesn't help to prevent other aggregation effects inside a DiffServ domain (cf. Per-Hop Behavior vs. Per Domain Behavior). - Following the end-to-end argument, it doesn't make sense to build somewhat complex mechanisms into the network, which may even depend on the particular application (like WebRTC etc.) - so building a "normalizer" (w/o having fully understood the concept) into the network doesn't seem to be the right approach in the long run. - Therefore, I agree very much with your last statement: it's only the application that has the knowledge and context to set any kind of forwarding priority (or drop precendence) for individual packets correctly. Especially, the logic to react on dropped packets should reflect the marking and corresponding dropping behavior. Regards, Roland From michawe@ifi.uio.no Wed Oct 16 01:49:20 2013 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 9135E11E8167; Wed, 16 Oct 2013 01:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwKNn1T3leXk; Wed, 16 Oct 2013 01:49:16 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 6369C11E811B; Wed, 16 Oct 2013 01:49:15 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VWMmu-0004LA-N7; Wed, 16 Oct 2013 10:49:04 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VWMmt-0001Wh-Tw; Wed, 16 Oct 2013 10:49:04 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_AA588AFE-C7D5-4736-8F64-81CCBFDC918F" From: Michael Welzl In-Reply-To: <525E4C96.2010102@kit.edu> Date: Wed, 16 Oct 2013 10:49:02 +0200 Message-Id: References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> <525E4C96.2010102@kit.edu> To: "Bless, Roland (TM)" X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 15 sum msgs/h 6 total rcpts 8630 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A1829A9EEAA0737530720645FBC6E37697756E8B X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 3369 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: Bernard Aboba , rmcat WG , tsv-area@ietf.org, Kevin Gross Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 08:49:20 -0000 --Apple-Mail=_AA588AFE-C7D5-4736-8F64-81CCBFDC918F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 16. okt. 2013, at 10:21, Bless, Roland (TM) wrote: > Hi Michael, >=20 > On 16.10.2013 09:36, Michael Welzl wrote: >> [I'm adding tsv-area: I noticed it was dropped from some part of this >> thread, but I think unintentionally? BTW I hope tsv-area is = appropriate, >> and not tsvwg? I started off to rmcat and tsv-area because I had a >> general DiffServ'ish question, yet related to rmcat, and so I thought >> this would fit.] >=20 > Yes, I'm following this on TSVAREA since I'm not subscribed on rmcat = yet. ... and dropping tsv-area was a mistake, as your message shows :( = 'cause we've been around this block I think... >> ...then this someone (flow A) would be better off in the presence of >> congestion, as described in the draft. This means that you'll never >> decide for a profile as in Flow B in your application because you = could >> hurt yourself, you might be treated worse than some other users. >>=20 >> This is what the normalizer fixes, but as long as you don't know it's >> there, going for a profile as in Flow B is still risky business. >>=20 >> "You" in my story here is the application programmer, and it really = has >> to be the application programmer doing this - the priorities would be >> derived from knowledge about the codec, FEC usage etc. What the >> application programmer needs is a signal that is definitely going to = be >> ignored unless it hits a normalizing ingress device. >=20 > Just some few observations from my point of view: > - DiffServ doesn't distinguish between individual flows within > a behavior aggregate - it was intentionally designed that way. > Per micro-flow unfairness within the same class is not prevented > by DiffServ - conceptionally you should only use the first-hop router > for this kind of traffic conditioning measures. However, this doesn't > help to prevent other aggregation effects inside a DiffServ domain > (cf. Per-Hop Behavior vs. Per Domain Behavior). Sure- > - Following the end-to-end argument, it doesn't make sense to build > somewhat complex mechanisms into the network, which may even depend > on the particular application (like WebRTC etc.) - so building a > "normalizer" (w/o having fully understood the concept) into the > network doesn't seem to be the right approach in the long run. I disagree with what you say about e2e, see: http://www.ietf.org/mail-archive/web/rmcat/current/msg00519.html but anyway that's a separate debate, as the normalizer draft works on = aggregates and is really compliant with DiffServ as far as I can tell. That's the draft we're debating here: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 > - Therefore, I agree very much with your last statement: it's only > the application that has the knowledge and context to set any > kind of forwarding priority (or drop precendence) for individual > packets correctly. > Especially, the logic to react on dropped packets should reflect > the marking and corresponding dropping behavior. Yeah, the issue we're debating is that an application won't have an = incentive to go for the profile of Flow B (page 4 of the draft) unless = it knows that the normalizer is there, because otherwise it could get = treated in the normal DiffServ way and that would make it worse off than = Flow A (page 4 of the draft). Thus you need a way for the application to = signal intra-flow packet priorities to an edge without "standard = DiffServ" operating on that signal. The signal must be ignored unless = the normalizer is there. I hope that helped to clarify the discussion a bit... Cheers, Michael --Apple-Mail=_AA588AFE-C7D5-4736-8F64-81CCBFDC918F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi Michael,

On 16.10.2013 09:36, Michael Welzl = wrote:
[I'm adding tsv-area: I noticed it = was dropped from some part of this
thread, but I think unintentionally? BTW I hope tsv-area = is appropriate,
and not tsvwg? = I started off to rmcat and tsv-area because I had = a
general DiffServ'ish = question, yet related to rmcat, and so I = thought
this would = fit.]

Yes, I'm following this on TSVAREA since I'm = not subscribed on rmcat yet.

... = and dropping tsv-area was a mistake, as your message shows  :( =   'cause we've been around this block I = think...


...then this someone (flow = A) would be better off in the presence of
congestion, as described in the draft. This means that = you'll never
decide for a = profile as in Flow B in your application because you = could
hurt yourself, you might = be treated worse than some other users.

This is what = the normalizer fixes, but as long as you don't know = it's
there, going for a = profile as in Flow B is still risky = business.

"You" in my = story here is the application programmer, and it really = has
to be the application = programmer doing this - the priorities would = be
derived from knowledge = about the codec, FEC usage etc. What the
application programmer needs is a signal that is = definitely going to be
ignored = unless it hits a normalizing ingress device.

Just = some few observations from my point of view:
- DiffServ doesn't = distinguish between individual flows within
 a behavior = aggregate - it was intentionally designed that way.
 Per = micro-flow unfairness within the same class is not prevented
=  by DiffServ - conceptionally you should only use the first-hop = router
 for this kind of traffic conditioning measures. = However, this doesn't
 help to prevent other aggregation = effects inside a DiffServ domain
 (cf. Per-Hop Behavior vs. Per = Domain = Behavior).

Sure-

=

- Following the end-to-end = argument, it doesn't make sense to build
 somewhat complex = mechanisms into the network, which may even depend
 on the = particular application (like WebRTC etc.) - so building a
=  "normalizer" (w/o having fully understood the concept) into = the
 network doesn't seem to be the right approach in the long = run.

I disagree with what you = say about e2e, see:
=
but anyway that's a separate debate, as the normalizer draft works = on aggregates and is really compliant with DiffServ as far as I can = tell.
That's the draft we're debating here:

<= div>
- Therefore, I agree = very much with your last statement: it's only
 the application = that has the knowledge and context to set any
 kind of = forwarding priority (or drop precendence) for individual
=  packets correctly.
 Especially, the logic to react on = dropped packets should reflect
 the marking and corresponding = dropping behavior.

Yeah, the = issue we're debating is that an application won't have an incentive to = go for the profile of Flow B (page 4 of the draft) unless it knows that = the normalizer is there, because otherwise it could get treated in the = normal DiffServ way and that would make it worse off than Flow A (page 4 = of the draft). Thus you need a way for the application to signal = intra-flow packet priorities to an edge without "standard DiffServ" = operating on that signal. The signal must be ignored unless the = normalizer is there.

I hope that helped to clarify = the discussion a = bit...

Cheers,
Michael

= --Apple-Mail=_AA588AFE-C7D5-4736-8F64-81CCBFDC918F-- From gorius@nt.uni-saarland.de Wed Oct 16 02:05:32 2013 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 30F5C21F9C0E for ; Wed, 16 Oct 2013 02:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jape97Qtnlrt for ; Wed, 16 Oct 2013 02:05:26 -0700 (PDT) Received: from theia.rz.uni-saarland.de (theia.rz.uni-saarland.de [134.96.7.31]) by ietfa.amsl.com (Postfix) with ESMTP id 50E5F11E82AB for ; Wed, 16 Oct 2013 02:05:23 -0700 (PDT) Received: from dhcp86-91.nt.uni-saarland.de (dhcp86-91.nt.uni-saarland.de [134.96.86.91]) (authenticated bits=0) by theia.rz.uni-saarland.de (8.14.1/8.14.0) with ESMTP id r9G95IPv006266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Oct 2013 11:05:19 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Manuel Gorius In-Reply-To: Date: Wed, 16 Oct 2013 11:05:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F0A5342-E5EF-44DD-94C2-9EB97FFE3A07@netapp.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39A74E@ESESSMB205.ericsson.se> <4FC1F85139E6FE4D9A55BD6798B29A4816AD20A5@NASANEXD02B.na.qualcomm.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39B113@ESESSMB205.ericsson.se> To: Michael Welzl X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (theia.rz.uni-saarland.de [134.96.7.31]); Wed, 16 Oct 2013 11:05:19 +0200 (CEST) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-14; AVE: 7.9.10.68; VDF: 7.11.99.164; host: AntiVir1) Cc: Ingemar Johansson S , "Van Der Auwera, Geert" , "Eggert, Lars" , rmcat WG Subject: Re: [rmcat] draft-vanderauwera-rmcat-video-quality X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 09:05:32 -0000 On 16.10.2013, at 09:06, Michael Welzl wrote: >=20 > On 16. okt. 2013, at 08:42, Ingemar Johansson S wrote: >=20 >> Hi >>=20 >> Thanks for the reply. >> I assumed 1500byte packeys which gives almost 400ms delay.=20 >> As I see it it seems a bit pessimistic with a ratio 30-40 between = latency under load and min RTT.=20 >> I am fully aware of the bufferbloat problem but isn't there a risk = that this becomes a corner case and that it might drive designs in a = direction that makes them suboptimal for the main operating conditions. >>=20 >> To take an example: In order for the RMCAT flow to be able to compete = with an FTP using TCP Reno or Cubic over this bottleneck, it becomes = necessary that the RMCAT flow contributes to the bufferbloat for = instance by increasing a target delay or whatever. Unless the RMCAT flow = gets some magic information from the network, it needs to infer = information about the existence of competing flows, it can work more or = less well and I see before be a lot of special code to do this, some of = it actually becomes engineered to solve this particular test case.=20 >=20 > Measured delay can serve as this "magic information"... >=20 >=20 >> The problem with this is that this added intelligence can actually = increase the risk that the RMCAT flow it self creates self-inflicted = congestion due to faulty decisions, meaning that the RMCAT flow it self = locks it self in 400ms RTT even though there is no competing traffic. >=20 > That would be the result of a badly designed congestion controller. I = don't think that this naturally follows from trying to minimize delay, = yet compete with TCP when it is present. >=20 Designing a sophisticated congestion controller in order to address this = problem is still challenging, though (are there any such solutions = available so far?). We performed experiments with delay-based congestion = control where we ran into exactly the same issue: The intensity of the = delay-based flows had to be increased in order to compete with = loss-based TCP-flows in environments with huge buffers. At the same time = it is probably desirable that the queues aren't filled excessively in = case there is only delay-controlled traffic. I think for a delay-based = decision, the controller has to learn the range of the delay variation = in such environments (maybe incorporating loss-based feedback as well) = and must derive a suitable weighting for the congestion feedback in = order to keep the flow competitive under an increasing number of = loss-based flows. Having a mixture of loss- and delay-based feedback = could solve the problem of self-inflicted congestion in my opinion. Best regards, Manuel From eckert@cisco.com Wed Oct 16 10:53:59 2013 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 16DDD11E82F3 for ; Wed, 16 Oct 2013 10:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.178 X-Spam-Level: X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZf-BmtTg5WG for ; Wed, 16 Oct 2013 10:53:42 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4991C21F9E6C for ; Wed, 16 Oct 2013 10:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7935; q=dns/txt; s=iport; t=1381946000; x=1383155600; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=2mi8Wkcyh6sG7oZxOcrdLFanqPtLeJByRebmn8wSXtg=; b=ZrcH57ZInr+MuyU4iv0fSaYTuVvWY6ANlChbXaTd8A8D1ddNsZY5Y4xg lcDV+ywCj5NzxjfC5/mHYJYmCE8mpCHNeEIAsdlAM52U/NTLmBAn5X+v5 MOwCfWcbGtReuV2Kt+QtF/1xTWfiUpqV7Dds+nN14yWzvvOKa2XMDLIYQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFANnRXlKrRDoI/2dsb2JhbABQBwODBzjADIEeFnSCJQEBAQMBDiwPHAISBQsLBwcKCSUPBUkTiAAFv0iODoEzEAcRgw6BBgOJPIprg1wBkgKDRBw X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="94865769" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 16 Oct 2013 17:53:18 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9GHrIQp027392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Oct 2013 17:53:18 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9GHrHN2028795; Wed, 16 Oct 2013 10:53:17 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9GHrGe4028793; Wed, 16 Oct 2013 10:53:16 -0700 Date: Wed, 16 Oct 2013 10:53:16 -0700 From: Toerless Eckert To: Michael Welzl Message-ID: <20131016175316.GA26546@cisco.com> References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Bernard Aboba , rmcat WG , Kevin Gross Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 17:53:59 -0000 On Wed, Oct 16, 2013 at 09:22:00AM +0200, Michael Welzl wrote: > ....so we'd really need "intra-flow drop precedence" bits, to inter-work with existing DSCP values and get the expected PHB, right? > (or do as you say, define the PHB + precedence, for all possible combinations) Right. And independent of those intra-flow priority bits there is IMHO still the open question whether the existing DSCP/PHB best suit what we would want for RMcat. > > And then the DSCP still get reset along the path, and apps still have problems > > setting DSCP across various OSs. > > There is also an architectural side to it: Kevin rightfully started this conversation by saying: "No, not per 5 tuple (per flow). I don't think that is something we should ask of the network." > Indeed, doing this right *requires* routers (or whatever box does that) to identify flows and keep track of them. Such per-flow functionality isn't what we want "normal" routers to do, I think, and so binding DSCP values to such a functionality just seems wrong to me. In a way, it makes the IP header less self-contained: in order to implement all the functions encoded in it, you need to look beyond the IP header. This doesn't strike me as good design. Flow-awareness is not evil, and there are a lot more proof points of deployment where it works and scales than IMHO places where its needed and does not scale. All enterprise routers i know do heavily leverage flow awareness. Flow awareness for intra-flow priority can easily be designed to require the same amount of flow awareness as existing QoS problems. Specifically for QoS-authorization on the edge (and for intra-flow priority, that authorization could mean normalization). I think that's waht you're also saying below. > I think it's not too much to ask of devices that identify flows to look beyond the IP header for a shim, RTP-something, or whatever we define. Then, this device can aggregate flows into the right DSCPs if it knows that traffic's going to traverse a path where the normalizer is present - and the normalizing devices again only need to look at the IP header, where it's all per-aggregate. > (sorry for repeating myself, I thought I'd say this again here just for context, but I did say this before) Right. There is also some fundamental insight into what a "correct" layer is that i think the IETF is missing. With IPv6, they just carried over the IPv4 design without reviewing why router-alert and IP packet options didn't catch on in IPv4 for onpath operations. After 30 years regurgitating what's not working, it's IMHO rally time to give IETF blessings to some other approach, and clean well reviewed designs with such network aware extensions in the transport layer IMHO is exactly that (whether it's shim layer, SCTP extensions, RTP header extension or what hae you - that's just a mattter of use-case priorities). Cheers toerless Cheers, > Michael > > > > > > > > Cheers > > Toerless > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > >> Maybe I skimmed it too quickly but my understanding is that the proposal is > >> to remark DSCP values at the ingress point of the network and possibly at > >> other key boundaries too. Such DSCP remapping is already common practice in > >> enterprise networks. > >> > >> The twist here is that the remapper will do the remapping dynamically based > >> on the proportion of AFn1, AFn2 and AFn3 packets received from a sender. A > >> greedy sender that it producing only AF41 markings will get some of those > >> randomly remarked as AF42 and AF43. > >> > >> The proposal uses existing DSCP values and it doesn't look like signaling > >> is necessary nor is it necessary for the application to know that this is > >> happening. > >> > >> Kevin Gross > >> +1-303-447-0517 > >> Media Network Consultant > >> AVA Networks - www.AVAnw.com > >> > >> > >> On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl wrote: > >> > >>> Hmm. Whether the balance is right or not might depend on how the signaling > >>> is done. Anyway, unless I misunderstood something, the way the normalizer > >>> now stands it won't really make a change: it gives an incentive to > >>> applications to mark some packets with higher drop precedence, yet requires > >>> applications to know that the normalizer is in place or else the service > >>> would be different. > >>> > >>> Maybe different DSCP values would be needed - but then this can't be used > >>> in combination with "regular" DiffServ usage. It really depends on the > >>> signaling - ideas are now being tossed around by Colin and Toerless, who > >>> clearly both know more about what the right signaling could be than me. > >>> > >>> Cheers, > >>> Michael > >>> > >>> > >>> On 15. okt. 2013, at 19:04, Kevin Gross wrote: > >>> > >>> I think you're stretching here. I don't think the balance is right. The > >>> proposed information is difficult to retrieve and of little use to much of > >>> the network. Even if standardized, it is unlikely to be successful. > >>> > >>> The ideas in the normalizer draft don't seem to have so many issues and I > >>> think it answers your original question and sets out to achieve what you're > >>> looking for. > >>> > >>> Kevin Gross > >>> +1-303-447-0517 > >>> Media Network Consultant > >>> AVA Networks - www.AVAnw.com > >>> > >>> > >>> On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl wrote: > >>> > >>>> Hi, > >>>> > >>>> I'll dissect your second and third sentences and tell you what I think > >>>> about each part :-) below: > >>>> > >>>> > >>>> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > >>>> > >>>>> No, not per 5 tuple (per flow). I don't think that is something we > >>>> should ask of the network. > >>>> > >>>> I agree that asking this of the network may seem like encouraging > >>>> per-flow functionality; in particular, if we'd put this into IP, that would > >>>> be ugly. However, it's just a matter of fact that there are devices that do > >>>> identify flows, and then, why not give such devices some guidance? I like > >>>> Toerless' suggestion of making this an RTP header extension field: if a > >>>> device is identifying flows, we can expect such a device to identify such a > >>>> field too. Plus, if we think of end systems playing an intermediate system > >>>> role in RTP (mixers, ..), these devices might also benefit from that sort > >>>> of information. > >>>> > >>>> > >>>>> It doesn't sit well with the end-to-end principle > >>>> > >>>> I disagree, this is an all-too-common misunderstanding of the end-to-end > >>>> principle: it only says that whatever can be done in the application should > >>>> be left up to the application, but it doesn't say that you mustn't identify > >>>> application streams inside the network or "keep the network simple and > >>>> stupid". If you do "keep the network stupid", you're definitely in line > >>>> with the e2e argument, but the argument isn't as strict as that (a typical > >>>> example is routing, which can well become as complex as you wish, without > >>>> harming the end-to-end principle). Now here we're discussing a function > >>>> where the application really can't help you: when congestion happens inside > >>>> the network and a packet must be dropped there, the best the application > >>>> can do is tell you which packet to drop. > >>>> > >>>> > >>>>> and it won't scale. > >>>> > >>>> I agree. But it doesn't have to, just because we introduce the signal we > >>>> don't harm scalability - devices at the edges of the network could deal > >>>> with it, all other devices could ignore it. > >>>> > >>>> Cheers, > >>>> Michael > >>>> From roland.bless@kit.edu Wed Oct 16 12:43:35 2013 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 3A56F11E82B0; Wed, 16 Oct 2013 12:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPYrHkj3SjdS; Wed, 16 Oct 2013 12:43:30 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE2B11E81DB; Wed, 16 Oct 2013 12:43:23 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1VWWzv-00061q-HU; Wed, 16 Oct 2013 21:43:13 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 0F70BA806BD; Wed, 16 Oct 2013 21:43:17 +0200 (CEST) Message-ID: <525EEC54.7050003@kit.edu> Date: Wed, 16 Oct 2013 21:43:16 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Michael Welzl References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> <525E4C96.2010102@kit.edu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1381952594. Cc: Bernard Aboba , rmcat WG , tsv-area@ietf.org, Kevin Gross Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 19:43:35 -0000 Hi Michael and all, Am 16.10.2013 10:49, schrieb Michael Welzl: >> - Following the end-to-end argument, it doesn't make sense to build >> somewhat complex mechanisms into the network, which may even depend >> on the particular application (like WebRTC etc.) - so building a >> "normalizer" (w/o having fully understood the concept) into the >> network doesn't seem to be the right approach in the long run. > > I disagree with what you say about e2e, see: > http://www.ietf.org/mail-archive/web/rmcat/current/msg00519.html > but anyway that's a separate debate, as the normalizer draft works on > aggregates and is really compliant with DiffServ as far as I can tell. > That's the draft we're debating here: > http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 Thanks for the pointer, I quickly read over it. My understanding is: if we have an example flow of AF41:AF42:AF43 80:20:0 the normalizer would reassign those packets to 40:20:20 (or whatever the configured proportion is). Is this perception correct? Regarding the e2e argument: - you said "it only says that whatever can be done in the application should be left up to the application" - I don't think this catches the gist of it: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible". => especially, application knowledge is often required when reacting on failures, i.e., the right decision cannot be made when implemented within the network. Thus, dropping packets according to the markings set by the application is fully in accordance with the e2e argument, whereas building marking mechanisms into the network that require application knowledge is usually not in accordance with it. - if I understood the normalizer proposal in draft-lai-tsvwg-normalizer-02 correctly, it is not in line with the e2e argument since it reassigns drop precedences without application knowledge. Thus, it may make the wrong decisions about the importance of packets, not knowing how apps react to loss. >> - Therefore, I agree very much with your last statement: it's only >> the application that has the knowledge and context to set any >> kind of forwarding priority (or drop precendence) for individual >> packets correctly. >> Especially, the logic to react on dropped packets should reflect >> the marking and corresponding dropping behavior. > > Yeah, the issue we're debating is that an application won't have an > incentive to go for the profile of Flow B (page 4 of the draft) unless > it knows that the normalizer is there, because otherwise it could get > treated in the normal DiffServ way and that would make it worse off than > Flow A (page 4 of the draft). Thus you need a way for the application to > signal intra-flow packet priorities to an edge without "standard > DiffServ" operating on that signal. The signal must be ignored unless > the normalizer is there. > > I hope that helped to clarify the discussion a bit... Thanks, I think I understand the rationale now. However, I see several potential problems with this approach and have some thoughts to share as well: 0) I think an application with a 40:20:20 assignment has no real problem if it experiences loss in PHBs AFx2, AFx3 since it was designed that way. Whether it's "unfair" w.r.t. to other streams doesn't really matter. Remember that QoS support is usually managed unfairness anyway. Fairness within AF usually matters for the "yellow" packets, e.g., AFx2. This excess bandwidth should be fairly shared among all streams in this AF class if possible. 1) reassignment of drop precedences w/o application knowledge 2) how can one find the right default proportions suitable for different streams or applications? 3) Is this AF PHB class restricted to forward this special kind of encoded video streams? If so, we already have the problem of knowing that this is actually the case in the particular DS domain/region... 4) Normalizing other (non video) streams within the same AF class may cause adverse effects to the application behavior. 5) Aggregation effects within a domain in interior nodes may cause a different proportion than what the normalizer is configured for. Thus the normalizer may not cause the desired effects for a whole domain. 6) The AF PHB group per se is difficult to handle, since drop precedences may be even inconsistenly configured within a DS domain or DS region (see RFC 2597, sec. 4 at the end: "Inconsistent discard behaviors lead to inconsistent end-to-end service semantics and limit the range of possible uses of the AF PHB in a multi-vendor environment."). Furthermore, packets of lowest drop precedence may suffer from packets with higher drop precedences waiting before them in the queue. 7) For an AF class you basically need a sort of admission control for the assured (let's say "green") AFx1 packets to guarantee the low loss probability. Every usage of excess bandwidth is purely optional for which the application must be prepared. Regards, Roland From chelai@cisco.com Wed Oct 16 14:53:40 2013 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 6AFB411E820B; Wed, 16 Oct 2013 14:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvdtCydLmgsN; Wed, 16 Oct 2013 14:53:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C634011E81D7; Wed, 16 Oct 2013 14:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9855; q=dns/txt; s=iport; t=1381960412; x=1383170012; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3DIYvWnBQJFVcG0vYaOZUQd9A2tiucSTu2RPvyT3TRg=; b=hjqoEEf3BpBbkumJ/vGbTUIcaB/WQTK7LJHfPlmkZKyh8fdA4+tpSBJP gW0Y0YPSmLoMT+YspRS7DkDEHNVKdG51XZcm6E5wNaC8FoM/C3n7baJDA iVe5vfe0RrSCba888cDJ87c/o0iQGqgBwNY4YQzJAKH5NCXRphSFazGWH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAEUKX1KtJXG//2dsb2JhbABaDoJ5OFK9dIEfFnSCJQEBAQMBOj8FBwQCAQgRBAEBCxQJBzIUCQgCBAENBQgBh3cGDL9JjhMFgQgxAgUGgxmBBgOZM5BTgmU/gWgIFyI X-IronPort-AV: E=Sophos;i="4.93,509,1378857600"; d="scan'208";a="273013401" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 16 Oct 2013 21:53:24 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9GLrOEp016532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 21:53:24 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.151]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 16:53:24 -0500 From: "Cheng-Jia Lai (chelai)" To: Roland Bless , Michael Welzl Thread-Topic: [rmcat] About the importance of packets in a single data stream Thread-Index: AQHOxxIBOJMNOML1QUC1C9YpsCaTb5nx4bqAgAC40ICAAH0UgIAAEJUAgAHoBICAAK5OAIAAmFKAgAA9WYCAACHmgIAAG1cAgAAT6QCAAArtAIAAFfCAgABEOQCAAAy+AIAAB6MAgAC2ygD//7sq0A== Date: Wed, 16 Oct 2013 21:53:23 +0000 Message-ID: References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> <525E4C96.2010102@kit.edu> <525EEC54.7050003@kit.edu> In-Reply-To: <525EEC54.7050003@kit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.84.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , rmcat WG , "tsv-area@ietf.org" , Kevin Gross Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 21:53:40 -0000 Hi Michael, Roland, Kevin, and all, As an author of this draft, I am grateful to see so many great comments and= insights from all of you. I do agree with most of those. Michael has made = a good point that the proposal's incentive won't be completely in effect un= less the applications *know* the normalizer is deployed in the network. Thi= s is probably the hardest problem (not technical, maybe). Usually we see th= at in an enterprise network, routers are managed as DS domains while servic= e provider edges have SLA, so it may be safe to say that the IT admins can = manually configure AF PHB in their network planning for video endpoints dep= loyment. Suppose the vendor of a video endpoint implements an option that a= llows generating more packets in lower priorities such as AF43 if so config= ured. Since the IT admin *knows* the enterprise network has deployed a norm= alizer at DS edges, the IT admin can turn on that option on the video endpo= int. However, if the DS domains don't have a single administration such as = on extranet or in service-provider networks, then the applications will nee= d some way to *know* exactly if a normalizer is used. One way to do that is make the normalizer deployment to become a standardiz= ed mechanism, so that the interaction (i.e. apps know or discover normalize= rs' existence) is possible by some sort of signaling or protocol. Exactly h= ow to do this (or whether it is wise to do this) is open to discussion, so = we tentatively changed the draft's intended status from standard (v0) to in= formational (v2) before it was presented to the WG. Also, some inline comments below. Regards, CJ > -----Original Message----- > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of= Roland Bless > Sent: Wednesday, October 16, 2013 12:43 PM > To: Michael Welzl > Cc: Bernard Aboba; rmcat WG; tsv-area@ietf.org; Kevin Gross > Subject: Re: [rmcat] About the importance of packets in a single data str= eam >=20 > Hi Michael and all, >=20 > Am 16.10.2013 10:49, schrieb Michael Welzl: > >> - Following the end-to-end argument, it doesn't make sense to build > >> somewhat complex mechanisms into the network, which may even depend > >> on the particular application (like WebRTC etc.) - so building a > >> "normalizer" (w/o having fully understood the concept) into the > >> network doesn't seem to be the right approach in the long run. > > > > I disagree with what you say about e2e, see: > > http://www.ietf.org/mail-archive/web/rmcat/current/msg00519.html > > but anyway that's a separate debate, as the normalizer draft works on > > aggregates and is really compliant with DiffServ as far as I can tell. > > That's the draft we're debating here: > > http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 >=20 > Thanks for the pointer, I quickly read over it. > My understanding is: if we have an example flow > of AF41:AF42:AF43 80:20:0 the normalizer would > reassign those packets to 40:20:20 (or whatever > the configured proportion is). Is this perception > correct? >=20 Yes. > Regarding the e2e argument: > - you said "it only says that whatever can be done in the application > should be left up to the application" - I don't think this catches > the gist of it: "The function in question can completely and > correctly be implemented only with the knowledge and help of the > application standing at the end points of the communication system. > Therefore, providing that questioned function as a feature of the > communication system itself is not possible". =3D> especially, > application knowledge is often required when reacting on failures, > i.e., the right decision cannot be made when implemented within the > network. Thus, dropping packets according to the markings set by > the application is fully in accordance with the e2e argument, whereas > building marking mechanisms into the network that require application > knowledge is usually not in accordance with it. >=20 > - if I understood the normalizer proposal in draft-lai-tsvwg-normalizer-0= 2 > correctly, it is not in line with the e2e argument since it reassigns > drop precedences without application knowledge. Thus, it may make > the wrong decisions about the importance of packets, not knowing how > apps react to loss. >=20 If the incoming packets of the flow are already marked by the application, = the normalizer (in a color-aware mode, i.e. aware of the existing markings)= should learn from the existing distribution of the existing markings while= it reassigns the markings. This might not be perfect, but it is making use= of application knowledge which is retrieved from the existing markings, fo= r right decisions. If the incoming packets have no good markings (i.e. all = the same), there is no application knowledge for the normalizer to retrieve= , so yes, I agree, it can make wrong decisions at remarking. But our thinki= ng is: if the applications do not care enough to mark its own packets, why = should the normalizer care? :) > >> - Therefore, I agree very much with your last statement: it's only > >> the application that has the knowledge and context to set any > >> kind of forwarding priority (or drop precendence) for individual > >> packets correctly. > >> Especially, the logic to react on dropped packets should reflect > >> the marking and corresponding dropping behavior. > > > > Yeah, the issue we're debating is that an application won't have an > > incentive to go for the profile of Flow B (page 4 of the draft) unless > > it knows that the normalizer is there, because otherwise it could get > > treated in the normal DiffServ way and that would make it worse off tha= n > > Flow A (page 4 of the draft). Thus you need a way for the application t= o > > signal intra-flow packet priorities to an edge without "standard > > DiffServ" operating on that signal. The signal must be ignored unless > > the normalizer is there. Agree. This signaling could be designed in various forms, so it might need = a few standardized mechanisms for this interaction. Either a new DiffServ s= ervice (like a contract) with DSCP assignments to be used in configuration = & deployment, or a more dynamic way, i.e. discovery of normalizer existence= via some protocol or application-layer message. > > > > I hope that helped to clarify the discussion a bit... >=20 > Thanks, I think I understand the rationale now. However, I see several > potential problems with this approach and have some thoughts to share > as well: > 0) I think an application with a 40:20:20 assignment has no real problem > if it experiences loss in PHBs AFx2, AFx3 since it was designed that > way. Whether it's "unfair" w.r.t. to other streams doesn't really > matter. Remember that QoS support is usually managed unfairness > anyway. Fairness within AF usually matters for the "yellow" packets, > e.g., AFx2. This excess bandwidth should be fairly shared among all > streams in this AF class if possible. I agree that "unfairness" is OK to some degree, as long as it is not super = unfair. The normalizer is designed to avoid the super unfairness, instead o= f offering perfect fairness which we can hardly achieve in DiffServ, as I a= gree with you. >=20 > 1) reassignment of drop precedences w/o application knowledge >=20 > 2) how can one find the right default proportions suitable for different > streams or applications? >=20 > 3) Is this AF PHB class restricted to forward this special kind of > encoded video streams? If so, we already have the problem of > knowing that this is actually the case in the particular DS > domain/region... We do not want it to specialize on particular video encoding. The H.264 not= ion in the draft is for example. >=20 > 4) Normalizing other (non video) streams within the same AF class may > cause adverse effects to the application behavior. Yes, agree. It is still necessary to classify/categorize the traffic so onl= y relevant streams should go into the AF class where a normalizer is deploy= ed. >=20 > 5) Aggregation effects within a domain in interior nodes may cause > a different proportion than what the normalizer is configured for. > Thus the normalizer may not cause the desired effects for a whole > domain. Assume all the edges are deployed with a normalizer, while the interior nod= es are not. Then, all flows traversing the interior nodes have already been= normalized, so they should see similar-fair drop effects everywhere inside= the DS domain. >=20 > 6) The AF PHB group per se is difficult to handle, since drop > precedences may be even inconsistenly configured within a DS domain > or DS region (see RFC 2597, sec. 4 at the end: "Inconsistent discard > behaviors lead to inconsistent end-to-end service semantics and > limit the range of possible uses of the AF PHB in a multi-vendor > environment."). > Furthermore, packets of lowest drop precedence may suffer from > packets with higher drop precedences waiting before them in the > queue. If the suffering here refers to queuing delays, then it is the same for all= packets (no matter high or low drop precedence) in the AF PHB class, on av= erage in the FIFO queue. Instead, the normalizer addresses the drop probabi= lity for AQM. >=20 > 7) For an AF class you basically need a sort of admission control for > the assured (let's say "green") AFx1 packets to guarantee the low > loss probability. Every usage of excess bandwidth is purely optional > for which the application must be prepared. >=20 > Regards, > Roland From eckert@cisco.com Wed Oct 16 17:22:30 2013 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 31E0B21F9901 for ; Wed, 16 Oct 2013 17:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.157 X-Spam-Level: X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnefjCAE0ApN for ; Wed, 16 Oct 2013 17:22:25 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A948D11E819B for ; Wed, 16 Oct 2013 17:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1464; q=dns/txt; s=iport; t=1381969343; x=1383178943; h=date:from:to:cc:subject:message-id:mime-version; bh=7+UNVcA2e7TbAECmzP5VN4+ykfkEbfGzrc+B6BhxyZw=; b=PogvnvbKUrD+/6NqUvNB/sqN0C+vdseLhmQ5qvXl3dFpQzntIKGaQ9x6 noIDE1YGItD9FcdfOsTF9KxiygwV+Xi328wcy+45WrT0U++oVVcB9IAcR 7D7vPbJpz4F1fcfppI/OmEYZrBe4SWncyMK0riAyF36zkqiCPYyVzR5H2 M=; X-IronPort-AV: E=Sophos;i="4.93,510,1378857600"; d="scan'208";a="91596985" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 17 Oct 2013 00:22:22 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9H0MLoi022789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Oct 2013 00:22:21 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9GNpDFi017078; Wed, 16 Oct 2013 16:51:13 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9GNpC63017076; Wed, 16 Oct 2013 16:51:12 -0700 Date: Wed, 16 Oct 2013 16:51:12 -0700 From: Toerless Eckert To: lars@netapp.com, mirja.kuehlewind@ikr.uni-stuttgart.de Message-ID: <20131016235112.GQ2518@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: rmcat@ietf.org, fyip@cisco.com, chelai@cisco.com, carlberg@g11.org.uk, Xiaoqing Zhu Subject: [rmcat] Agenda rquest/suggestion: intelligent packet drop X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 00:22:30 -0000 Dear RMcat WG chairs given how there seem to have been some interest or at least discussion about the methods of intelligent packet dropping, i would like to sugest to have a short 5 min slot at the RMcat agenda for '88 to just give an overview of the idea (not that it's new, but i don't think it has been reviewed as a tool for RMcat). I think the overall idea of intelligent dropping of video frames is becoming quite common in switching codecs to deal with congestion based rate reductions, but what i think is much less clear to the application audience in RMcat is that the same could be achieved via intelligent dropping in router/switches devices exactly where the congestion happens - and therefore also helping to much faster resolve burst collisions like those happening during (re-)startup of RMcat flows. Given how RMcat tries to have very fast up/downspeeding for vidoe flows, i think it would be very useful to know what tools could help to achieve this, and intelligent dropping in the network could be quite a useful tool. This isn't meant to give dertails of marking options or normalizatin (which we hve a draft for - draft-lai-tsvwg-normalizer-02.txt), but rather to let RMcat folks understand how this tool could help their rate-control mechanisms. We have some results through simulation and running code to lean on. Btw: if there is a better IRTF group to talk about, please let me know. Cheers Toerless From ingemar.s.johansson@ericsson.com Thu Oct 17 02:14:13 2013 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 862FD21F9BB1 for ; Thu, 17 Oct 2013 02:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.337 X-Spam-Level: X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgKNAAlFsT2o for ; Thu, 17 Oct 2013 02:14:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE5D21F92B2 for ; Thu, 17 Oct 2013 02:14:04 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-1f-525faa5bf082 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F9.31.03802.B5AAF525; Thu, 17 Oct 2013 11:14:03 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.11]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Thu, 17 Oct 2013 11:14:02 +0200 From: Ingemar Johansson S To: Manuel Gorius , Michael Welzl Thread-Topic: [rmcat] draft-vanderauwera-rmcat-video-quality Thread-Index: AQHOyRAqZZiBadU22UGKupfsfcenAJn1g/TwgAB3OQCAANlI8P//9F8AgAAhOoCAAbQ5YA== Date: Thu, 17 Oct 2013 09:14:02 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA1C39C0DC@ESESSMB205.ericsson.se> References: <6F0A5342-E5EF-44DD-94C2-9EB97FFE3A07@netapp.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39A74E@ESESSMB205.ericsson.se> <4FC1F85139E6FE4D9A55BD6798B29A4816AD20A5@NASANEXD02B.na.qualcomm.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39B113@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvjW70qvgggw3rRSzOHz/LZDFpxyRW ixeve1gsfpzdyWqx+uYHNgdWjyVLfjJ5rF79kNljxqcvbB4n3l1h9Fg09RljAGsUl01Kak5m WWqRvl0CV8bGRQ3MBS3SFV9vfmNrYDwr2sXIySEhYCKxsWMBE4QtJnHh3nq2LkYuDiGBw4wS e6e8YYRwFjNK3Px8nxmkik3ARmLloe+MILaIQLDE9e3tbCA2s0CJxPxrV8AmCQtYS6yfNRWq xkbi696pzBB2mMSWA9tZuxg5OFgEVCWW7y4CMXkFfCX2vLQBqRAS+MckcWULI0iYU8BN4spc K5Awo4CsxP3v91ggFolL3HoyH+pkAYkle84zQ9iiEi8f/2OFsBUl2p82MELU60gs2P0J6kht iWULX4PV8woISpyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsY2XMTM3PSy402MQJj6+CW36o7 GO+cEznEKM3BoiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRhahDq7sZA02Icl/ IiUaa3g0v3At2sZnvs6hJXHeMYf3U2+WPbM+4LzyztMnMlMuXGDmLp4gErToytuK64u8PRrm Xf701cR01pFImdxdB55emHuTYXtI27IP5eeeXLdhXRHRk8Ye9kfsifzUKP+Efst5m7+b5N6a Xq2gcMKmZf6948+2lWRMf6bEUpyRaKjFXFScCADBbLH/ewIAAA== Cc: "Van Der Auwera, Geert" , rmcat WG , "Eggert, Lars" Subject: Re: [rmcat] draft-vanderauwera-rmcat-video-quality X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 09:14:13 -0000 Hi I believe that the closest to some kind of an adaptive delay-based to loss= -based congestion control is the Hamilton Delay TCP (thanks for the heads u= p Mirja!).=20 http://eprints.nuim.ie/1745/1/HamiltonDelayAIMD.pdf=20 I have not experimented with it though so I can't comment on the usefulness= .=20 /Ingemar > -----Original Message----- > From: Manuel Gorius [mailto:gorius@nt.uni-saarland.de] > Sent: den 16 oktober 2013 11:05 > To: Michael Welzl > Cc: Ingemar Johansson S; Van Der Auwera, Geert; rmcat WG; Eggert, Lars > Subject: Re: [rmcat] draft-vanderauwera-rmcat-video-quality >=20 >=20 > On 16.10.2013, at 09:06, Michael Welzl wrote: >=20 > > > > On 16. okt. 2013, at 08:42, Ingemar Johansson S wrote: > > > >> Hi > >> > >> Thanks for the reply. > >> I assumed 1500byte packeys which gives almost 400ms delay. > >> As I see it it seems a bit pessimistic with a ratio 30-40 between late= ncy > under load and min RTT. > >> I am fully aware of the bufferbloat problem but isn't there a risk tha= t this > becomes a corner case and that it might drive designs in a direction that > makes them suboptimal for the main operating conditions. > >> > >> To take an example: In order for the RMCAT flow to be able to compete > with an FTP using TCP Reno or Cubic over this bottleneck, it becomes > necessary that the RMCAT flow contributes to the bufferbloat for instance= by > increasing a target delay or whatever. Unless the RMCAT flow gets some > magic information from the network, it needs to infer information about t= he > existence of competing flows, it can work more or less well and I see bef= ore > be a lot of special code to do this, some of it actually becomes engineer= ed to > solve this particular test case. > > > > Measured delay can serve as this "magic information"... > > > > > >> The problem with this is that this added intelligence can actually inc= rease > the risk that the RMCAT flow it self creates self-inflicted congestion du= e to > faulty decisions, meaning that the RMCAT flow it self locks it self in 40= 0ms RTT > even though there is no competing traffic. > > > > That would be the result of a badly designed congestion controller. I d= on't > think that this naturally follows from trying to minimize delay, yet comp= ete > with TCP when it is present. > > > Designing a sophisticated congestion controller in order to address this > problem is still challenging, though (are there any such solutions availa= ble so > far?). We performed experiments with delay-based congestion control > where we ran into exactly the same issue: The intensity of the delay-base= d > flows had to be increased in order to compete with loss-based TCP-flows i= n > environments with huge buffers. At the same time it is probably desirable > that the queues aren't filled excessively in case there is only delay-con= trolled > traffic. I think for a delay-based decision, the controller has to learn = the range > of the delay variation in such environments (maybe incorporating loss-bas= ed > feedback as well) and must derive a suitable weighting for the congestion > feedback in order to keep the flow competitive under an increasing number > of loss-based flows. Having a mixture of loss- and delay-based feedback > could solve the problem of self-inflicted congestion in my opinion. >=20 > Best regards, > Manuel From michawe@ifi.uio.no Thu Oct 17 04:43:00 2013 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 74AAB11E81B6 for ; Thu, 17 Oct 2013 04:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24TeVvJP5MDG for ; Thu, 17 Oct 2013 04:42:55 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 75AB311E8177 for ; Thu, 17 Oct 2013 04:42:39 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VWlyQ-0003Dv-DO for rmcat@ietf.org; Thu, 17 Oct 2013 13:42:38 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VWlyP-0007Wg-Ew for rmcat@ietf.org; Thu, 17 Oct 2013 13:42:38 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_509AAACD-1606-4B21-8323-FF2B0046EE06" Date: Thu, 17 Oct 2013 13:42:36 +0200 References: <20131017113150.21859.25715.idtracker@ietfa.amsl.com> To: rmcat WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 8676 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6C9E13B148900BEBC4562D0AD668296B8742BB46 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3409 max/h 16 blacklist 0 greylist 0 ratelimit 0 Subject: [rmcat] Fwd: New Version Notification for draft-welzl-rmcat-coupled-cc-02.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 11:43:00 -0000 --Apple-Mail=_509AAACD-1606-4B21-8323-FF2B0046EE06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, We have posted an update of the coupled congestion control draft, where = we incorporated the comments that we got at the last meeting. It = includes an "active" version of the algorithm which is closer in spirit = to RFC 2140: if one flow changes its rate, all flows must immediately = update theirs, leading to an aggregate behavior that's easier to = understand. We had planned to share a technical report with simulation results too = at this stage, but it's just going to take a little longer I'm afraid, = sorry for that. What I do promise is that we keep on working on it and = will announce it as soon as we have it (not necessarily just 1 week = before the next meeting). Complementing this work, we are working on shared bottleneck detection = too, and we hope that we'll have something to present at the next = (London) IETF. Cheers, Michael Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-welzl-rmcat-coupled-cc-02.txt > Date: 17. oktober 2013 13:31:50 GMT+02:00 > To: Safiqul Islam , Michael Welzl = , Stein Gjessing >=20 >=20 > A new version of I-D, draft-welzl-rmcat-coupled-cc-02.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Filename: draft-welzl-rmcat-coupled-cc > Revision: 02 > Title: Coupled congestion control for RTP media > Creation date: 2013-10-17 > Group: Individual Submission > Number of pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-02.txt > Status: = http://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc > Htmlized: = http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-welzl-rmcat-coupled-cc-02 >=20 > Abstract: > When multiple congestion controlled RTP sessions traverse the same > network bottleneck, it can be beneficial to combine their controls > such that the total on-the-wire behavior is improved. This document > describes such a method for flows that have the same sender, in a = way > that is as flexible and simple as possible while minimizing the > amount of changes needed to existing RTP applications. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_509AAACD-1606-4B21-8323-FF2B0046EE06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

We have posted an update of the coupled = congestion control draft, where we incorporated the comments that we got = at the last meeting. It includes an "active" version of the algorithm = which is closer in spirit to RFC 2140: if one flow changes its rate, all = flows must immediately update theirs, leading to an aggregate behavior = that's easier to understand.

We had planned to = share a technical report with simulation results too at this stage, but = it's just going to take a little longer I'm afraid, sorry for that. What = I do promise is that we keep on working on it and will announce it as = soon as we have it  (not necessarily just 1 week before the next = meeting).

Complementing this work, we are = working on shared bottleneck detection too, and we hope that we'll have = something to present at the next (London) = IETF.

Cheers,
Michael


Begin forwarded message:

Subject: New Version Notification for = draft-welzl-rmcat-coupled-cc-02.txt
Date: 17. oktober 2013 = 13:31:50 GMT+02:00
To: Safiqul Islam <safiquli@ifi.uio.no>, Michael = Welzl <michawe@ifi.uio.no>, Stein = Gjessing <steing@ifi.uio.no>


A new version of I-D, = draft-welzl-rmcat-coupled-cc-02.txt
has been successfully submitted = by Michael Welzl and posted to the
IETF = repository.

Filename: = draft-welzl-rmcat-coupled-cc
Revision: 02
Title: Coupled = congestion control for RTP media
Creation date: = 2013-10-17
Group: Individual Submission
Number = of pages: 17
URL: =             http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-02= .txt
Status: =          http= ://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc
Htmlized: =        http:/= /tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-02
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-welzl-rmcat-coupled-cc-02
Abstract:
  When multiple congestion controlled RTP = sessions traverse the same
  network bottleneck, it can be = beneficial to combine their controls
  such that the total = on-the-wire behavior is improved.  This document
=   describes such a method for flows that have the same sender, = in a way
  that is as flexible and simple as possible = while minimizing the
  amount of changes needed to = existing RTP applications.




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.

The IETF = Secretariat


= --Apple-Mail=_509AAACD-1606-4B21-8323-FF2B0046EE06-- From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Oct 17 06:47:42 2013 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 3261711E826E for ; Thu, 17 Oct 2013 06:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rrerl585NRbw for ; Thu, 17 Oct 2013 06:47:38 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id E2E3611E8269 for ; Thu, 17 Oct 2013 06:47:37 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 94C0960252; Thu, 17 Oct 2013 15:47:36 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 8E7FE60251; Thu, 17 Oct 2013 15:47:36 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Thu, 17 Oct 2013 15:47:36 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <20131016175316.GA26546@cisco.com> In-Reply-To: <20131016175316.GA26546@cisco.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310171547.36116.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Bernard Aboba , Toerless Eckert , Kevin Gross , Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 13:47:42 -0000 Hi,=20 I have a (quick) question as you are talking about using existing DSCP vs.= =20 some kind of "intra-flow drop precedence" signaling. You only have been=20 talking about the signaling so far. But what would be the expected network= =20 behavior/reaction? With AF4x classed if believe you will have to calculate different drop=20 probabilities for each class based on a different parameter set for RED (or= =20 something similar...?), right? I would always have envisioned an behavior where you calculate the same dro= p=20 probability for every packet or even use DropTail. Then if a packet is abou= t=20 to be dropped, you look into the queue and try to find another packet of th= e=20 same flow but with the "drop precedence" bit set. If you find one, you drop= =20 this packet instead, if not you drop the original (incoming) packet. Does such a mechanism exist anywhere? Mirja On Wednesday 16 October 2013 19:53:16 Toerless Eckert wrote: > On Wed, Oct 16, 2013 at 09:22:00AM +0200, Michael Welzl wrote: > > ....so we'd really need "intra-flow drop precedence" bits, to inter-work > > with existing DSCP values and get the expected PHB, right? (or do as you > > say, define the PHB + precedence, for all possible combinations) > > Right. And independent of those intra-flow priority bits there is > IMHO still the open question whether the existing DSCP/PHB best suit > what we would want for RMcat. > > > > And then the DSCP still get reset along the path, and apps still have > > > problems setting DSCP across various OSs. > > > > There is also an architectural side to it: Kevin rightfully started this > > conversation by saying: "No, not per 5 tuple (per flow). I don't think > > that is something we should ask of the network." Indeed, doing this rig= ht > > *requires* routers (or whatever box does that) to identify flows and ke= ep > > track of them. Such per-flow functionality isn't what we want "normal" > > routers to do, I think, and so binding DSCP values to such a > > functionality just seems wrong to me. In a way, it makes the IP header > > less self-contained: in order to implement all the functions encoded in > > it, you need to look beyond the IP header. This doesn't strike me as go= od > > design. > > Flow-awareness is not evil, and there are a lot more proof points of > deployment where it works and scales than IMHO places where its needed and > does not scale. All enterprise routers i know do heavily leverage flow > awareness. > > Flow awareness for intra-flow priority can easily be designed to require > the same amount of flow awareness as existing QoS problems. Specifically > for QoS-authorization on the edge (and for intra-flow priority, that > authorization could mean normalization). I think that's waht you're also > saying below. > > > I think it's not too much to ask of devices that identify flows to look > > beyond the IP header for a shim, RTP-something, or whatever we define. > > Then, this device can aggregate flows into the right DSCPs if it knows > > that traffic's going to traverse a path where the normalizer is present= - > > and the normalizing devices again only need to look at the IP header, > > where it's all per-aggregate. (sorry for repeating myself, I thought I'd > > say this again here just for context, but I did say this before) > > Right. > > There is also some fundamental insight into what a "correct" layer is that > i think the IETF is missing. With IPv6, they just carried over the IPv4 > design without reviewing why router-alert and IP packet options didn't > catch on in IPv4 for onpath operations. After 30 years regurgitating what= 's > not working, it's IMHO rally time to give IETF blessings to some other > approach, and clean well reviewed designs with such network aware > extensions in the transport layer IMHO is exactly that (whether it's shim > layer, SCTP extensions, RTP header extension or what hae you - that's > just a mattter of use-case priorities). > > > Cheers > toerless > > Cheers, > > > Michael > > > > > Cheers > > > Toerless > > > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > >> Maybe I skimmed it too quickly but my understanding is that the > > >> proposal is to remark DSCP values at the ingress point of the network > > >> and possibly at other key boundaries too. Such DSCP remapping is > > >> already common practice in enterprise networks. > > >> > > >> The twist here is that the remapper will do the remapping dynamically > > >> based on the proportion of AFn1, AFn2 and AFn3 packets received from= a > > >> sender. A greedy sender that it producing only AF41 markings will get > > >> some of those randomly remarked as AF42 and AF43. > > >> > > >> The proposal uses existing DSCP values and it doesn't look like > > >> signaling is necessary nor is it necessary for the application to kn= ow > > >> that this is happening. > > >> > > >> Kevin Gross > > >> +1-303-447-0517 > > >> Media Network Consultant > > >> AVA Networks - www.AVAnw.com > > >> > > >> On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl = =20 wrote: > > >>> Hmm. Whether the balance is right or not might depend on how the > > >>> signaling is done. Anyway, unless I misunderstood something, the way > > >>> the normalizer now stands it won't really make a change: it gives an > > >>> incentive to applications to mark some packets with higher drop > > >>> precedence, yet requires applications to know that the normalizer is > > >>> in place or else the service would be different. > > >>> > > >>> Maybe different DSCP values would be needed - but then this can't be > > >>> used in combination with "regular" DiffServ usage. It really depends > > >>> on the signaling - ideas are now being tossed around by Colin and > > >>> Toerless, who clearly both know more about what the right signaling > > >>> could be than me. > > >>> > > >>> Cheers, > > >>> Michael > > >>> > > >>> > > >>> On 15. okt. 2013, at 19:04, Kevin Gross > > >>> wrote: > > >>> > > >>> I think you're stretching here. I don't think the balance is right. > > >>> The proposed information is difficult to retrieve and of little use > > >>> to much of the network. Even if standardized, it is unlikely to be > > >>> successful. > > >>> > > >>> The ideas in the normalizer draft don't seem to have so many issues > > >>> and I think it answers your original question and sets out to achie= ve > > >>> what you're looking for. > > >>> > > >>> Kevin Gross > > >>> +1-303-447-0517 > > >>> Media Network Consultant > > >>> AVA Networks - www.AVAnw.com > > >>> > > >>> On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl = =20 wrote: > > >>>> Hi, > > >>>> > > >>>> I'll dissect your second and third sentences and tell you what I > > >>>> think about each part :-) below: > > >>>> > > >>>> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > >>>>> No, not per 5 tuple (per flow). I don't think that is something we > > >>>> > > >>>> should ask of the network. > > >>>> > > >>>> I agree that asking this of the network may seem like encouraging > > >>>> per-flow functionality; in particular, if we'd put this into IP, > > >>>> that would be ugly. However, it's just a matter of fact that there > > >>>> are devices that do identify flows, and then, why not give such > > >>>> devices some guidance? I like Toerless' suggestion of making this > > >>>> an RTP header extension field: if a device is identifying flows, we > > >>>> can expect such a device to identify such a field too. Plus, if we > > >>>> think of end systems playing an intermediate system role in RTP > > >>>> (mixers, ..), these devices might also benefit from that sort of > > >>>> information. > > >>>> > > >>>>> It doesn't sit well with the end-to-end principle > > >>>> > > >>>> I disagree, this is an all-too-common misunderstanding of the > > >>>> end-to-end principle: it only says that whatever can be done in the > > >>>> application should be left up to the application, but it doesn't s= ay > > >>>> that you mustn't identify application streams inside the network or > > >>>> "keep the network simple and stupid". If you do "keep the network > > >>>> stupid", you're definitely in line with the e2e argument, but the > > >>>> argument isn't as strict as that (a typical example is routing, > > >>>> which can well become as complex as you wish, without harming the > > >>>> end-to-end principle). Now here we're discussing a function where > > >>>> the application really can't help you: when congestion happens > > >>>> inside the network and a packet must be dropped there, the best the > > >>>> application can do is tell you which packet to drop. > > >>>> > > >>>>> and it won't scale. > > >>>> > > >>>> I agree. But it doesn't have to, just because we introduce the > > >>>> signal we don't harm scalability - devices at the edges of the > > >>>> network could deal with it, all other devices could ignore it. > > >>>> > > >>>> Cheers, > > >>>> Michael =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From eckert@cisco.com Thu Oct 17 07:16:05 2013 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 6F9C411E8266 for ; Thu, 17 Oct 2013 07:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.906 X-Spam-Level: X-Spam-Status: No, score=-9.906 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEoLYuoOSfc9 for ; Thu, 17 Oct 2013 07:16:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF6E11E8205 for ; Thu, 17 Oct 2013 07:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11086; q=dns/txt; s=iport; t=1382019358; x=1383228958; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=oZuG+T64VQ5Osm9o6xAuHbkVEeIVfSMQnmEA8alzfqE=; b=Q8dLn1QzrdBN9OyV7MF/WAvDkKy77SRB1TDYAL+CN+RKkwjGkcb4spyo gn13bC9r0O24arn6PwDjSshKvcbWzFyk50uHJKmFzdLGsqNTe5FwZWKS2 ltxg2rjupwdj30zG7Vb0sFXeo3bs/DgG8gp6z48J0NmiHKCrdAmdfkr6k Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFAEjwX1KrRDoJ/2dsb2JhbABQBwODBzi6Y4NxgSMWdIIlAQEBBA4kARYcAhIQCwcLBgklDwU1FBOIBcBJjggGgTMQBxGDDoEHA4k8imuDXgGSBINEHIE0 X-IronPort-AV: E=Sophos;i="4.93,514,1378857600"; d="scan'208";a="92357803" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 17 Oct 2013 14:15:57 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9HEFuWn001434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Oct 2013 14:15:56 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9HEFuwW003439; Thu, 17 Oct 2013 07:15:56 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9HEFtnW003438; Thu, 17 Oct 2013 07:15:55 -0700 Date: Thu, 17 Oct 2013 07:15:55 -0700 From: Toerless Eckert To: Mirja Kuehlewind Message-ID: <20131017141555.GA9464@cisco.com> References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <20131016175316.GA26546@cisco.com> <201310171547.36116.mirja.kuehlewind@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201310171547.36116.mirja.kuehlewind@ikr.uni-stuttgart.de> User-Agent: Mutt/1.4.2.2i Cc: Bernard Aboba , rmcat@ietf.org, Kevin Gross , Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 14:16:05 -0000 Mirja, Simple drop-tail configs for the different classes yielded IMHO quite good results. WRED just adds more parameters (with the slope). Routers may support only WRED and no explicit drop-tail, so one can easily use WRED to create a drop-tail config via a WRED config, but leveraging the slope in WREP is something IMHO related to the CC mechanism used so we didn't play around too much with that yet (priority dropping is meant to react faster than CC). What you describe last is what we called the "oracle", aka the method that we thought could be used in simulation at least as a theoretical "best-possible-drop-priority" mechanism. And no, you're right, it does not exist in router products. Luckily it turned out to actually be worse than droptail. I have some analsysis slide that tries to explain why. Hint: bufferbloat ;-) Cheers Toerless On Thu, Oct 17, 2013 at 03:47:36PM +0200, Mirja Kuehlewind wrote: > Hi, > > I have a (quick) question as you are talking about using existing DSCP vs. > some kind of "intra-flow drop precedence" signaling. You only have been > talking about the signaling so far. But what would be the expected network > behavior/reaction? > > With AF4x classed if believe you will have to calculate different drop > probabilities for each class based on a different parameter set for RED (or > something similar...?), right? > > I would always have envisioned an behavior where you calculate the same drop > probability for every packet or even use DropTail. Then if a packet is about > to be dropped, you look into the queue and try to find another packet of the > same flow but with the "drop precedence" bit set. If you find one, you drop > this packet instead, if not you drop the original (incoming) packet. > Does such a mechanism exist anywhere? > > Mirja > > > On Wednesday 16 October 2013 19:53:16 Toerless Eckert wrote: > > On Wed, Oct 16, 2013 at 09:22:00AM +0200, Michael Welzl wrote: > > > ....so we'd really need "intra-flow drop precedence" bits, to inter-work > > > with existing DSCP values and get the expected PHB, right? (or do as you > > > say, define the PHB + precedence, for all possible combinations) > > > > Right. And independent of those intra-flow priority bits there is > > IMHO still the open question whether the existing DSCP/PHB best suit > > what we would want for RMcat. > > > > > > And then the DSCP still get reset along the path, and apps still have > > > > problems setting DSCP across various OSs. > > > > > > There is also an architectural side to it: Kevin rightfully started this > > > conversation by saying: "No, not per 5 tuple (per flow). I don't think > > > that is something we should ask of the network." Indeed, doing this right > > > *requires* routers (or whatever box does that) to identify flows and keep > > > track of them. Such per-flow functionality isn't what we want "normal" > > > routers to do, I think, and so binding DSCP values to such a > > > functionality just seems wrong to me. In a way, it makes the IP header > > > less self-contained: in order to implement all the functions encoded in > > > it, you need to look beyond the IP header. This doesn't strike me as good > > > design. > > > > Flow-awareness is not evil, and there are a lot more proof points of > > deployment where it works and scales than IMHO places where its needed and > > does not scale. All enterprise routers i know do heavily leverage flow > > awareness. > > > > Flow awareness for intra-flow priority can easily be designed to require > > the same amount of flow awareness as existing QoS problems. Specifically > > for QoS-authorization on the edge (and for intra-flow priority, that > > authorization could mean normalization). I think that's waht you're also > > saying below. > > > > > I think it's not too much to ask of devices that identify flows to look > > > beyond the IP header for a shim, RTP-something, or whatever we define. > > > Then, this device can aggregate flows into the right DSCPs if it knows > > > that traffic's going to traverse a path where the normalizer is present - > > > and the normalizing devices again only need to look at the IP header, > > > where it's all per-aggregate. (sorry for repeating myself, I thought I'd > > > say this again here just for context, but I did say this before) > > > > Right. > > > > There is also some fundamental insight into what a "correct" layer is that > > i think the IETF is missing. With IPv6, they just carried over the IPv4 > > design without reviewing why router-alert and IP packet options didn't > > catch on in IPv4 for onpath operations. After 30 years regurgitating what's > > not working, it's IMHO rally time to give IETF blessings to some other > > approach, and clean well reviewed designs with such network aware > > extensions in the transport layer IMHO is exactly that (whether it's shim > > layer, SCTP extensions, RTP header extension or what hae you - that's > > just a mattter of use-case priorities). > > > > > > Cheers > > toerless > > > > Cheers, > > > > > Michael > > > > > > > Cheers > > > > Toerless > > > > > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > > >> Maybe I skimmed it too quickly but my understanding is that the > > > >> proposal is to remark DSCP values at the ingress point of the network > > > >> and possibly at other key boundaries too. Such DSCP remapping is > > > >> already common practice in enterprise networks. > > > >> > > > >> The twist here is that the remapper will do the remapping dynamically > > > >> based on the proportion of AFn1, AFn2 and AFn3 packets received from a > > > >> sender. A greedy sender that it producing only AF41 markings will get > > > >> some of those randomly remarked as AF42 and AF43. > > > >> > > > >> The proposal uses existing DSCP values and it doesn't look like > > > >> signaling is necessary nor is it necessary for the application to know > > > >> that this is happening. > > > >> > > > >> Kevin Gross > > > >> +1-303-447-0517 > > > >> Media Network Consultant > > > >> AVA Networks - www.AVAnw.com > > > >> > > > >> On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl > wrote: > > > >>> Hmm. Whether the balance is right or not might depend on how the > > > >>> signaling is done. Anyway, unless I misunderstood something, the way > > > >>> the normalizer now stands it won't really make a change: it gives an > > > >>> incentive to applications to mark some packets with higher drop > > > >>> precedence, yet requires applications to know that the normalizer is > > > >>> in place or else the service would be different. > > > >>> > > > >>> Maybe different DSCP values would be needed - but then this can't be > > > >>> used in combination with "regular" DiffServ usage. It really depends > > > >>> on the signaling - ideas are now being tossed around by Colin and > > > >>> Toerless, who clearly both know more about what the right signaling > > > >>> could be than me. > > > >>> > > > >>> Cheers, > > > >>> Michael > > > >>> > > > >>> > > > >>> On 15. okt. 2013, at 19:04, Kevin Gross > > > >>> wrote: > > > >>> > > > >>> I think you're stretching here. I don't think the balance is right. > > > >>> The proposed information is difficult to retrieve and of little use > > > >>> to much of the network. Even if standardized, it is unlikely to be > > > >>> successful. > > > >>> > > > >>> The ideas in the normalizer draft don't seem to have so many issues > > > >>> and I think it answers your original question and sets out to achieve > > > >>> what you're looking for. > > > >>> > > > >>> Kevin Gross > > > >>> +1-303-447-0517 > > > >>> Media Network Consultant > > > >>> AVA Networks - www.AVAnw.com > > > >>> > > > >>> On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl > wrote: > > > >>>> Hi, > > > >>>> > > > >>>> I'll dissect your second and third sentences and tell you what I > > > >>>> think about each part :-) below: > > > >>>> > > > >>>> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > > >>>>> No, not per 5 tuple (per flow). I don't think that is something we > > > >>>> > > > >>>> should ask of the network. > > > >>>> > > > >>>> I agree that asking this of the network may seem like encouraging > > > >>>> per-flow functionality; in particular, if we'd put this into IP, > > > >>>> that would be ugly. However, it's just a matter of fact that there > > > >>>> are devices that do identify flows, and then, why not give such > > > >>>> devices some guidance? I like Toerless' suggestion of making this > > > >>>> an RTP header extension field: if a device is identifying flows, we > > > >>>> can expect such a device to identify such a field too. Plus, if we > > > >>>> think of end systems playing an intermediate system role in RTP > > > >>>> (mixers, ..), these devices might also benefit from that sort of > > > >>>> information. > > > >>>> > > > >>>>> It doesn't sit well with the end-to-end principle > > > >>>> > > > >>>> I disagree, this is an all-too-common misunderstanding of the > > > >>>> end-to-end principle: it only says that whatever can be done in the > > > >>>> application should be left up to the application, but it doesn't say > > > >>>> that you mustn't identify application streams inside the network or > > > >>>> "keep the network simple and stupid". If you do "keep the network > > > >>>> stupid", you're definitely in line with the e2e argument, but the > > > >>>> argument isn't as strict as that (a typical example is routing, > > > >>>> which can well become as complex as you wish, without harming the > > > >>>> end-to-end principle). Now here we're discussing a function where > > > >>>> the application really can't help you: when congestion happens > > > >>>> inside the network and a packet must be dropped there, the best the > > > >>>> application can do is tell you which packet to drop. > > > >>>> > > > >>>>> and it won't scale. > > > >>>> > > > >>>> I agree. But it doesn't have to, just because we introduce the > > > >>>> signal we don't harm scalability - devices at the edges of the > > > >>>> network could deal with it, all other devices could ignore it. > > > >>>> > > > >>>> Cheers, > > > >>>> Michael > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja Kühlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From Emmanuel.LOCHIN@isae.fr Thu Oct 17 22:59:47 2013 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 6C18021F9F62 for ; Thu, 17 Oct 2013 22:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDRXjasvbLDK for ; Thu, 17 Oct 2013 22:59:41 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id 50A6521F9F70 for ; Thu, 17 Oct 2013 22:59:32 -0700 (PDT) Received: from supmail (unknown [10.132.1.9]) by smtpext.isae.fr (Postfix) with ESMTP id E05CA22E492; Fri, 18 Oct 2013 07:59:28 +0200 (CEST) Received: from wali.isae.fr (wali.isae.fr [10.132.1.26]) by supmail (Postfix) with ESMTP id E8BE6C88510; Fri, 18 Oct 2013 07:59:30 +0200 (CEST) User-Agent: SOGoMail 2.0.7 X-Forward: 81.56.87.55 MIME-Version: 1.0 from: "LOCHIN Emmanuel" message-id: <57e2-5260ce80-b-1fe79060@95907578> to: "Mirja Kuehlewind" content-type: text/plain; charset="utf-8" date: Fri, 18 Oct 2013 07:59:30 +0200 in-reply-to: <201310171547.36116.mirja.kuehlewind@ikr.uni-stuttgart.de> content-transfer-encoding: quoted-printable Cc: Bernard Aboba , rmcat@ietf.org, Toerless Eckert , Michael Welzl , Kevin Gross Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 05:59:47 -0000 Hi Mirja Your proposal is not random because in terms of probability, all packet= s are not considered as an independent event anymore. IMHO the simply thing is to classify packets with and without "drop pre= cedence" bit set into two separate queues (can be FIFO or RED) for a gi= ven class and to schedule both queues with a round robin or priority queuing sche= me. EL Le Jeudi 17 Octobre 2013 15:47 CEST, Mirja Kuehlewind a =C3=A9crit: > Hi, > > I have a (quick) question as you are talking about using existing DSC= P vs. > some kind of "intra-flow drop precedence" signaling. You only have be= en > talking about the signaling so far. But what would be the expected ne= twork > behavior/reaction? > > With AF4x classed if believe you will have to calculate different dro= p > probabilities for each class based on a different parameter set for R= ED (or > something similar...?), right? > > I would always have envisioned an behavior where you calculate the sa= me drop > probability for every packet or even use DropTail. Then if a packet i= s about > to be dropped, you look into the queue and try to find another packet= of the > same flow but with the "drop precedence" bit set. If you find one, yo= u drop > this packet instead, if not you drop the original (incoming) packet. = > Does such a mechanism exist anywhere? > > Mirja > > > On Wednesday 16 October 2013 19:53:16 Toerless Eckert wrote: > > On Wed, Oct 16, 2013 at 09:22:00AM +0200, Michael Welzl wrote: > > > ....so we'd really need "intra-flow drop precedence" bits, to int= er-work > > > with existing DSCP values and get the expected PHB, right? (or do= as you > > > say, define the PHB + precedence, for all possible combinations) = > > > > Right. And independent of those intra-flow priority bits there is > > IMHO still the open question whether the existing DSCP/PHB best sui= t > > what we would want for RMcat. > > > > > > And then the DSCP still get reset along the path, and apps stil= l have > > > > problems setting DSCP across various OSs. > > > > > > There is also an architectural side to it: Kevin rightfully start= ed this > > > conversation by saying: "No, not per 5 tuple (per flow). I don't = think > > > that is something we should ask of the network." Indeed, doing th= is right > > > *requires* routers (or whatever box does that) to identify flows = and keep > > > track of them. Such per-flow functionality isn't what we want "no= rmal" > > > routers to do, I think, and so binding DSCP values to such a > > > functionality just seems wrong to me. In a way, it makes the IP h= eader > > > less self-contained: in order to implement all the functions enco= ded in > > > it, you need to look beyond the IP header. This doesn't strike me= as good > > > design. > > > > Flow-awareness is not evil, and there are a lot more proof points o= f > > deployment where it works and scales than IMHO places where its nee= ded and > > does not scale. All enterprise routers i know do heavily leverage f= low > > awareness. > > > > Flow awareness for intra-flow priority can easily be designed to re= quire > > the same amount of flow awareness as existing QoS problems. Specifi= cally > > for QoS-authorization on the edge (and for intra-flow priority, tha= t > > authorization could mean normalization). I think that's waht you'r= e also > > saying below. > > > > > I think it's not too much to ask of devices that identify flows t= o look > > > beyond the IP header for a shim, RTP-something, or whatever we de= fine. > > > Then, this device can aggregate flows into the right DSCPs if it = knows > > > that traffic's going to traverse a path where the normalizer is p= resent - > > > and the normalizing devices again only need to look at the IP hea= der, > > > where it's all per-aggregate. (sorry for repeating myself, I thou= ght I'd > > > say this again here just for context, but I did say this before) = > > > > Right. > > > > There is also some fundamental insight into what a "correct" layer = is that > > i think the IETF is missing. With IPv6, they just carried over the = IPv4 > > design without reviewing why router-alert and IP packet options did= n't > > catch on in IPv4 for onpath operations. After 30 years regurgitatin= g what's > > not working, it's IMHO rally time to give IETF blessings to some ot= her > > approach, and clean well reviewed designs with such network aware > > extensions in the transport layer IMHO is exactly that (whether it'= s shim > > layer, SCTP extensions, RTP header extension or what hae you - that= 's > > just a mattter of use-case priorities). > > > > > > Cheers > > toerless > > > > Cheers, > > > > > Michael > > > > > > > Cheers > > > > Toerless > > > > > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > > >> Maybe I skimmed it too quickly but my understanding is that th= e > > > >> proposal is to remark DSCP values at the ingress point of the = network > > > >> and possibly at other key boundaries too. Such DSCP remapping = is > > > >> already common practice in enterprise networks. > > > >> > > > >> The twist here is that the remapper will do the remapping dyna= mically > > > >> based on the proportion of AFn1, AFn2 and AFn3 packets receive= d from a > > > >> sender. A greedy sender that it producing only AF41 markings w= ill get > > > >> some of those randomly remarked as AF42 and AF43. > > > >> > > > >> The proposal uses existing DSCP values and it doesn't look lik= e > > > >> signaling is necessary nor is it necessary for the application= to know > > > >> that this is happening. > > > >> > > > >> Kevin Gross > > > >> +1-303-447-0517 > > > >> Media Network Consultant > > > >> AVA Networks - www.AVAnw.com > > > >> > > > >> On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl > wrote: > > > >>> Hmm. Whether the balance is right or not might depend on how = the > > > >>> signaling is done. Anyway, unless I misunderstood something, = the way > > > >>> the normalizer now stands it won't really make a change: it g= ives an > > > >>> incentive to applications to mark some packets with higher dr= op > > > >>> precedence, yet requires applications to know that the normal= izer is > > > >>> in place or else the service would be different. > > > >>> > > > >>> Maybe different DSCP values would be needed - but then this c= an't be > > > >>> used in combination with "regular" DiffServ usage. It really = depends > > > >>> on the signaling - ideas are now being tossed around by Colin= and > > > >>> Toerless, who clearly both know more about what the right sig= naling > > > >>> could be than me. > > > >>> > > > >>> Cheers, > > > >>> Michael > > > >>> > > > >>> > > > >>> On 15. okt. 2013, at 19:04, Kevin Gross > > > >>> wrote: > > > >>> > > > >>> I think you're stretching here. I don't think the balance is = right. > > > >>> The proposed information is difficult to retrieve and of litt= le use > > > >>> to much of the network. Even if standardized, it is unlikely = to be > > > >>> successful. > > > >>> > > > >>> The ideas in the normalizer draft don't seem to have so many = issues > > > >>> and I think it answers your original question and sets out to= achieve > > > >>> what you're looking for. > > > >>> > > > >>> Kevin Gross > > > >>> +1-303-447-0517 > > > >>> Media Network Consultant > > > >>> AVA Networks - www.AVAnw.com > > > >>> > > > >>> On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl > wrote: > > > >>>> Hi, > > > >>>> > > > >>>> I'll dissect your second and third sentences and tell you wh= at I > > > >>>> think about each part :-) below: > > > >>>> > > > >>>> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > > >>>>> No, not per 5 tuple (per flow). I don't think that is somet= hing we > > > >>>> > > > >>>> should ask of the network. > > > >>>> > > > >>>> I agree that asking this of the network may seem like encour= aging > > > >>>> per-flow functionality; in particular, if we'd put this into= IP, > > > >>>> that would be ugly. However, it's just a matter of fact that= there > > > >>>> are devices that do identify flows, and then, why not give s= uch > > > >>>> devices some guidance? I like Toerless' suggestion of makin= g this > > > >>>> an RTP header extension field: if a device is identifying fl= ows, we > > > >>>> can expect such a device to identify such a field too. Plus,= if we > > > >>>> think of end systems playing an intermediate system role in = RTP > > > >>>> (mixers, ..), these devices might also benefit from that sor= t of > > > >>>> information. > > > >>>> > > > >>>>> It doesn't sit well with the end-to-end principle > > > >>>> > > > >>>> I disagree, this is an all-too-common misunderstanding of th= e > > > >>>> end-to-end principle: it only says that whatever can be done= in the > > > >>>> application should be left up to the application, but it doe= sn't say > > > >>>> that you mustn't identify application streams inside the net= work or > > > >>>> "keep the network simple and stupid". If you do "keep the ne= twork > > > >>>> stupid", you're definitely in line with the e2e argument, bu= t the > > > >>>> argument isn't as strict as that (a typical example is routi= ng, > > > >>>> which can well become as complex as you wish, without harmin= g the > > > >>>> end-to-end principle). Now here we're discussing a function = where > > > >>>> the application really can't help you: when congestion happe= ns > > > >>>> inside the network and a packet must be dropped there, the b= est the > > > >>>> application can do is tell you which packet to drop. > > > >>>> > > > >>>>> and it won't scale. > > > >>>> > > > >>>> I agree. But it doesn't have to, just because we introduce t= he > > > >>>> signal we don't harm scalability - devices at the edges of t= he > > > >>>> network could deal with it, all other devices could ignore i= t. > > > >>>> > > > >>>> Cheers, > > > >>>> Michael > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=C3=BChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From roland.bless@kit.edu Fri Oct 18 00:25:16 2013 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 4CCB121F9D87 for ; Fri, 18 Oct 2013 00:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-+x3tCcIGJo for ; Fri, 18 Oct 2013 00:25:10 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id ECF4B21F9E14 for ; Fri, 18 Oct 2013 00:25:08 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1VX4Qc-0004lf-9z for ; Fri, 18 Oct 2013 09:25:00 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 for id 1VX4Qj-0000Ez-BT; Fri, 18 Oct 2013 09:25:05 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 2C85EA804E6 for ; Fri, 18 Oct 2013 09:25:05 +0200 (CEST) Message-ID: <5260E250.9080102@kit.edu> Date: Fri, 18 Oct 2013 09:25:04 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <57e2-5260ce80-b-1fe79060@95907578> In-Reply-To: <57e2-5260ce80-b-1fe79060@95907578> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1382081100. Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 07:25:16 -0000 Hi, On 18.10.2013 07:59, LOCHIN Emmanuel wrote: > Your proposal is not random because in terms of probability, all packets are not considered as an independent event anymore. > IMHO the simply thing is to classify packets with and without "drop precedence" bit set into two separate queues (can be FIFO or RED) for a given class > and to schedule both queues with a round robin or priority queuing scheme. But by using separate queues you'll get reordered packets within a microflow (e2e data stream) and AF class, which is not allowed by the AF PHB group specification. Regards, Roland From Emmanuel.LOCHIN@isae.fr Fri Oct 18 00:30:39 2013 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 1F81F21F9E50 for ; Fri, 18 Oct 2013 00:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0dbjxTQqRVu for ; Fri, 18 Oct 2013 00:30:33 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id C9DED21F9E1A for ; Fri, 18 Oct 2013 00:30:32 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with ESMTP id 31DC222E49E; Fri, 18 Oct 2013 09:30:28 +0200 (CEST) Received: from smtp-secu (smtp-secu.isae.fr [193.54.120.15]) by catalpa (Postfix) with ESMTP id 4E92BB7D5E; Fri, 18 Oct 2013 09:30:31 +0200 (CEST) Received: from [10.75.100.30] (unknown [37.161.121.215]) by smtp-secu (Postfix) with ESMTP id CA10F3FF3C; Fri, 18 Oct 2013 09:30:30 +0200 (CEST) References: <57e2-5260ce80-b-1fe79060@95907578> <5260E250.9080102@kit.edu> User-Agent: mySecureMail/2.1.1.7186 In-Reply-To: <5260E250.9080102@kit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Emmanuel Lochin Date: Fri, 18 Oct 2013 09:29:23 +0200 To: "Bless, Roland (TM)" ,rmcat@ietf.org Message-ID: <06f77be1-2edc-436a-b2b1-2173f78dee33@email.android.com> Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 07:30:39 -0000 But when you declassify AF trafic in another AF class or in the best-effort one you might also get reordering. If this is a problem, the only solution is, I think, to implement a pushout mechanism that drops marked packets when the queue is full. Emmanuel "Bless, Roland (TM)" wrote: >Hi, > >On 18.10.2013 07:59, LOCHIN Emmanuel wrote: >> Your proposal is not random because in terms of probability, all >packets are not considered as an independent event anymore. >> IMHO the simply thing is to classify packets with and without "drop >precedence" bit set into two separate queues (can be FIFO or RED) for a >given class >> and to schedule both queues with a round robin or priority queuing >scheme. > >But by using separate queues you'll get reordered packets within a >microflow (e2e data stream) and AF class, which is not allowed by the >AF PHB group specification. > >Regards, > Roland From roland.bless@kit.edu Fri Oct 18 05:05:35 2013 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 597C211E8201 for ; Fri, 18 Oct 2013 05:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE7Nv7varCTT for ; Fri, 18 Oct 2013 05:05:29 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA1011E81FD for ; Fri, 18 Oct 2013 05:05:23 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1VX8nk-0008Gv-UM; Fri, 18 Oct 2013 14:05:14 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1VX8ns-00050x-4P; Fri, 18 Oct 2013 14:05:16 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id EFA61A80119; Fri, 18 Oct 2013 14:05:15 +0200 (CEST) Message-ID: <526123FB.4090807@kit.edu> Date: Fri, 18 Oct 2013 14:05:15 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Emmanuel Lochin , rmcat@ietf.org References: <57e2-5260ce80-b-1fe79060@95907578> <5260E250.9080102@kit.edu> <06f77be1-2edc-436a-b2b1-2173f78dee33@email.android.com> In-Reply-To: <06f77be1-2edc-436a-b2b1-2173f78dee33@email.android.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1382097914. Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 12:05:35 -0000 Hi Emmanuel, Am 18.10.2013 09:29, schrieb Emmanuel Lochin: > But when you declassify AF trafic in another AF class or in the best-effort one you might also get reordering. That's actually a different story and falls more into the PDB concept than into a PHB concept. Furthermore, we are talking about reordering caused by PHB _implementations_, so getting reordered packets by routing is quite a different story, too. With DiffServ one usually assumes that the DS domains have at least some agreement on how they treat the aggregates. For PHBs it's quite well defined (though there is still some room left for variation), but if you remark traffic between different PHBs, it's something the service user should be aware of (could be part of a PDB specification). > If this is a problem, the only solution is, I think, to implement a pushout mechanism that drops marked packets when the queue is full. Yes, maybe. But how do you determine eligible packets? Starting from the front of the queue, considering makred packets of all flows, of only your own microflow or by using some randomized selection scheme? Regards, Roland From eckert@cisco.com Fri Oct 18 06:51:43 2013 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 9F24E11E81CD for ; Fri, 18 Oct 2013 06:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2J-JpCcqtsg for ; Fri, 18 Oct 2013 06:51:38 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9732411E81C4 for ; Fri, 18 Oct 2013 06:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2159; q=dns/txt; s=iport; t=1382104298; x=1383313898; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=/hB8KOVnygXcAPR98M9dsWoN26Ld7lEVbFvdolPyqmI=; b=N68R4J8aeIMWzB4W1tpchNlhMpAkel3/pw4qiaGhGO57V8BYa97B/llk wrspTD2lPkLWgwz7eio/H1/3dgw4fv9IAlaNkiPD6P/lGvdZ2dXh55wg1 o6uKL1KQ0IUT2UrtzqDWfjF3TqnCK4MpIj3DMJPXZ1m+h82opBUM6Xpp5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAK87YVKrRDoJ/2dsb2JhbABagwe/KoEkFnSCJQEBAQQ6PxALGAklDwVJExuHasEAj1YHgx+BCgOJP45JAZIHg0Qc X-IronPort-AV: E=Sophos;i="4.93,522,1378857600"; d="scan'208";a="94948877" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2013 13:51:35 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9IDpYLT023367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 13:51:34 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9IDpYRH017021; Fri, 18 Oct 2013 06:51:34 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9IDpX3t017017; Fri, 18 Oct 2013 06:51:33 -0700 Date: Fri, 18 Oct 2013 06:51:33 -0700 From: Toerless Eckert To: Emmanuel Lochin Message-ID: <20131018135133.GB9464@cisco.com> References: <57e2-5260ce80-b-1fe79060@95907578> <5260E250.9080102@kit.edu> <06f77be1-2edc-436a-b2b1-2173f78dee33@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06f77be1-2edc-436a-b2b1-2173f78dee33@email.android.com> User-Agent: Mutt/1.4.2.2i Cc: rmcat@ietf.org, "Bless, Roland \(TM\)" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 13:51:43 -0000 IMHO, whatever PHB is most feasible to achieve the desired priority-dropping is the one to use or to define. If packet reordering between the priorities would be a result, then IMHO thats would be a perfectly good price to pay given how receivers have playout buffers. And if that means that AF would be unusable becaue of it's "no-reorder" policy, then so be it. Its just that i don't think that it is either necessary nor beneficial to use a mechanism that leads to persistent reordering to solve the priority-dropping requirement. If you just created different weighted queues for the different priorities, i think you've achieved nothing towards priority dropping: If the ratio of traffic in the priority bucket stays the same, but you've got bursts that in total exceed the aggregate bandwidth available, you just start dropping across all priorities proportional to their BW-share. Thats not the desired behavior. So, IMHO, single queue with different drop thresholds for different priorities is perfectly fine and does not cause reordering. Cheers Toerless On Fri, Oct 18, 2013 at 09:29:23AM +0200, Emmanuel Lochin wrote: > But when you declassify AF trafic in another AF class or in the best-effort one you might also get reordering. > > If this is a problem, the only solution is, I think, to implement a pushout mechanism that drops marked packets when the queue is full. > > Emmanuel > > > "Bless, Roland (TM)" wrote: > > >Hi, > > > >On 18.10.2013 07:59, LOCHIN Emmanuel wrote: > >> Your proposal is not random because in terms of probability, all > >packets are not considered as an independent event anymore. > >> IMHO the simply thing is to classify packets with and without "drop > >precedence" bit set into two separate queues (can be FIFO or RED) for a > >given class > >> and to schedule both queues with a round robin or priority queuing > >scheme. > > > >But by using separate queues you'll get reordered packets within a > >microflow (e2e data stream) and AF class, which is not allowed by the > >AF PHB group specification. > > > >Regards, > > Roland From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 18 07:08:20 2013 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 03E5111E818F for ; Fri, 18 Oct 2013 07:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOf3HQST2VC2 for ; Fri, 18 Oct 2013 07:08:16 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9234A11E817F for ; Fri, 18 Oct 2013 07:08:15 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id CB5E960283; Fri, 18 Oct 2013 16:08:14 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id B6AB160282; Fri, 18 Oct 2013 16:08:14 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Fri, 18 Oct 2013 16:08:14 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <201310171547.36116.mirja.kuehlewind@ikr.uni-stuttgart.de> <20131017141555.GA9464@cisco.com> In-Reply-To: <20131017141555.GA9464@cisco.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310181608.14414.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Bernard Aboba , Toerless Eckert , Michael Welzl , Kevin Gross Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 14:08:20 -0000 Hi Toerless, can you provide these results? I can't imagine that this will be worse than= =20 droptail without this mechanism. Sure it doesn't help in terms of=20 bufferbloat. This is a problem you have to address differently. But it=20 shouldn't worsen the problem, no? And at least it will help the application= =20 to better deal with packets drops/losses. Mirja On Thursday 17 October 2013 16:15:55 Toerless Eckert wrote: > Mirja, > > Simple drop-tail configs for the different classes yielded IMHO > quite good results. > > WRED just adds more parameters (with the slope). Routers may support only > WRED and no explicit drop-tail, so one can easily use WRED to create > a drop-tail config via a WRED config, but leveraging the slope in WREP > is something IMHO related to the CC mechanism used so we didn't play arou= nd > too much with that yet (priority dropping is meant to react faster than > CC). > > What you describe last is what we called the "oracle", aka the method > that we thought could be used in simulation at least as a theoretical > "best-possible-drop-priority" mechanism. And no, you're right, it does not > exist in router products. Luckily it turned out to actually be worse than > droptail. I have some analsysis slide that tries to explain why. Hint: > bufferbloat ;-) > > Cheers > Toerless > > On Thu, Oct 17, 2013 at 03:47:36PM +0200, Mirja Kuehlewind wrote: > > Hi, > > > > I have a (quick) question as you are talking about using existing DSCP > > vs. some kind of "intra-flow drop precedence" signaling. You only have > > been talking about the signaling so far. But what would be the expected > > network behavior/reaction? > > > > With AF4x classed if believe you will have to calculate different drop > > probabilities for each class based on a different parameter set for RED > > (or something similar...?), right? > > > > I would always have envisioned an behavior where you calculate the same > > drop probability for every packet or even use DropTail. Then if a packet > > is about to be dropped, you look into the queue and try to find another > > packet of the same flow but with the "drop precedence" bit set. If you > > find one, you drop this packet instead, if not you drop the original > > (incoming) packet. Does such a mechanism exist anywhere? > > > > Mirja > > > > On Wednesday 16 October 2013 19:53:16 Toerless Eckert wrote: > > > On Wed, Oct 16, 2013 at 09:22:00AM +0200, Michael Welzl wrote: > > > > ....so we'd really need "intra-flow drop precedence" bits, to > > > > inter-work with existing DSCP values and get the expected PHB, righ= t? > > > > (or do as you say, define the PHB + precedence, for all possible > > > > combinations) > > > > > > Right. And independent of those intra-flow priority bits there is > > > IMHO still the open question whether the existing DSCP/PHB best suit > > > what we would want for RMcat. > > > > > > > > And then the DSCP still get reset along the path, and apps still > > > > > have problems setting DSCP across various OSs. > > > > > > > > There is also an architectural side to it: Kevin rightfully started > > > > this conversation by saying: "No, not per 5 tuple (per flow). I don= 't > > > > think that is something we should ask of the network." Indeed, doing > > > > this right *requires* routers (or whatever box does that) to identi= fy > > > > flows and keep track of them. Such per-flow functionality isn't what > > > > we want "normal" routers to do, I think, and so binding DSCP values > > > > to such a functionality just seems wrong to me. In a way, it makes > > > > the IP header less self-contained: in order to implement all the > > > > functions encoded in it, you need to look beyond the IP header. This > > > > doesn't strike me as good design. > > > > > > Flow-awareness is not evil, and there are a lot more proof points of > > > deployment where it works and scales than IMHO places where its needed > > > and does not scale. All enterprise routers i know do heavily leverage > > > flow awareness. > > > > > > Flow awareness for intra-flow priority can easily be designed to > > > require the same amount of flow awareness as existing QoS problems. > > > Specifically for QoS-authorization on the edge (and for intra-flow > > > priority, that authorization could mean normalization). I think that= 's > > > waht you're also saying below. > > > > > > > I think it's not too much to ask of devices that identify flows to > > > > look beyond the IP header for a shim, RTP-something, or whatever we > > > > define. Then, this device can aggregate flows into the right DSCPs = if > > > > it knows that traffic's going to traverse a path where the normaliz= er > > > > is present - and the normalizing devices again only need to look at > > > > the IP header, where it's all per-aggregate. (sorry for repeating > > > > myself, I thought I'd say this again here just for context, but I d= id > > > > say this before) > > > > > > Right. > > > > > > There is also some fundamental insight into what a "correct" layer is > > > that i think the IETF is missing. With IPv6, they just carried over t= he > > > IPv4 design without reviewing why router-alert and IP packet options > > > didn't catch on in IPv4 for onpath operations. After 30 years > > > regurgitating what's not working, it's IMHO rally time to give IETF > > > blessings to some other approach, and clean well reviewed designs with > > > such network aware extensions in the transport layer IMHO is exactly > > > that (whether it's shim layer, SCTP extensions, RTP header extension = or > > > what hae you - that's just a mattter of use-case priorities). > > > > > > > > > Cheers > > > toerless > > > > > > Cheers, > > > > > > > Michael > > > > > > > > > Cheers > > > > > Toerless > > > > > > > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > > > >> Maybe I skimmed it too quickly but my understanding is that the > > > > >> proposal is to remark DSCP values at the ingress point of the > > > > >> network and possibly at other key boundaries too. Such DSCP > > > > >> remapping is already common practice in enterprise networks. > > > > >> > > > > >> The twist here is that the remapper will do the remapping > > > > >> dynamically based on the proportion of AFn1, AFn2 and AFn3 packe= ts > > > > >> received from a sender. A greedy sender that it producing only > > > > >> AF41 markings will get some of those randomly remarked as AF42 a= nd > > > > >> AF43. > > > > >> > > > > >> The proposal uses existing DSCP values and it doesn't look like > > > > >> signaling is necessary nor is it necessary for the application to > > > > >> know that this is happening. > > > > >> > > > > >> Kevin Gross > > > > >> +1-303-447-0517 > > > > >> Media Network Consultant > > > > >> AVA Networks - www.AVAnw.com > > > > >> > > > > >> On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl > > > > >> > > > > wrote: > > > > >>> Hmm. Whether the balance is right or not might depend on how the > > > > >>> signaling is done. Anyway, unless I misunderstood something, the > > > > >>> way the normalizer now stands it won't really make a change: it > > > > >>> gives an incentive to applications to mark some packets with > > > > >>> higher drop precedence, yet requires applications to know that > > > > >>> the normalizer is in place or else the service would be > > > > >>> different. > > > > >>> > > > > >>> Maybe different DSCP values would be needed - but then this can= 't > > > > >>> be used in combination with "regular" DiffServ usage. It really > > > > >>> depends on the signaling - ideas are now being tossed around by > > > > >>> Colin and Toerless, who clearly both know more about what the > > > > >>> right signaling could be than me. > > > > >>> > > > > >>> Cheers, > > > > >>> Michael > > > > >>> > > > > >>> > > > > >>> On 15. okt. 2013, at 19:04, Kevin Gross > > > > >>> wrote: > > > > >>> > > > > >>> I think you're stretching here. I don't think the balance is > > > > >>> right. The proposed information is difficult to retrieve and of > > > > >>> little use to much of the network. Even if standardized, it is > > > > >>> unlikely to be successful. > > > > >>> > > > > >>> The ideas in the normalizer draft don't seem to have so many > > > > >>> issues and I think it answers your original question and sets o= ut > > > > >>> to achieve what you're looking for. > > > > >>> > > > > >>> Kevin Gross > > > > >>> +1-303-447-0517 > > > > >>> Media Network Consultant > > > > >>> AVA Networks - www.AVAnw.com > > > > >>> > > > > >>> On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl > > > > >>> > > > > wrote: > > > > >>>> Hi, > > > > >>>> > > > > >>>> I'll dissect your second and third sentences and tell you what= I > > > > >>>> think about each part :-) below: > > > > >>>> > > > > >>>> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > > > >>>>> No, not per 5 tuple (per flow). I don't think that is somethi= ng > > > > >>>>> we > > > > >>>> > > > > >>>> should ask of the network. > > > > >>>> > > > > >>>> I agree that asking this of the network may seem like > > > > >>>> encouraging per-flow functionality; in particular, if we'd put > > > > >>>> this into IP, that would be ugly. However, it's just a matter = of > > > > >>>> fact that there are devices that do identify flows, and then, > > > > >>>> why not give such devices some guidance? I like Toerless' > > > > >>>> suggestion of making this an RTP header extension field: if a > > > > >>>> device is identifying flows, we can expect such a device to > > > > >>>> identify such a field too. Plus, if we think of end systems > > > > >>>> playing an intermediate system role in RTP (mixers, ..), these > > > > >>>> devices might also benefit from that sort of information. > > > > >>>> > > > > >>>>> It doesn't sit well with the end-to-end principle > > > > >>>> > > > > >>>> I disagree, this is an all-too-common misunderstanding of the > > > > >>>> end-to-end principle: it only says that whatever can be done in > > > > >>>> the application should be left up to the application, but it > > > > >>>> doesn't say that you mustn't identify application streams insi= de > > > > >>>> the network or "keep the network simple and stupid". If you do > > > > >>>> "keep the network stupid", you're definitely in line with the > > > > >>>> e2e argument, but the argument isn't as strict as that (a > > > > >>>> typical example is routing, which can well become as complex as > > > > >>>> you wish, without harming the end-to-end principle). Now here > > > > >>>> we're discussing a function where the application really can't > > > > >>>> help you: when congestion happens inside the network and a > > > > >>>> packet must be dropped there, the best the application can do = is > > > > >>>> tell you which packet to drop. > > > > >>>> > > > > >>>>> and it won't scale. > > > > >>>> > > > > >>>> I agree. But it doesn't have to, just because we introduce the > > > > >>>> signal we don't harm scalability - devices at the edges of the > > > > >>>> network could deal with it, all other devices could ignore it. > > > > >>>> > > > > >>>> Cheers, > > > > >>>> Michael > > > > -- > > ------------------------------------------------------------------- > > Dipl.-Ing. Mirja K=FChlewind > > Institute of Communication Networks and Computer Engineering (IKR) > > University of Stuttgart, Germany > > Pfaffenwaldring 47, D-70569 Stuttgart > > > > tel: +49(0)711/685-67973 > > email: mirja.kuehlewind@ikr.uni-stuttgart.de > > web: www.ikr.uni-stuttgart.de > > ------------------------------------------------------------------- =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 18 07:17:33 2013 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 CCF2411E81CF for ; Fri, 18 Oct 2013 07:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZzjUkcP0Y2Y for ; Fri, 18 Oct 2013 07:17:29 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 71B0C21F9D52 for ; Fri, 18 Oct 2013 07:17:27 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id B7E4360283; Fri, 18 Oct 2013 16:17:26 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id A23B160282; Fri, 18 Oct 2013 16:17:26 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Fri, 18 Oct 2013 16:17:26 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <57e2-5260ce80-b-1fe79060@95907578> In-Reply-To: <57e2-5260ce80-b-1fe79060@95907578> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310181617.26152.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Bernard Aboba , Toerless Eckert , Michael Welzl , LOCHIN Emmanuel , Kevin Gross Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 14:17:33 -0000 Hi Emmanuel, yes, it's not random because the goal to potentially avoid losses for some= =20 packets. But it's still random on a per flow basis; which means flows will= =20 see drops proportional to their bandwidth share. That's the important part! I believe my proposal is actually more simple that handling different queue= s,=20 and you can avoid such problems like reordering (as already discussed) or=20 disincentive to set the bit because your traffic might get treated worse. If you have different queues and use round robin, you might actually end up= =20 that you 'drop precedence' packet get treated better than the other traffic= ,=20 if e.g. the bandwidth share of these packets is smaller... I believe this=20 makes things really complicated... Mirja On Friday 18 October 2013 07:59:30 LOCHIN Emmanuel wrote: > Hi Mirja > > Your proposal is not random because in terms of probability, all packets > are not considered as an independent event anymore. IMHO the simply thing > is to classify packets with and without "drop precedence" bit set into two > separate queues (can be FIFO or RED) for a given class and to schedule bo= th > queues with a round robin or priority queuing scheme. > > EL > > Le Jeudi 17 Octobre 2013 15:47 CEST, Mirja Kuehlewind=20 a =C3=A9crit: > > Hi, > > > > I have a (quick) question as you are talking about using existing DSCP > > vs. some kind of "intra-flow drop precedence" signaling. You only have > > been talking about the signaling so far. But what would be the expected > > network behavior/reaction? > > > > With AF4x classed if believe you will have to calculate different drop > > probabilities for each class based on a different parameter set for RED > > (or something similar...?), right? > > > > I would always have envisioned an behavior where you calculate the same > > drop probability for every packet or even use DropTail. Then if a packet > > is about to be dropped, you look into the queue and try to find another > > packet of the same flow but with the "drop precedence" bit set. If you > > find one, you drop this packet instead, if not you drop the original > > (incoming) packet. > > > > Does such a mechanism exist anywhere? > > > > Mirja > > > > On Wednesday 16 October 2013 19:53:16 Toerless Eckert wrote: > > > On Wed, Oct 16, 2013 at 09:22:00AM +0200, Michael Welzl wrote: > > > > ....so we'd really need "intra-flow drop precedence" bits, to > > > > inter-work with existing DSCP values and get the expected PHB, righ= t? > > > > (or do as you say, define the PHB + precedence, for all possible > > > > combinations) > > > > > > Right. And independent of those intra-flow priority bits there is > > > IMHO still the open question whether the existing DSCP/PHB best suit > > > what we would want for RMcat. > > > > > > > > And then the DSCP still get reset along the path, and apps still > > > > > have problems setting DSCP across various OSs. > > > > > > > > There is also an architectural side to it: Kevin rightfully started > > > > this conversation by saying: "No, not per 5 tuple (per flow). I don= 't > > > > think that is something we should ask of the network." Indeed, doing > > > > this right *requires* routers (or whatever box does that) to identi= fy > > > > flows and keep track of them. Such per-flow functionality isn't what > > > > we want "normal" routers to do, I think, and so binding DSCP values > > > > to such a functionality just seems wrong to me. In a way, it makes > > > > the IP header less self-contained: in order to implement all the > > > > functions encoded in it, you need to look beyond the IP header. This > > > > doesn't strike me as good design. > > > > > > Flow-awareness is not evil, and there are a lot more proof points of > > > deployment where it works and scales than IMHO places where its needed > > > and does not scale. All enterprise routers i know do heavily leverage > > > flow awareness. > > > > > > Flow awareness for intra-flow priority can easily be designed to > > > require the same amount of flow awareness as existing QoS problems. > > > Specifically for QoS-authorization on the edge (and for intra-flow > > > priority, that authorization could mean normalization). I think that= 's > > > waht you're also saying below. > > > > > > > I think it's not too much to ask of devices that identify flows to > > > > look beyond the IP header for a shim, RTP-something, or whatever we > > > > define. Then, this device can aggregate flows into the right DSCPs = if > > > > it knows that traffic's going to traverse a path where the normaliz= er > > > > is present - and the normalizing devices again only need to look at > > > > the IP header, where it's all per-aggregate. (sorry for repeating > > > > myself, I thought I'd say this again here just for context, but I d= id > > > > say this before) > > > > > > Right. > > > > > > There is also some fundamental insight into what a "correct" layer is > > > that i think the IETF is missing. With IPv6, they just carried over t= he > > > IPv4 design without reviewing why router-alert and IP packet options > > > didn't catch on in IPv4 for onpath operations. After 30 years > > > regurgitating what's not working, it's IMHO rally time to give IETF > > > blessings to some other approach, and clean well reviewed designs with > > > such network aware extensions in the transport layer IMHO is exactly > > > that (whether it's shim layer, SCTP extensions, RTP header extension = or > > > what hae you - that's just a mattter of use-case priorities). > > > > > > > > > Cheers > > > toerless > > > > > > Cheers, > > > > > > > Michael > > > > > > > > > Cheers > > > > > Toerless > > > > > > > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > > > >> Maybe I skimmed it too quickly but my understanding is that the > > > > >> proposal is to remark DSCP values at the ingress point of the > > > > >> network and possibly at other key boundaries too. Such DSCP > > > > >> remapping is already common practice in enterprise networks. > > > > >> > > > > >> The twist here is that the remapper will do the remapping > > > > >> dynamically based on the proportion of AFn1, AFn2 and AFn3 packe= ts > > > > >> received from a sender. A greedy sender that it producing only > > > > >> AF41 markings will get some of those randomly remarked as AF42 a= nd > > > > >> AF43. > > > > >> > > > > >> The proposal uses existing DSCP values and it doesn't look like > > > > >> signaling is necessary nor is it necessary for the application to > > > > >> know that this is happening. > > > > >> > > > > >> Kevin Gross > > > > >> +1-303-447-0517 > > > > >> Media Network Consultant > > > > >> AVA Networks - www.AVAnw.com > > > > >> > > > > >> On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl > > > > >> > > > > wrote: > > > > >>> Hmm. Whether the balance is right or not might depend on how the > > > > >>> signaling is done. Anyway, unless I misunderstood something, the > > > > >>> way the normalizer now stands it won't really make a change: it > > > > >>> gives an incentive to applications to mark some packets with > > > > >>> higher drop precedence, yet requires applications to know that > > > > >>> the normalizer is in place or else the service would be > > > > >>> different. > > > > >>> > > > > >>> Maybe different DSCP values would be needed - but then this can= 't > > > > >>> be used in combination with "regular" DiffServ usage. It really > > > > >>> depends on the signaling - ideas are now being tossed around by > > > > >>> Colin and Toerless, who clearly both know more about what the > > > > >>> right signaling could be than me. > > > > >>> > > > > >>> Cheers, > > > > >>> Michael > > > > >>> > > > > >>> > > > > >>> On 15. okt. 2013, at 19:04, Kevin Gross > > > > >>> wrote: > > > > >>> > > > > >>> I think you're stretching here. I don't think the balance is > > > > >>> right. The proposed information is difficult to retrieve and of > > > > >>> little use to much of the network. Even if standardized, it is > > > > >>> unlikely to be successful. > > > > >>> > > > > >>> The ideas in the normalizer draft don't seem to have so many > > > > >>> issues and I think it answers your original question and sets o= ut > > > > >>> to achieve what you're looking for. > > > > >>> > > > > >>> Kevin Gross > > > > >>> +1-303-447-0517 > > > > >>> Media Network Consultant > > > > >>> AVA Networks - www.AVAnw.com > > > > >>> > > > > >>> On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl > > > > >>> > > > > wrote: > > > > >>>> Hi, > > > > >>>> > > > > >>>> I'll dissect your second and third sentences and tell you what= I > > > > >>>> think about each part :-) below: > > > > >>>> > > > > >>>> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > > > >>>>> No, not per 5 tuple (per flow). I don't think that is somethi= ng > > > > >>>>> we > > > > >>>> > > > > >>>> should ask of the network. > > > > >>>> > > > > >>>> I agree that asking this of the network may seem like > > > > >>>> encouraging per-flow functionality; in particular, if we'd put > > > > >>>> this into IP, that would be ugly. However, it's just a matter = of > > > > >>>> fact that there are devices that do identify flows, and then, > > > > >>>> why not give such devices some guidance? I like Toerless' > > > > >>>> suggestion of making this an RTP header extension field: if a > > > > >>>> device is identifying flows, we can expect such a device to > > > > >>>> identify such a field too. Plus, if we think of end systems > > > > >>>> playing an intermediate system role in RTP (mixers, ..), these > > > > >>>> devices might also benefit from that sort of information. > > > > >>>> > > > > >>>>> It doesn't sit well with the end-to-end principle > > > > >>>> > > > > >>>> I disagree, this is an all-too-common misunderstanding of the > > > > >>>> end-to-end principle: it only says that whatever can be done in > > > > >>>> the application should be left up to the application, but it > > > > >>>> doesn't say that you mustn't identify application streams insi= de > > > > >>>> the network or "keep the network simple and stupid". If you do > > > > >>>> "keep the network stupid", you're definitely in line with the > > > > >>>> e2e argument, but the argument isn't as strict as that (a > > > > >>>> typical example is routing, which can well become as complex as > > > > >>>> you wish, without harming the end-to-end principle). Now here > > > > >>>> we're discussing a function where the application really can't > > > > >>>> help you: when congestion happens inside the network and a > > > > >>>> packet must be dropped there, the best the application can do = is > > > > >>>> tell you which packet to drop. > > > > >>>> > > > > >>>>> and it won't scale. > > > > >>>> > > > > >>>> I agree. But it doesn't have to, just because we introduce the > > > > >>>> signal we don't harm scalability - devices at the edges of the > > > > >>>> network could deal with it, all other devices could ignore it. > > > > >>>> > > > > >>>> Cheers, > > > > >>>> Michael > > > > -- > > ------------------------------------------------------------------- > > Dipl.-Ing. Mirja K=C3=BChlewind > > Institute of Communication Networks and Computer Engineering (IKR) > > University of Stuttgart, Germany > > Pfaffenwaldring 47, D-70569 Stuttgart > > > > tel: +49(0)711/685-67973 > > email: mirja.kuehlewind@ikr.uni-stuttgart.de > > web: www.ikr.uni-stuttgart.de > > ------------------------------------------------------------------- =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=C3=BChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 18 07:28:17 2013 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 C062311E81D9 for ; Fri, 18 Oct 2013 07:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+pWYLwgdDWP for ; Fri, 18 Oct 2013 07:28:13 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 05EE911E81F3 for ; Fri, 18 Oct 2013 07:28:13 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 64E0360284 for ; Fri, 18 Oct 2013 16:28:12 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 57AF460283 for ; Fri, 18 Oct 2013 16:28:12 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat@ietf.org Date: Fri, 18 Oct 2013 16:28:11 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201310181628.11870.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [rmcat] Agenda uploaded X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 14:28:18 -0000 Hi working group, I've just uploaded the current version of the next meeting's agenda: http://www.ietf.org/proceedings/88/agenda/agenda-88-rmcat Please let me know, if something needs to be changed or added! Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 18 07:44:28 2013 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 CBF3A11E82CA for ; Fri, 18 Oct 2013 07:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w44DiEOOGTvi for ; Fri, 18 Oct 2013 07:44:23 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACDF11E819D for ; Fri, 18 Oct 2013 07:44:20 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 95CD560284 for ; Fri, 18 Oct 2013 16:44:19 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 891C660283 for ; Fri, 18 Oct 2013 16:44:19 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat@ietf.org Date: Fri, 18 Oct 2013 16:44:19 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201310181644.19038.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [rmcat] application/traffic model X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 14:44:28 -0000 Hi group, looking at the current status and proposed scenarios regarding the evaluation criteria, and taking previous comments on the mic into account, I believe one crucial thing we need to proceed is some kind of application/traffic model. Obviously assuming greedy sources is not enough for the evaluation of media traffic scenarios. Under the assumption that there will be an interface between transport congestion control and the application (see milestone app-interactions), a simple traffic that is from time to time application-limited might also not be enough. And using a real set of examples videos in simulation is propably quite hard. I believe we could actually need more input from the application designers itself meaning the people that are (also) involved in rtcweb. If considered useful, we can try to book a room on Sunday to discuss this topic and also announce this to rtcweb...? Any interested? Otherwise let us know if you, and especially the design team, need a room to further discuss the evaluation criteria anyway! Mirja From Emmanuel.LOCHIN@isae.fr Fri Oct 18 08:50:44 2013 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 CCC5611E8263 for ; Fri, 18 Oct 2013 08:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDU+N5yIGk-2 for ; Fri, 18 Oct 2013 08:50:34 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1413411E8264 for ; Fri, 18 Oct 2013 08:50:33 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with ESMTP id 2660722E493; Fri, 18 Oct 2013 17:50:25 +0200 (CEST) Received: from [10.33.1.1] (pc-lochin.isae.fr [10.33.1.1]) by catalpa (Postfix) with ESMTP id 0661CB7D5E; Fri, 18 Oct 2013 17:50:33 +0200 (CEST) Message-ID: <52615915.60000@isae.fr> Date: Fri, 18 Oct 2013 17:51:49 +0200 From: Emmanuel Lochin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Bless, Roland (TM)" , rmcat@ietf.org References: <57e2-5260ce80-b-1fe79060@95907578> <5260E250.9080102@kit.edu> <06f77be1-2edc-436a-b2b1-2173f78dee33@email.android.com> <526123FB.4090807@kit.edu> In-Reply-To: <526123FB.4090807@kit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 15:50:44 -0000 On 18/10/2013 14:05, Bless, Roland (TM) wrote: > Hi Emmanuel, Hi Roland, > Am 18.10.2013 09:29, schrieb Emmanuel Lochin: >> But when you declassify AF trafic in another AF class or in the best-effort one you might also get reordering. > That's actually a different story and falls more into the PDB concept > than into a PHB concept. Furthermore, we are talking about reordering > caused by PHB _implementations_, so getting reordered packets by routing > is quite a different story, too. > > With DiffServ one usually assumes that the DS domains have at least > some agreement on how they treat the aggregates. For PHBs it's quite > well defined (though there is still some room left for variation), but > if you remark traffic between different PHBs, it's something the > service user should be aware of (could be part of a PDB specification). Ok, thanks for these clarifications :) > >> If this is a problem, the only solution is, I think, to implement a pushout mechanism that drops marked packets when the queue is full. > Yes, maybe. But how do you determine eligible packets? > Starting from the front of the queue, considering makred packets of > all flows, of only your own microflow or by using some randomized > selection scheme? Considering a simple Push-Out implementation, as soon as the queue is full and you get an incoming non-marked packet, you have to drop one marked packet previously enqueued. Might be the last one or the first one enqueued. This has to be evaluated. Emmanuel > > Regards, > Roland > -- Emmanuel Lochin Professeur ISAE - OSSI Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" From geertv@qti.qualcomm.com Fri Oct 18 10:45:51 2013 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 5660311E82E7 for ; Fri, 18 Oct 2013 10:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 143h540geXIO for ; Fri, 18 Oct 2013 10:45:47 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 072F811E82E9 for ; Fri, 18 Oct 2013 10:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1382118343; x=1413654343; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AcrH2QWMoNBCl6lWBElgddxHRwvDkfb6DXnaE61ZJLg=; b=edwQGa9w0di4KX8nSy2yu5pX6Y90U/dE4ed4lKjinKGrBigUpPAso+P2 RZ1r9y/sCC5njpTkll4YkWM+GLhSXTWMwWz2uc3e93uDGYxXvHggWapO6 WouhQtFQL6B1ZyJitPakjpKpnS6UB1f0MvZ1ovtfrkOf+lLdkfLjVWJ43 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7232"; a="54302241" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 18 Oct 2013 10:45:43 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7232"; a="624700958" Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Oct 2013 10:45:42 -0700 Received: from NASANEXD02B.na.qualcomm.com ([169.254.2.138]) by NASANEXHC03.na.qualcomm.com ([172.30.48.26]) with mapi id 14.03.0158.001; Fri, 18 Oct 2013 10:45:42 -0700 From: "Van Der Auwera, Geert" To: Ingemar Johansson S , Manuel Gorius , Michael Welzl Thread-Topic: [rmcat] draft-vanderauwera-rmcat-video-quality Thread-Index: AQHOyMGl+gLGCv2ZD0SP3S+Z7fqMDpn1+7cAgAAB5TCAAVvdAIAABtgAgAAhOoCAAZS7AIABlvVQ Date: Fri, 18 Oct 2013 17:45:41 +0000 Message-ID: <4FC1F85139E6FE4D9A55BD6798B29A4816AD4A57@NASANEXD02B.na.qualcomm.com> References: <6F0A5342-E5EF-44DD-94C2-9EB97FFE3A07@netapp.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39A74E@ESESSMB205.ericsson.se> <4FC1F85139E6FE4D9A55BD6798B29A4816AD20A5@NASANEXD02B.na.qualcomm.com> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39B113@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA1C39C0DC@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA1C39C0DC@ESESSMB205.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rmcat WG , "Eggert, Lars" Subject: Re: [rmcat] draft-vanderauwera-rmcat-video-quality X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 17:45:51 -0000 Thank you for the paper; it also has an interesting reference list. Buffer = size is an important parameter and it should indeed be chosen carefully in = the test scenarios. There seems to be the need to evaluate congestion contr= ol under several buffer size conditions. On the other hand, it is better no= t to have an excessive amount of test cases. What's the feeling on two buff= er sizes in the tests and are there any suggestions, for example, 10 and 32= packets (1Mbps link)? Best regards, Geert -----Original Message----- From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]=20 Sent: Thursday, October 17, 2013 2:14 AM To: Manuel Gorius; Michael Welzl Cc: Van Der Auwera, Geert; rmcat WG; Eggert, Lars Subject: RE: [rmcat] draft-vanderauwera-rmcat-video-quality Hi I believe that the closest to some kind of an adaptive delay-based to loss= -based congestion control is the Hamilton Delay TCP (thanks for the heads u= p Mirja!).=20 http://eprints.nuim.ie/1745/1/HamiltonDelayAIMD.pdf I have not experimented with it though so I can't comment on the usefulness= .=20 /Ingemar > -----Original Message----- > From: Manuel Gorius [mailto:gorius@nt.uni-saarland.de] > Sent: den 16 oktober 2013 11:05 > To: Michael Welzl > Cc: Ingemar Johansson S; Van Der Auwera, Geert; rmcat WG; Eggert, Lars > Subject: Re: [rmcat] draft-vanderauwera-rmcat-video-quality >=20 >=20 > On 16.10.2013, at 09:06, Michael Welzl wrote: >=20 > > > > On 16. okt. 2013, at 08:42, Ingemar Johansson S wrote: > > > >> Hi > >> > >> Thanks for the reply. > >> I assumed 1500byte packeys which gives almost 400ms delay. > >> As I see it it seems a bit pessimistic with a ratio 30-40 between=20 > >> latency > under load and min RTT. > >> I am fully aware of the bufferbloat problem but isn't there a risk=20 > >> that this > becomes a corner case and that it might drive designs in a direction=20 > that makes them suboptimal for the main operating conditions. > >> > >> To take an example: In order for the RMCAT flow to be able to=20 > >> compete > with an FTP using TCP Reno or Cubic over this bottleneck, it becomes=20 > necessary that the RMCAT flow contributes to the bufferbloat for=20 > instance by increasing a target delay or whatever. Unless the RMCAT=20 > flow gets some magic information from the network, it needs to infer=20 > information about the existence of competing flows, it can work more=20 > or less well and I see before be a lot of special code to do this,=20 > some of it actually becomes engineered to solve this particular test case= . > > > > Measured delay can serve as this "magic information"... > > > > > >> The problem with this is that this added intelligence can actually=20 > >> increase > the risk that the RMCAT flow it self creates self-inflicted congestion=20 > due to faulty decisions, meaning that the RMCAT flow it self locks it=20 > self in 400ms RTT even though there is no competing traffic. > > > > That would be the result of a badly designed congestion controller.=20 > > I don't > think that this naturally follows from trying to minimize delay, yet=20 > compete with TCP when it is present. > > > Designing a sophisticated congestion controller in order to address=20 > this problem is still challenging, though (are there any such=20 > solutions available so far?). We performed experiments with=20 > delay-based congestion control where we ran into exactly the same=20 > issue: The intensity of the delay-based flows had to be increased in=20 > order to compete with loss-based TCP-flows in environments with huge=20 > buffers. At the same time it is probably desirable that the queues=20 > aren't filled excessively in case there is only delay-controlled=20 > traffic. I think for a delay-based decision, the controller has to=20 > learn the range of the delay variation in such environments (maybe=20 > incorporating loss-based feedback as well) and must derive a suitable=20 > weighting for the congestion feedback in order to keep the flow=20 > competitive under an increasing number of loss-based flows. Having a mixt= ure of loss- and delay-based feedback could solve the problem of self-infli= cted congestion in my opinion. >=20 > Best regards, > Manuel From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 18 10:45:56 2013 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 4BF9711E825D for ; Fri, 18 Oct 2013 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yBW3IxQyqYh for ; Fri, 18 Oct 2013 10:45:51 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 767D711E82B4 for ; Fri, 18 Oct 2013 10:45:50 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id A393660281; Fri, 18 Oct 2013 19:45:49 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9606B60280; Fri, 18 Oct 2013 19:45:49 +0200 (CEST) From: Mirja =?utf-8?q?K=C3=BChlewind?= To: rmcat@ietf.org Date: Fri, 18 Oct 2013 19:45:49 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <57e2-5260ce80-b-1fe79060@95907578> <526123FB.4090807@kit.edu> <52615915.60000@isae.fr> In-Reply-To: <52615915.60000@isae.fr> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201310181945.49296.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "Bless, Roland \(TM\)" , Emmanuel Lochin Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 17:45:56 -0000 Hi Emmanuel, > >> If this is a problem, the only solution is, I think, to implement a > >> pushout mechanism that drops marked packets when the queue is full. > > > > Yes, maybe. But how do you determine eligible packets? > > Starting from the front of the queue, considering makred packets of > > all flows, of only your own microflow or by using some randomized > > selection scheme? > > Considering a simple Push-Out implementation, as soon as the queue is > full and you get an incoming non-marked packet, you have to drop one > marked packet previously enqueued. > Might be the last one or the first one enqueued. This has to be evaluated. If you do this, there is a disincentive to mark packets (as 'drop precedence') as this will treat you worse than flows that don't mark at all or at least less. That's why I proposed to look for a marked packet of the same flow only. If there is no marked packet of the same flow in the queue, you drop the original packets. Because than this flow presumably does not have any packets that are important to not get dropped or the flow did just ignore the possibility of marking but than it's its own fault. Mirja From xiaoqzhu@cisco.com Fri Oct 18 17:36:55 2013 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 AE56811E80EE for ; Fri, 18 Oct 2013 17:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH-nXuh5w+jO for ; Fri, 18 Oct 2013 17:36:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 135E111E80D9 for ; Fri, 18 Oct 2013 17:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1458; q=dns/txt; s=iport; t=1382143010; x=1383352610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q47yAdPAF/c7T3DpYEQCK/aOam8cGzpTuzBh+kMqPBQ=; b=dQM4WlZqkwQJpMwjZk1xQ+8qBSgPAABPF599klgtxK5dg3+vuMYrIuWe I01stb6Oi4r3+QB8VmGel4h9+y+Z5fjUfmphnCKXyvdj8vPAQdaDzTDe4 I9tKc3xUCE24BKlK2A0iSDwyQSQt1DQzIUNAob6LsLJFx4vKKR6YJMFOR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAAHTYVKtJXG//2dsb2JhbABagmYhgQq+K4EkFnSCJQEBAQMBeQULAgEIIgsZMiUCBA4FCId4BgHAWo4XgQwCMQcKgxWBCgOJB6EJgySBaEI X-IronPort-AV: E=Sophos;i="4.93,526,1378857600"; d="scan'208";a="273961940" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 19 Oct 2013 00:36:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9J0an4Z031656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Oct 2013 00:36:49 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 19:36:49 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: [rmcat] application/traffic model Thread-Index: AQHOzBCOboYbeJdcVUyf6MD5tZSBQZn7gkcA Date: Sat, 19 Oct 2013 00:36:48 +0000 Message-ID: References: <201310181644.19038.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201310181644.19038.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.146.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <10F5579FCFC9C9448BD7BB6D6CCA01EB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rmcat] application/traffic model X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 00:36:55 -0000 I will be happy to contribute to this one and describe the video source mod= el we used for NADA.=20 You want this to be a draft?=20 Best, Xiaoqing On Oct 18, 2013, at 9:44 AM, Mirja K=FChlewind wrote: > Hi group, >=20 > looking at the current status and proposed scenarios regarding the evalua= tion=20 > criteria, and taking previous comments on the mic into account, I believe= one=20 > crucial thing we need to proceed is some kind of application/traffic mode= l. >=20 > Obviously assuming greedy sources is not enough for the evaluation of med= ia=20 > traffic scenarios. Under the assumption that there will be an interface=20 > between transport congestion control and the application (see milestone=20 > app-interactions), a simple traffic that is from time to time=20 > application-limited might also not be enough. And using a real set of=20 > examples videos in simulation is propably quite hard. >=20 > I believe we could actually need more input from the application designer= s=20 > itself meaning the people that are (also) involved in rtcweb. If consider= ed=20 > useful, we can try to book a room on Sunday to discuss this topic and als= o=20 > announce this to rtcweb...? >=20 > Any interested?=20 >=20 > Otherwise let us know if you, and especially the design team, need a room= to=20 > further discuss the evaluation criteria anyway! >=20 > Mirja From Emmanuel.LOCHIN@isae.fr Fri Oct 18 23:46:25 2013 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 D1B7711E817A for ; Fri, 18 Oct 2013 23:46:25 -0700 (PDT) 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=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEjr59c0pM7g for ; Fri, 18 Oct 2013 23:46:21 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id 892D511E8179 for ; Fri, 18 Oct 2013 23:46:17 -0700 (PDT) Received: from supmail (unknown [10.132.1.9]) by smtpext.isae.fr (Postfix) with ESMTP id 8AE7B22E2EF; Sat, 19 Oct 2013 08:46:13 +0200 (CEST) Received: from wali.isae.fr (wali.isae.fr [10.132.1.26]) by supmail (Postfix) with ESMTP id 20F35C884FC; Sat, 19 Oct 2013 08:46:16 +0200 (CEST) User-Agent: SOGoMail 2.0.7 X-Forward: 81.56.87.55 MIME-Version: 1.0 from: "LOCHIN Emmanuel" message-id: <2322-52622a80-5b-21cb4240@161088665> to: =?utf-8?q?Mirja_K=C3=BChlewind?= content-type: text/plain; charset="utf-8" date: Sat, 19 Oct 2013 08:46:15 +0200 in-reply-to: <201310181945.49296.mirja.kuehlewind@ikr.uni-stuttgart.de> content-transfer-encoding: quoted-printable Cc: rmcat@ietf.org, "Bless, Roland \(TM\)" , pascal.anelli@univ-reunion.fr Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 06:46:25 -0000 Le Vendredi 18 Octobre 2013 19:45 CEST, Mirja K=C3=BChlewind a =C3=A9crit: Hi Mirja, That's interesting :) I did a presentation at the last ICCRG meeting in= Berlin about an AQM that does this kind of operation. I mean, looking whether an incoming packet belongs to a flow of packets= previously enqueued. Except that in my case, the objective is to dequeue this incoming packe= t first if it does not belong to a flow previously enqueued. The goal is to decrease the overall latency following a well-known queu= ing theory property which states that short jobs should be served first= . See for details: http://arxiv.org/abs/1103.2303 One big comment during my presentation in Berlin came from a router ven= dor (I think) who said that such kind of classification (based for inst= ance on a hash table) is not scalable and not deployable inside a core router. On my side, I've implemented such = thing inside ns-2 and I am currently porting the code inside TC GNU/Lin= ux API for edge router (I do not target core router anyway). Other thing, you'll see inside my paper, that such classification is st= rongly linked to the traffic pattern and that the dropping policy based= on such classification can be greatly unfair as a function of the traffic pattern (in particular the burstiness and the pacing) and h= ow the sizing of the queue is done (sized with the BDP product, larger,= smaller ...). So, following my experience and looking at my statistical analysis (htt= p://arxiv.org/abs/1103.2303), I believe that you might have unfairness = in terms of video quality between flows crossing the same path by using such dropping policy. If I have a bit of time, I= 'll send you some simulation results based on your proposal to check th= is intuition. Emmanuel > Hi Emmanuel, > > > >> If this is a problem, the only solution is, I think, to implemen= t a > > >> pushout mechanism that drops marked packets when the queue is fu= ll. > > > > > > Yes, maybe. But how do you determine eligible packets? > > > Starting from the front of the queue, considering makred packets = of > > > all flows, of only your own microflow or by using some randomized= > > > selection scheme? > > > > Considering a simple Push-Out implementation, as soon as the queue = is > > full and you get an incoming non-marked packet, you have to drop on= e > > marked packet previously enqueued. > > Might be the last one or the first one enqueued. This has to be eva= luated. > > If you do this, there is a disincentive to mark packets (as 'drop pre= cedence') > as this will treat you worse than flows that don't mark at all or at = least > less. > > That's why I proposed to look for a marked packet of the same flow on= ly. If > there is no marked packet of the same flow in the queue, you drop the= > original packets. Because than this flow presumably does not have any= packets > that are important to not get dropped or the flow did just ignore the= > possibility of marking but than it's its own fault. > > Mirja From michawe@ifi.uio.no Sat Oct 19 02:45:32 2013 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 BD2FA21F9EFB for ; Sat, 19 Oct 2013 02:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKF7kyA0piTs for ; Sat, 19 Oct 2013 02:45:27 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id A3FE411E819C for ; Sat, 19 Oct 2013 02:45:26 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VXT65-000258-FH; Sat, 19 Oct 2013 11:45:25 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.104]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VXT65-000590-0G; Sat, 19 Oct 2013 11:45:25 +0200 References: <201310181644.19038.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <5B55B5EC-79DB-4178-AEA6-7D023ADE8AB5@ifi.uio.no> X-Mailer: iPhone Mail (9B206) From: Michael Welzl Date: Sat, 19 Oct 2013 11:45:24 +0200 To: "Xiaoqing Zhu (xiaoqzhu)" X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 8 sum msgs/h 4 total rcpts 8791 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FB257C103E33A0693EE40B21C53A2242A8851BD0 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 344 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: "" , =?utf-8?Q?Mirja_K=C3=BChlewind?= Subject: Re: [rmcat] application/traffic model X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 09:45:32 -0000 And we'd be happy to use this! ns2 code would be especially welcome Sent from my iPhone On 19. okt. 2013, at 02:36, "Xiaoqing Zhu (xiaoqzhu)" w= rote: > I will be happy to contribute to this one and describe the video source mo= del we used for NADA.=20 >=20 > You want this to be a draft?=20 >=20 > Best, > Xiaoqing >=20 > On Oct 18, 2013, at 9:44 AM, Mirja K=C3=BChlewind wrote: >=20 >> Hi group, >>=20 >> looking at the current status and proposed scenarios regarding the evalua= tion=20 >> criteria, and taking previous comments on the mic into account, I believe= one=20 >> crucial thing we need to proceed is some kind of application/traffic mode= l. >>=20 >> Obviously assuming greedy sources is not enough for the evaluation of med= ia=20 >> traffic scenarios. Under the assumption that there will be an interface=20= >> between transport congestion control and the application (see milestone=20= >> app-interactions), a simple traffic that is from time to time=20 >> application-limited might also not be enough. And using a real set of=20 >> examples videos in simulation is propably quite hard. >>=20 >> I believe we could actually need more input from the application designer= s=20 >> itself meaning the people that are (also) involved in rtcweb. If consider= ed=20 >> useful, we can try to book a room on Sunday to discuss this topic and als= o=20 >> announce this to rtcweb...? >>=20 >> Any interested?=20 >>=20 >> Otherwise let us know if you, and especially the design team, need a room= to=20 >> further discuss the evaluation criteria anyway! >>=20 >> Mirja >=20 From mirja.kuehlewind@ikr.uni-stuttgart.de Sat Oct 19 06:17:42 2013 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 9FE4711E81D0 for ; Sat, 19 Oct 2013 06:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPdut1JEaQUK for ; Sat, 19 Oct 2013 06:17:38 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C60011E819E for ; Sat, 19 Oct 2013 06:17:38 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9DE04602D6; Sat, 19 Oct 2013 15:17:36 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 90956602D4; Sat, 19 Oct 2013 15:17:36 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: "Xiaoqing Zhu (xiaoqzhu)" Date: Sat, 19 Oct 2013 12:42:51 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201310181644.19038.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310191242.51095.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "" Subject: Re: [rmcat] application/traffic model X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 13:17:42 -0000 Hi Xiaoqing, it would be definitely good to have this documented in a way that others ca= n=20 easily access and use your model. I guess a draft is the easiest way to do= =20 this. Can't tell you yet what we will do with this draft in the working=20 group. But please go ahead an write it. Mirja On Saturday 19 October 2013 02:36:48 Xiaoqing Zhu (xiaoqzhu) wrote: > I will be happy to contribute to this one and describe the video source > model we used for NADA. > > You want this to be a draft? > > Best, > Xiaoqing > > On Oct 18, 2013, at 9:44 AM, Mirja K=FChlewind=20 wrote: > > Hi group, > > > > looking at the current status and proposed scenarios regarding the > > evaluation criteria, and taking previous comments on the mic into > > account, I believe one crucial thing we need to proceed is some kind of > > application/traffic model. > > > > Obviously assuming greedy sources is not enough for the evaluation of > > media traffic scenarios. Under the assumption that there will be an > > interface between transport congestion control and the application (see > > milestone app-interactions), a simple traffic that is from time to time > > application-limited might also not be enough. And using a real set of > > examples videos in simulation is propably quite hard. > > > > I believe we could actually need more input from the application > > designers itself meaning the people that are (also) involved in rtcweb. > > If considered useful, we can try to book a room on Sunday to discuss th= is > > topic and also announce this to rtcweb...? > > > > Any interested? > > > > Otherwise let us know if you, and especially the design team, need a ro= om > > to further discuss the evaluation criteria anyway! > > > > Mirja =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From vsingh.ietf@gmail.com Sun Oct 20 00:19:59 2013 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 7C4D611E8182 for ; Sun, 20 Oct 2013 00:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUCY9bH0Gs7v for ; Sun, 20 Oct 2013 00:19:58 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id AC77011E8165 for ; Sun, 20 Oct 2013 00:19:58 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so12169504ieb.23 for ; Sun, 20 Oct 2013 00:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=h6XMLxOgdhNXlaV43520BpzMUDI5z+97AFZLJduDMIQ=; b=GtwQsBphZex1jKN+frzJEyn+iKuXSRTsTDyY4tgOZluhcNUiThTKIroo4hgxeG9G40 /ZzhFqoUGQtYOq36pgqAb/eLHhLIVYtdYj2zlGvUMV5ZHvKqhK7dghuoWAEk/7ibI+F2 sn6fEQqvx0QPX+6CuA3pDsDmmX07WDRmZSGtgZtJ8hgVYMvs4BE8Ep1gwJHam97/0Vwq 3ZLonwHAh6NwzvXPYbe2pEavpHqqWH6rXRMDdm+NBxwNQ1LNA55kj4vgqshOkfv6LzqI 9M5Rbykpv+gkfr7+iqmrGk8GLS+wkPMq07NVwi2Cz72G7vsO+04hq1F1/WPBhqRNcVvU hybQ== X-Received: by 10.50.138.137 with SMTP id qq9mr222488igb.51.1382253598142; Sun, 20 Oct 2013 00:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sun, 20 Oct 2013 00:19:38 -0700 (PDT) From: Varun Singh Date: Sun, 20 Oct 2013 02:19:38 -0500 Message-ID: To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [rmcat] Recent papers evaluating RMCAT proposals X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 07:19:59 -0000 Hi all, Following is the list of papers that have recently been published about RMCAT proposals. I do not have pointers to all the papers, but if you know of any other evaluations or have links to the papers listed below. Experimental Investigation of the Google Congestion Control for Real-Time Flows, L. De Cicco, G. Carlucci, and S. Mascolo: http://c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf Performance Analysis of Receive-Side Real-Time Congestion Control for WebRTC; Singh V., Lozano A.A., Ott J., http://www.netlab.tkk.fi/~varun/singh2013rrtcc.pdf Understanding the Dynamic Behaviour of the Google Congestion Control, L. De Cicco, G. Carlucci, and S. Mascolo NADA: A Unified Congestion Control Scheme for Low-Latency Interactive Video, Xiaoqing Zhu, Rong Pan DFlow: Low latency congestion control: Piers O'Hanlon; Kenneth Carlberg Cheers, Varun -- http://www.netlab.tkk.fi/~varun/ From safiquli@ifi.uio.no Sun Oct 20 07:55:52 2013 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 2010F11E840A for ; Sun, 20 Oct 2013 07:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlVbHiBeRj1z for ; Sun, 20 Oct 2013 07:55:47 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id A469011E840C for ; Sun, 20 Oct 2013 07:55:37 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VXuPm-0001Rw-CP; Sun, 20 Oct 2013 16:55:34 +0200 Received: from 158.6.202.84.customer.cdi.no ([84.202.6.158] helo=[192.168.0.102]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user safiquli (Exim 4.80) (envelope-from ) id 1VXuPl-000065-GT; Sun, 20 Oct 2013 16:55:34 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_303D8FD8-979B-42D1-93EE-D65608DCC765" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Safiqul Islam In-Reply-To: Date: Sun, 20 Oct 2013 16:55:33 +0200 Message-Id: <12F6450E-BE8A-4472-97BA-5DAB196EB6E9@ifi.uio.no> References: To: rmcat WG X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 4 sum msgs/h 2 total rcpts 757 max rcpts/h 24 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9792083D72A26F1BC5CF717CE58341972DB6B53E X-UiO-SPAM-Test: remote_host: 84.202.6.158 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 5 max/h 2 blacklist 0 greylist 0 ratelimit 0 X-UiOonly: 2DAC4DDFBDD73318F5CCDEB54101E746D033D63F Cc: Varun Singh Subject: Re: [rmcat] Recent papers evaluating RMCAT proposals X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 14:55:52 -0000 --Apple-Mail=_303D8FD8-979B-42D1-93EE-D65608DCC765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi all, In addition, the following poster has also been accepted : "One Control to Rule Them All - Coupled Congestion Control for RTP = Media"; S. Islam, M. Welzl, and S. Gjessing=20 http://safiquli.at.ifi.uio.no/paper/pv2013-fse-poster-final.pdf Cheers, Safiqul On 20. okt. 2013, at 09:19, Varun Singh wrote: > Hi all, >=20 > Following is the list of papers that have recently been published > about RMCAT proposals. I do not have pointers to all the papers, but > if you know of any other evaluations or have links to the papers > listed below. >=20 > Experimental Investigation of the Google Congestion Control for > Real-Time Flows, L. De Cicco, G. Carlucci, and S. Mascolo: > http://c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf >=20 > Performance Analysis of Receive-Side Real-Time Congestion Control for > WebRTC; Singh V., Lozano A.A., Ott J., > http://www.netlab.tkk.fi/~varun/singh2013rrtcc.pdf >=20 > Understanding the Dynamic Behaviour of the Google Congestion Control, > L. De Cicco, G. Carlucci, and S. Mascolo >=20 > NADA: A Unified Congestion Control Scheme for Low-Latency Interactive > Video, Xiaoqing Zhu, Rong Pan >=20 > DFlow: Low latency congestion control: Piers O'Hanlon; Kenneth = Carlberg >=20 >=20 > Cheers, > Varun > --=20 > http://www.netlab.tkk.fi/~varun/ --Apple-Mail=_303D8FD8-979B-42D1-93EE-D65608DCC765 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = all,

In addition, the following poster has also = been accepted :

"One Control to Rule Them All - = Coupled Congestion Control for RTP Media"; S. Islam, M. Welzl, and S. = Gjessing 

=
Cheers,
Safiqul


On 20. okt. 2013, at 09:19, Varun Singh <vsingh.ietf@gmail.com> = wrote:

Hi all,

Following is the list of papers that have = recently been published
about RMCAT proposals. I do not have pointers = to all the papers, but
if you know of any other evaluations or have = links to the papers
listed below.

Experimental Investigation = of the Google Congestion Control for
Real-Time Flows, L. De Cicco, G. = Carlucci, and S. Mascolo:
http:/= /c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf

Performanc= e Analysis of Receive-Side Real-Time Congestion Control for
WebRTC; = Singh V., Lozano A.A., Ott = J.,
http://www.netlab.tkk.fi/~varun/singh2013rrtcc.pdf

Understan= ding the Dynamic Behaviour of the Google Congestion Control,
L. De = Cicco, G. Carlucci, and S. Mascolo

NADA: A Unified Congestion = Control Scheme for Low-Latency Interactive
Video, Xiaoqing Zhu, Rong = Pan

DFlow: Low latency congestion control: Piers O'Hanlon; = Kenneth Carlberg


Cheers,
Varun
-- =
http://www.netlab.tkk.fi/~varun/

= --Apple-Mail=_303D8FD8-979B-42D1-93EE-D65608DCC765-- From vsingh.ietf@gmail.com Sun Oct 20 09:00:05 2013 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 2A0FA21F99E9 for ; Sun, 20 Oct 2013 09:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBWNphg0iOzX for ; Sun, 20 Oct 2013 09:00:01 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB4021F9B35 for ; Sun, 20 Oct 2013 08:59:27 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id e14so9563382iej.39 for ; Sun, 20 Oct 2013 08:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=eQJQc17NTTtE6wLoq4qAKd9gN8O7ZOAM6kULN5Ega24=; b=yF5YeFZvRdaZsE+TlemOrsfuIUlMhNItygz+Yov8ayV3Cpb+aOImhWSXLCW9qqLo2n h4sbaHmHY0UvJd5W27qOmkOdfMVpemWDW9U5pCGjAo550rp7TEvh9ez+ppjRwTJwC7xb InHk53aNlGuOXkpPPSsywKr1bl81vJfp15BieOhz7+R9u/1+2oKZ8rv82ei+pW01+cRu CLDXX7X1ljUaoZRGavJWb1tERrqYjo110/G0Wl772tED47K7lepl3RabKbMtPUlJPAEd DfXHskED8jEUIC+moQgTQZU9WP22gy81KA9WYR1j6jPBQ31NOzWE1TveaXTxiyOGkVWf PGLw== X-Received: by 10.50.1.78 with SMTP id 14mr6443793igk.37.1382284766120; Sun, 20 Oct 2013 08:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sun, 20 Oct 2013 08:59:06 -0700 (PDT) In-Reply-To: <12F6450E-BE8A-4472-97BA-5DAB196EB6E9@ifi.uio.no> References: <12F6450E-BE8A-4472-97BA-5DAB196EB6E9@ifi.uio.no> From: Varun Singh Date: Sun, 20 Oct 2013 10:59:06 -0500 Message-ID: To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rmcat] Recent papers evaluating RMCAT proposals X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 16:00:05 -0000 Hi all, As a side note, some of the papers will be presented at the Packet Video Workshop on the 12-13 December in San Jose. If you are interested in these papers or multimedia streaming/communication, consider attending the conference. Details at: http://pv2013.itec.aau.at/ and list of accepted papers at: http://pv2013.itec.aau.at/list-of-accepted-papers/ Also, chapter 6 of a master thesis titled: Performance analysis of topologies for Web-based Real-Time Communication (WebRTC) maybe of interest to some of you (it is a slightly different version from our paper accepted at PV2013). https://aaltodoc.aalto.fi/bitstream/handle/123456789/11093/master_Abell%C3%B3_Lozano_Albert_2013.pdf?sequence=1 Cheers, Varun On Sun, Oct 20, 2013 at 9:55 AM, Safiqul Islam wrote: > Hi all, > > In addition, the following poster has also been accepted : > > "One Control to Rule Them All - Coupled Congestion Control for RTP Media"; > S. Islam, M. Welzl, and S. Gjessing > http://safiquli.at.ifi.uio.no/paper/pv2013-fse-poster-final.pdf > > Cheers, > Safiqul > > > On 20. okt. 2013, at 09:19, Varun Singh wrote: > > Hi all, > > Following is the list of papers that have recently been published > about RMCAT proposals. I do not have pointers to all the papers, but > if you know of any other evaluations or have links to the papers > listed below. > > Experimental Investigation of the Google Congestion Control for > Real-Time Flows, L. De Cicco, G. Carlucci, and S. Mascolo: > http://c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf > > Performance Analysis of Receive-Side Real-Time Congestion Control for > WebRTC; Singh V., Lozano A.A., Ott J., > http://www.netlab.tkk.fi/~varun/singh2013rrtcc.pdf > > Understanding the Dynamic Behaviour of the Google Congestion Control, > L. De Cicco, G. Carlucci, and S. Mascolo > > NADA: A Unified Congestion Control Scheme for Low-Latency Interactive > Video, Xiaoqing Zhu, Rong Pan > > DFlow: Low latency congestion control: Piers O'Hanlon; Kenneth Carlberg > > > Cheers, > Varun > -- > http://www.netlab.tkk.fi/~varun/ > > -- http://www.netlab.tkk.fi/~varun/ From vsingh.ietf@gmail.com Sun Oct 20 09:15:28 2013 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 7AE6F11E81CB for ; Sun, 20 Oct 2013 09:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3auyOLaG9Ope for ; Sun, 20 Oct 2013 09:15:27 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 90A0811E81E1 for ; Sun, 20 Oct 2013 09:15:26 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id ar20so10049687iec.0 for ; Sun, 20 Oct 2013 09:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=KVJJILaE/qyTt0tkbkRhYF5SyN/vU4yq1rzrdvqojv0=; b=JuZ8lsL6ThBLeWp7NcGCaY1+fOY2PJkw4FN+s6p1tcD62cbJKBKSQwaHorS9VBE7pg gMopMNER0ndeV3IUfCYh+CMqpAl6L4rFi+HuXHnnhuS1uk7/Tb0RdlAtEiMIkBh+KQxs cd3zWWA28bstCsGanLMpL2PdgZv2SyZGIOBMXXqhIIUg7QYC6ecuCiBTnaVM38AHCAK7 PIJMxAKFckkjoTd7RoDB+DeKrlo7pV/iyT6sUMvLNcM6PsfNYtpfjlHDxpGes06pvMJP 34jgMwspzQw3WLW1ZwHUKYnjQLzIR6djQKpEROVDOMYr48f/sQZUdgcmcQ+fxar+XxLh KQ/g== X-Received: by 10.42.62.196 with SMTP id z4mr560506ich.49.1382285725476; Sun, 20 Oct 2013 09:15:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sun, 20 Oct 2013 09:15:05 -0700 (PDT) In-Reply-To: <201310191242.51095.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201310181644.19038.mirja.kuehlewind@ikr.uni-stuttgart.de> <201310191242.51095.mirja.kuehlewind@ikr.uni-stuttgart.de> From: Varun Singh Date: Sun, 20 Oct 2013 11:15:05 -0500 Message-ID: To: Mirja Kuehlewind Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] application/traffic model X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 16:15:28 -0000 +1, evaluations that do not use video sequences would definitely gain from having a consistent media stream traffic generator. +1 also for a meeting on Sunday to discuss the traffic generator and input from application designers. Cheers, Varun On Sat, Oct 19, 2013 at 5:42 AM, Mirja Kuehlewind wrote: > Hi Xiaoqing, > > it would be definitely good to have this documented in a way that others = can > easily access and use your model. I guess a draft is the easiest way to d= o > this. Can't tell you yet what we will do with this draft in the working > group. But please go ahead an write it. > > Mirja > > > On Saturday 19 October 2013 02:36:48 Xiaoqing Zhu (xiaoqzhu) wrote: >> I will be happy to contribute to this one and describe the video source >> model we used for NADA. >> >> You want this to be a draft? >> >> Best, >> Xiaoqing >> >> On Oct 18, 2013, at 9:44 AM, Mirja K=FChlewind > wrote: >> > Hi group, >> > >> > looking at the current status and proposed scenarios regarding the >> > evaluation criteria, and taking previous comments on the mic into >> > account, I believe one crucial thing we need to proceed is some kind o= f >> > application/traffic model. >> > >> > Obviously assuming greedy sources is not enough for the evaluation of >> > media traffic scenarios. Under the assumption that there will be an >> > interface between transport congestion control and the application (se= e >> > milestone app-interactions), a simple traffic that is from time to tim= e >> > application-limited might also not be enough. And using a real set of >> > examples videos in simulation is propably quite hard. >> > >> > I believe we could actually need more input from the application >> > designers itself meaning the people that are (also) involved in rtcweb= . >> > If considered useful, we can try to book a room on Sunday to discuss t= his >> > topic and also announce this to rtcweb...? >> > >> > Any interested? >> > >> > Otherwise let us know if you, and especially the design team, need a r= oom >> > to further discuss the evaluation criteria anyway! >> > >> > Mirja > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- --=20 http://www.netlab.tkk.fi/~varun/ From internet-drafts@ietf.org Sun Oct 20 09:15:43 2013 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 079D611E81F4; Sun, 20 Oct 2013 09:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXI5d5+abs1g; Sun, 20 Oct 2013 09:15:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B59821F9FE5; Sun, 20 Oct 2013 09:15:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131020161542.22727.48641.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 09:15:42 -0700 Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-singh-rmcat-cc-eval-04.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 16:15:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RTP Media Congestion Avoidance Techniques= Working Group of the IETF. Title : Evaluating Congestion Control for Interactive Real-time = Media Author(s) : Varun Singh Joerg Ott Filename : draft-singh-rmcat-cc-eval-04.txt Pages : 19 Date : 2013-10-20 Abstract: The Real-time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-singh-rmcat-cc-eval There's also a htmlized version available at: http://tools.ietf.org/html/draft-singh-rmcat-cc-eval-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-singh-rmcat-cc-eval-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vsingh.ietf@gmail.com Sun Oct 20 09:27:06 2013 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 782AA11E81E9 for ; Sun, 20 Oct 2013 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzBREXjYGEF5 for ; Sun, 20 Oct 2013 09:27:05 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D410011E81E1 for ; Sun, 20 Oct 2013 09:27:05 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id u16so9662439iet.4 for ; Sun, 20 Oct 2013 09:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=cDWhaPSwU43ekRLqx38uKlYj+OgcOioiW5EABB1naak=; b=AoxRAiEfh3T6eM8NcD509neBNTBC9qy3ZSTHwjeRmESL5gPVl07Pt7R3RXDfq0MnOP kowhj9kdWCyhGzEhASWi5sGylLH+Kta9iCR2pYW+ZbI2PLnnn9M4bLPRfTlw18f+6FDZ 5DwHp++0DHbmGtfqanfzMRQD1X8gA9cFnv/6RL0vBVh84yjN1Bbfl6podIaMOeppLBLR DblD4Y6wm2EKyEsl9MPpyJaD8k3qw9/S6TPYI/GzNWcAid5zZDuEhRN3xuUrvmCgE9sX dLcjFmRLQPz/Nb9wT25VBbDmBHMbtFEwElhMjMZAds3cy9RvqHqoyacxYMdnrx17zge8 T/xg== X-Received: by 10.50.115.35 with SMTP id jl3mr6533938igb.37.1382286424945; Sun, 20 Oct 2013 09:27:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sun, 20 Oct 2013 09:26:44 -0700 (PDT) In-Reply-To: <20131020161542.22727.48641.idtracker@ietfa.amsl.com> References: <20131020161542.22727.48641.idtracker@ietfa.amsl.com> From: Varun Singh Date: Sun, 20 Oct 2013 11:26:44 -0500 Message-ID: To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rmcat] I-D Action: draft-singh-rmcat-cc-eval-04.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 16:27:06 -0000 Hi all, This update covers the feedback received at IETF87, Berlin. The main changes are: - Open issue: unfairness metric/criteria reworded into an "unfairness test" - Open issue: use of jain fairness index - clarified convergence time, bandwidth utilization - clarified on measuring losses, and post-repair losses (e.g., retx or FEC) - Kevin's comments on circuit breaker and I-frames - clarified only use Droptail for evaluation. This should be reconsidered again when we have more mature AQM proposals - retitled parameter set as an example parameter set, to convey that the numbers in the section are a guideline. - moved open issue on measuring quality to the appendix. No changes were made to the parameter set, the scenario in the appendix. This may change depending on how https://sites.google.com/site/ietfrmcatsolutionevaluations/home/ and draft-vanderauwera-rmcat-video-quality-00 progress. Cheers, Varun On Sun, Oct 20, 2013 at 11:15 AM, wrote: > > 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 Working Group of the IETF. > > Title : Evaluating Congestion Control for Interactive Real-time Media > Author(s) : Varun Singh > Joerg Ott > Filename : draft-singh-rmcat-cc-eval-04.txt > Pages : 19 > Date : 2013-10-20 > > Abstract: > The Real-time Transport Protocol (RTP) is used to transmit media in > telephony and video conferencing applications. This document > describes the guidelines to evaluate new congestion control > algorithms for interactive point-to-point real-time media. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-singh-rmcat-cc-eval > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-singh-rmcat-cc-eval-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-singh-rmcat-cc-eval-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > -- http://www.netlab.tkk.fi/~varun/ From michawe@ifi.uio.no Sun Oct 20 13:07:04 2013 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 513D311E842C for ; Sun, 20 Oct 2013 13:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd2V68puhwnW for ; Sun, 20 Oct 2013 13:06:46 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id EF8B211E822C for ; Sun, 20 Oct 2013 13:06:40 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VXzGn-0002ZS-5a; Sun, 20 Oct 2013 22:06:37 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VXzGm-00042T-JS; Sun, 20 Oct 2013 22:06:37 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <2322-52622a80-5b-21cb4240@161088665> Date: Sun, 20 Oct 2013 22:06:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9781A74D-1E09-4462-9A08-19BF1D99B4E4@ifi.uio.no> References: <2322-52622a80-5b-21cb4240@161088665> To: LOCHIN Emmanuel X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 8804 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 273F7E2B0E111B3279F9462DA102D8071748B882 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 353 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org, "Bless, Roland \(TM\)" , =?iso-8859-1?Q?Mirja_K=FChlewind?= , pascal.anelli@univ-reunion.fr Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 20:07:04 -0000 Hi Emmanuel, The last sentence here: (below) On 19. okt. 2013, at 08:46, LOCHIN Emmanuel = wrote: >=20 > Le Vendredi 18 Octobre 2013 19:45 CEST, Mirja K=FChlewind = a =E9crit: >=20 > Hi Mirja, >=20 > That's interesting :) I did a presentation at the last ICCRG meeting = in Berlin about an AQM that does this kind of operation. > I mean, looking whether an incoming packet belongs to a flow of = packets previously enqueued. > Except that in my case, the objective is to dequeue this incoming = packet first if it does not belong to a flow previously enqueued. > The goal is to decrease the overall latency following a well-known = queuing theory property which states that short jobs should be served = first. See for details: http://arxiv.org/abs/1103.2303 > One big comment during my presentation in Berlin came from a router = vendor (I think) who said that such kind of classification (based for = instance on a hash table) is not scalable and > not deployable inside a core router. On my side, I've implemented such = thing inside ns-2 and I am currently porting the code inside TC = GNU/Linux API for edge router (I do not target core router anyway). > Other thing, you'll see inside my paper, that such classification is = strongly linked to the traffic pattern and that the dropping policy = based on such classification can be greatly unfair as a function of > the traffic pattern (in particular the burstiness and the pacing) and = how the sizing of the queue is done (sized with the BDP product, larger, = smaller ...). > So, following my experience and looking at my statistical analysis = (http://arxiv.org/abs/1103.2303), I believe that you might have = unfairness in terms of video quality between flows crossing > the same path by using such dropping policy. ... sounds like a pretty general (not scoped to your mechanism only) = statement related to Mirja's proposal, and is, as such, perhaps too = pessimistic? I think it would be extremely important to avoid such unfairness (giving = the right incentives is the whole point!), and it should also be quite = easy, by simply requiring: *only* drop a packet from a flow if you would = have dropped a packet from that flow anyway, based on the "regular" AQM = rules =3D> *only* change *which* of the packets from that flow are = dropped, i.e. if there's a higher drop precedence packet, drop this one = instead of a lower drop precedence one. ...or am I completely off track?? Cheers, Michael > If I have a bit of time, I'll send you some simulation results based = on your proposal to check this intuition. >=20 > Emmanuel >=20 >> Hi Emmanuel, >>=20 >>>>> If this is a problem, the only solution is, I think, to implement = a >>>>> pushout mechanism that drops marked packets when the queue is = full. >>>>=20 >>>> Yes, maybe. But how do you determine eligible packets? >>>> Starting from the front of the queue, considering makred packets of >>>> all flows, of only your own microflow or by using some randomized >>>> selection scheme? >>>=20 >>> Considering a simple Push-Out implementation, as soon as the queue = is >>> full and you get an incoming non-marked packet, you have to drop one >>> marked packet previously enqueued. >>> Might be the last one or the first one enqueued. This has to be = evaluated. >>=20 >> If you do this, there is a disincentive to mark packets (as 'drop = precedence') >> as this will treat you worse than flows that don't mark at all or at = least >> less. >>=20 >> That's why I proposed to look for a marked packet of the same flow = only. If >> there is no marked packet of the same flow in the queue, you drop the >> original packets. Because than this flow presumably does not have any = packets >> that are important to not get dropped or the flow did just ignore the >> possibility of marking but than it's its own fault. >>=20 >> Mirja >=20 >=20 >=20 >=20 >=20 From eckert@cisco.com Sun Oct 20 16:57:12 2013 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 1C2ED11E82DD for ; Sun, 20 Oct 2013 16:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.25 X-Spam-Level: X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g8xftfUp75C for ; Sun, 20 Oct 2013 16:57:05 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4632D11E81D6 for ; Sun, 20 Oct 2013 16:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2620; q=dns/txt; s=iport; t=1382313423; x=1383523023; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=LL5o5HTs1hfsbBcEcXCiL+2530pTKvTO4+EpzMyWKAA=; b=jLBx6581+WTVOC8agqVTiNTlin+npn+TfTTFGKcBvwHEVz6HDdD6acSn oBh/Eva5PzRrXCGGuCrHsQNvI4tpMkUZ+wY9+jLbfIsdCWP1SzAiGJh9x 2G6ZIFhi9hjOuCHNRjBb3ibAGWj2cVP7M9mJZlqj8/ug/yNihEjwXVrmB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFADJtZFKrRDoH/2dsb2JhbABagwe/PoEkFnSCJQEBAQQ6PxALDgQGCSUPBTUUExuHar1uj1wHgx+BCgOJP45JAZIHg0Qc X-IronPort-AV: E=Sophos;i="4.93,535,1378857600"; d="scan'208";a="95097502" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 20 Oct 2013 23:57:02 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9KNv1BX001409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Oct 2013 23:57:01 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9KNuxLH010781; Sun, 20 Oct 2013 16:57:00 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9KNuwpP010778; Sun, 20 Oct 2013 16:56:58 -0700 Date: Sun, 20 Oct 2013 16:56:58 -0700 From: Toerless Eckert To: Michael Welzl Message-ID: <20131020235658.GA14037@cisco.com> References: <2322-52622a80-5b-21cb4240@161088665> <9781A74D-1E09-4462-9A08-19BF1D99B4E4@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9781A74D-1E09-4462-9A08-19BF1D99B4E4@ifi.uio.no> User-Agent: Mutt/1.4.2.2i Cc: rmcat@ietf.org, "Bless, Roland \(TM\)" , LOCHIN Emmanuel Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 23:57:12 -0000 Michael, I really think it's hard to see how to build this mechanism efficiently into HW. Even in general purpose CPU/memory it seems to be quite expensive. Given how we want low-latency, i think it is unlikley and undesirable that a single flow would have to have another low-priority frame in the queue if it has a high-priority frame that randomnly got elected to be dropped. On Sun, Oct 20, 2013 at 10:06:34PM +0200, Michael Welzl wrote: > I think it would be extremely important to avoid such unfairness (giving the right incentives is the whole point!), and it should also be quite easy, by simply requiring: *only* drop a packet from a flow if you would have dropped a packet from that flow anyway, based on the "regular" AQM rules => *only* change *which* of the packets from that flow are dropped, i.e. if there's a higher drop precedence packet, drop this one instead of a lower drop precedence one. > > ...or am I completely off track?? > > Cheers, > Michael > > > > > > If I have a bit of time, I'll send you some simulation results based on your proposal to check this intuition. > > > > Emmanuel > > > >> Hi Emmanuel, > >> > >>>>> If this is a problem, the only solution is, I think, to implement a > >>>>> pushout mechanism that drops marked packets when the queue is full. > >>>> > >>>> Yes, maybe. But how do you determine eligible packets? > >>>> Starting from the front of the queue, considering makred packets of > >>>> all flows, of only your own microflow or by using some randomized > >>>> selection scheme? > >>> > >>> Considering a simple Push-Out implementation, as soon as the queue is > >>> full and you get an incoming non-marked packet, you have to drop one > >>> marked packet previously enqueued. > >>> Might be the last one or the first one enqueued. This has to be evaluated. > >> > >> If you do this, there is a disincentive to mark packets (as 'drop precedence') > >> as this will treat you worse than flows that don't mark at all or at least > >> less. > >> > >> That's why I proposed to look for a marked packet of the same flow only. If > >> there is no marked packet of the same flow in the queue, you drop the > >> original packets. Because than this flow presumably does not have any packets > >> that are important to not get dropped or the flow did just ignore the > >> possibility of marking but than it's its own fault. > >> > >> Mirja > > > > > > > > > > > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From eckert@cisco.com Sun Oct 20 18:35:07 2013 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 0C59511E8307 for ; Sun, 20 Oct 2013 18:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljVzea-gNIbW for ; Sun, 20 Oct 2013 18:35:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E990811E80EC for ; Sun, 20 Oct 2013 18:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2594; q=dns/txt; s=iport; t=1382319302; x=1383528902; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=XWabogCJbYv+9XvxHZ47VTNF85hrulZK7Wklr8DgrWE=; b=KKCaz08RbrQwTbUz+l2B2jcqaNMZf+Rfc/ZJVcEaLMGUrYB+F+9nZnGU gA8itSFGPS4NoeSujnPggNx09tW/iT8Ls6lmAAKTDQgwOilD3hxitNMfV 2quAk/sOfx/EKfmDmkZbFGgWYIhrz9UygqigCl8txS2sNR/qageVBER5v o=; X-IronPort-AV: E=Sophos;i="4.93,536,1378857600"; d="scan'208";a="92589599" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 21 Oct 2013 01:35:01 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9L1Z0b2003056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 01:35:00 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9L1Ywtu016307; Sun, 20 Oct 2013 18:34:59 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9L1YwXJ016306; Sun, 20 Oct 2013 18:34:58 -0700 Date: Sun, 20 Oct 2013 18:34:58 -0700 From: Toerless Eckert To: Mirja@cisco.com, K@cisco.com Message-ID: <20131021013458.GB14037@cisco.com> References: <57e2-5260ce80-b-1fe79060@95907578> <526123FB.4090807@kit.edu> <52615915.60000@isae.fr> <201310181945.49296.mirja.kuehlewind@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201310181945.49296.mirja.kuehlewind@ikr.uni-stuttgart.de> User-Agent: Mutt/1.4.2.2i Cc: rmcat@ietf.org, "Bless, Roland \(TM\)" , Emmanuel Lochin Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 01:35:07 -0000 Fundamentally, any form of low-priority dropping in itself is a form of AQM even without other AQM enabled. Simple thought experiment: 20% packets/frames in flows are low priority. Assume we never have more than 20% drops in our queue, so we only drop low-priority packets. RED for example randomnly subsets flows to avoid global synchronization. priority dropping would select the flows who can best afford a loss (eg: the 20% flows with a low priority packet in the queue right now). Priority dropping is IMHO very beneficial, but it's not totally "free", aka: the application tht is marking priorities should better know what to expect and be preapred to react accordingly: If one in five frames in a flow is low priority (unrealistic but simple example for the sake of explanation), then a flow with 50 fps would see drops only once every 100 msec. So the rate-control should better not upspeed faster than that. A sender that marks priorities and only sees drop in low priority packets can likewise tune its rate , for example to linger around a low drop rate of low priority packets. Cheers Toerless On Fri, Oct 18, 2013 at 07:45:49PM +0200, Mirja K?hlewind wrote: > Hit Emmanuel, > > > >> If this is a problem, the only solution is, I think, to implement a > > >> pushout mechanism that drops marked packets when the queue is full. > > > > > > Yes, maybe. But how do you determine eligible packets? > > > Starting from the front of the queue, considering makred packets of > > > all flows, of only your own microflow or by using some randomized > > > selection scheme? > > > > Considering a simple Push-Out implementation, as soon as the queue is > > full and you get an incoming non-marked packet, you have to drop one > > marked packet previously enqueued. > > Might be the last one or the first one enqueued. This has to be evaluated. > > If you do this, there is a disincentive to mark packets (as 'drop precedence') > as this will treat you worse than flows that don't mark at all or at least > less. > > That's why I proposed to look for a marked packet of the same flow only. If > there is no marked packet of the same flow in the queue, you drop the > original packets. Because than this flow presumably does not have any packets > that are important to not get dropped or the flow did just ignore the > possibility of marking but than it's its own fault. > > Mirja -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From michawe@ifi.uio.no Mon Oct 21 00:13:07 2013 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 7CEF711E8321 for ; Mon, 21 Oct 2013 00:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7y4cDc1+pUb for ; Mon, 21 Oct 2013 00:13:02 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 114A411E8175 for ; Mon, 21 Oct 2013 00:13:01 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VY9ff-00061i-CY; Mon, 21 Oct 2013 09:12:59 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VY9fe-0003lq-BD; Mon, 21 Oct 2013 09:12:59 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_8A7B2C58-EA46-4499-9554-4419A87A7D2D" From: Michael Welzl In-Reply-To: <20131020235658.GA14037@cisco.com> Date: Mon, 21 Oct 2013 09:12:56 +0200 Message-Id: <6D8E353D-1D42-4E8A-ADEE-9A4A73F05A83@ifi.uio.no> References: <2322-52622a80-5b-21cb4240@161088665> <9781A74D-1E09-4462-9A08-19BF1D99B4E4@ifi.uio.no> <20131020235658.GA14037@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 8815 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EB17B481B497DE5615B28A38A3CB0C1B34E7A905 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 3460 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org, "Bless, Roland \(TM\)" , LOCHIN Emmanuel Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 07:13:07 -0000 --Apple-Mail=_8A7B2C58-EA46-4499-9554-4419A87A7D2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21. okt. 2013, at 01:56, Toerless Eckert wrote: > Michael, >=20 > I really think it's hard to see how to build this mechanism = efficiently > into HW. Even in general purpose CPU/memory it seems to be quite = expensive. 1) you said yourself that you target edge equipment. I think we can be a = bit more relaxed about such constraints there... 2) So what about CHOKe? Was that not implementable? CHOKe, upon arrival = of a packet, picked a random packet from the queue and dropped both if = they were from the same sender. This way it punished aggressive senders. = A variation of Mirja's suggestion could be a simple extension to CHOKe: = if the rule I just described says "yes, drop!", then you only drop the = packet with the higher drop precedence, not both. Someone could argue that dropping both is a key requirement of CHOKe, = but then my rule would make it less aggressive at dropping? So consider = gCHOKe, a scheme investigated by Addisu Eshete in his Ph.D. thesis: = http://ntnu.diva-portal.org/smash/record.jsf?pid=3Ddiva2:583155 a related paper: = http://www.sciencedirect.com/science/article/pii/S138912861200326X gCHOKe applies the CHOKe rule not once, but up to N times ("up to" = because it also stops if the check on a similar packet fails) in a row, = thereby dropping multiple packets from the queue in one go. As a = variation of gCHOKe that incorporates drop precedence, one could apply = "only drop the higher drop precedence packet" from iteration M Given how we want low-latency, i think it is unlikley and undesirable > that a single flow would have to have another low-priority frame in = the > queue if it has a high-priority frame that randomnly got elected to be = dropped. Well yes, the scheme would operate only quite rarely, given that the = queues are supposed to be small anyway. This would potentially limit its = benefits - by how much would have to be investigated (I think this is = one of the issues Toerless mentioned early on in this conversation). = Then again, I can't see how you can guarantee to a flow that setting = higher drop precedence for some of its packets wouldn't give the flow a = worse overall treatment than other flows in the network - and so there = is no incentive to use higher drop precedence marking in applications, = as today. Cheers, Michael >=20 > On Sun, Oct 20, 2013 at 10:06:34PM +0200, Michael Welzl wrote: >> I think it would be extremely important to avoid such unfairness = (giving the right incentives is the whole point!), and it should also be = quite easy, by simply requiring: *only* drop a packet from a flow if you = would have dropped a packet from that flow anyway, based on the = "regular" AQM rules =3D> *only* change *which* of the packets from that = flow are dropped, i.e. if there's a higher drop precedence packet, drop = this one instead of a lower drop precedence one. >>=20 >> ...or am I completely off track?? >>=20 >> Cheers, >> Michael >>=20 >>=20 >>=20 >>=20 >>> If I have a bit of time, I'll send you some simulation results based = on your proposal to check this intuition. >>>=20 >>> Emmanuel >>>=20 >>>> Hi Emmanuel, >>>>=20 >>>>>>> If this is a problem, the only solution is, I think, to = implement a >>>>>>> pushout mechanism that drops marked packets when the queue is = full. >>>>>>=20 >>>>>> Yes, maybe. But how do you determine eligible packets? >>>>>> Starting from the front of the queue, considering makred packets = of >>>>>> all flows, of only your own microflow or by using some randomized >>>>>> selection scheme? >>>>>=20 >>>>> Considering a simple Push-Out implementation, as soon as the queue = is >>>>> full and you get an incoming non-marked packet, you have to drop = one >>>>> marked packet previously enqueued. >>>>> Might be the last one or the first one enqueued. This has to be = evaluated. >>>>=20 >>>> If you do this, there is a disincentive to mark packets (as 'drop = precedence') >>>> as this will treat you worse than flows that don't mark at all or = at least >>>> less. >>>>=20 >>>> That's why I proposed to look for a marked packet of the same flow = only. If >>>> there is no marked packet of the same flow in the queue, you drop = the >>>> original packets. Because than this flow presumably does not have = any packets >>>> that are important to not get dropped or the flow did just ignore = the >>>> possibility of marking but than it's its own fault. >>>>=20 >>>> Mirja >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 --Apple-Mail=_8A7B2C58-EA46-4499-9554-4419A87A7D2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Michael,

I really think it's hard to see how = to build this mechanism efficiently
into HW. Even in general purpose = CPU/memory it seems to be quite = expensive.

1) you said yourself = that you target edge equipment. I think we can be a bit more relaxed = about such constraints there...
2) So what about CHOKe? Was = that not implementable? CHOKe, upon arrival of a packet, picked a random = packet from the queue and dropped both if they were from the same = sender. This way it punished aggressive senders. A variation = of Mirja's suggestion could be a simple extension to CHOKe: if the rule = I just described says "yes, drop!", then you only drop the packet with = the higher drop precedence, not both.

Someone = could argue that dropping both is a key requirement of CHOKe, but then = my rule would make it less aggressive at dropping? So consider gCHOKe, a = scheme investigated by Addisu Eshete in his Ph.D. thesis:  h= ttp://ntnu.diva-portal.org/smash/record.jsf?pid=3Ddiva2:583155
a related paper: http://www.sciencedirect.com/science/article/pii/S138912861200326X
gCHOKe applies the CHOKe rule not once, but up to N times ("up = to" because it also stops if the check on a similar packet fails) in a = row, thereby dropping multiple packets from the queue in one go. As a = variation of gCHOKe that incorporates drop precedence, one could apply = "only drop the higher drop precedence packet" from iteration M<N = onward or something.

Just an = example.


Given how we want low-latency, i think it is unlikley = and undesirable
that a single flow would have to have another = low-priority frame in the
queue if it has a high-priority frame that = randomnly got elected to be = dropped.

Well yes, the scheme = would operate only quite rarely, given that the queues are supposed to = be small anyway. This would potentially limit its benefits - by how much = would have to be investigated (I think this is one of the issues = Toerless mentioned early on in this conversation). Then again, I can't = see how you can guarantee to a flow that setting higher drop precedence = for some of its packets wouldn't give the flow a worse overall treatment = than other flows in the network - and so there is no incentive to use = higher drop precedence marking in applications, as = today.

Cheers,
Michael




On Sun, Oct = 20, 2013 at 10:06:34PM +0200, Michael Welzl wrote:
I think it would be extremely important to avoid such = unfairness (giving the right incentives is the whole point!), and it = should also be quite easy, by simply requiring: *only* drop a packet = from a flow if you would have dropped a packet from that flow anyway, = based on the "regular" AQM rules =3D> *only* change *which* of the = packets from that flow are dropped, i.e. if there's a higher drop = precedence packet, drop this one instead of a lower drop precedence = one.

...or am I = completely off track??

Cheers,
Michael




If I have a bit of time, I'll send you some simulation = results based on your proposal to check this = intuition.

Emmanuel

Hi = Emmanuel,

If this is a problem, the only = solution is, I think, to implement = a
pushout mechanism that drops = marked packets when the queue is = full.
=

Yes, = maybe. But how do you determine eligible = packets?
Starting= from the front of the queue, considering makred packets = of
all = flows, of only your own microflow or by using some = randomized
selection = scheme?

Considering a simple Push-Out = implementation, as soon as the queue = is
full and you get an incoming = non-marked packet, you have to drop = one
marked packet previously = enqueued.
Might be the last one or the = first one enqueued. This has to be = evaluated.

If you = do this, there is a disincentive to mark packets (as 'drop = precedence')
as = this will treat you worse than flows that don't mark at all or at = least
less.

That's = why I proposed to look for a marked packet of the same flow only. = If
there = is no marked packet of the same flow in the queue, you drop = the
original= packets. Because than this flow presumably does not have any = packets
that = are important to not get dropped or the flow did just ignore = the
possibility of marking but than it's its own = fault.

Mirja







--
---
Toerless Eckert, eckert@cisco.com
Cisco NSSTG = Systems & Technology Architecture
SDN: Let me play with the = network, = mommy!


= --Apple-Mail=_8A7B2C58-EA46-4499-9554-4419A87A7D2D-- From michawe@ifi.uio.no Mon Oct 21 01:08:52 2013 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 10AA911E8361 for ; Mon, 21 Oct 2013 01:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivbnsKhC3TKi for ; Mon, 21 Oct 2013 01:08:44 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id AB51911E817F for ; Mon, 21 Oct 2013 01:08:29 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VYAXD-00084R-Tx; Mon, 21 Oct 2013 10:08:19 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VYAXD-0000jQ-Bl; Mon, 21 Oct 2013 10:08:19 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_130D5E11-DD80-4B1F-9464-3FA169DE89F1" From: Michael Welzl In-Reply-To: Date: Mon, 21 Oct 2013 10:08:18 +0200 Message-Id: <7705ACD8-5AE1-4102-8B23-D2704A2A2A2C@ifi.uio.no> References: <12F6450E-BE8A-4472-97BA-5DAB196EB6E9@ifi.uio.no> To: Varun Singh X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 8820 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7417A0C6658D4F7FFE3F715161855866B9569BD0 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3464 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] Recent papers evaluating RMCAT proposals X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 08:08:52 -0000 --Apple-Mail=_130D5E11-DD80-4B1F-9464-3FA169DE89F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi all, I created this page now: http://www.openwiki.com/ow.asp?rmcat_bib Do with it whatever you wish - I thought it's useful to have such a = collection somewhere and it took < 5 minutes to create, that's why I did = it. openwiki has a rather messy look to it, but it's the only page of its = kind that I know... (zero security, everyone can edit) moving this to a somewhat "cleaner" page wouldn't hurt I guess.=20 On 20. okt. 2013, at 17:59, Varun Singh wrote: > Hi all, >=20 > As a side note, some of the papers will be presented at the Packet > Video Workshop > on the 12-13 December in San Jose. If you are interested in these > papers or multimedia > streaming/communication, consider attending the conference. Details > at: http://pv2013.itec.aau.at/ > and list of accepted papers at: > http://pv2013.itec.aau.at/list-of-accepted-papers/ >=20 > Also, chapter 6 of a master thesis titled: Performance analysis of > topologies for Web-based Real-Time Communication (WebRTC) > maybe of interest to some of you (it is a slightly different version > from our paper accepted at PV2013). > = https://aaltodoc.aalto.fi/bitstream/handle/123456789/11093/master_Abell%C3= %B3_Lozano_Albert_2013.pdf?sequence=3D1 >=20 > Cheers, > Varun >=20 > On Sun, Oct 20, 2013 at 9:55 AM, Safiqul Islam = wrote: >> Hi all, >>=20 >> In addition, the following poster has also been accepted : >>=20 >> "One Control to Rule Them All - Coupled Congestion Control for RTP = Media"; >> S. Islam, M. Welzl, and S. Gjessing >> http://safiquli.at.ifi.uio.no/paper/pv2013-fse-poster-final.pdf >>=20 >> Cheers, >> Safiqul >>=20 >>=20 >> On 20. okt. 2013, at 09:19, Varun Singh = wrote: >>=20 >> Hi all, >>=20 >> Following is the list of papers that have recently been published >> about RMCAT proposals. I do not have pointers to all the papers, but >> if you know of any other evaluations or have links to the papers >> listed below. >>=20 >> Experimental Investigation of the Google Congestion Control for >> Real-Time Flows, L. De Cicco, G. Carlucci, and S. Mascolo: >> http://c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf >>=20 >> Performance Analysis of Receive-Side Real-Time Congestion Control for >> WebRTC; Singh V., Lozano A.A., Ott J., >> http://www.netlab.tkk.fi/~varun/singh2013rrtcc.pdf >>=20 >> Understanding the Dynamic Behaviour of the Google Congestion Control, >> L. De Cicco, G. Carlucci, and S. Mascolo >>=20 >> NADA: A Unified Congestion Control Scheme for Low-Latency Interactive >> Video, Xiaoqing Zhu, Rong Pan >>=20 >> DFlow: Low latency congestion control: Piers O'Hanlon; Kenneth = Carlberg >>=20 >>=20 >> Cheers, >> Varun >> -- >> http://www.netlab.tkk.fi/~varun/ >>=20 >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ --Apple-Mail=_130D5E11-DD80-4B1F-9464-3FA169DE89F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = all,

I created this page now:

Do with it whatever you = wish - I thought it's useful to have such a collection somewhere and it = took < 5 minutes to create, that's why I did it.
openwiki = has a rather messy look to it, but it's the only page of its kind = that I know... (zero security, everyone can edit)
moving this = to a somewhat "cleaner" page wouldn't hurt I = guess. 


On 20. okt. 2013, at = 17:59, Varun Singh wrote:

Hi = all,

As a side note, some of the papers will be presented at the = Packet
Video Workshop
on the 12-13 December in San Jose. If you = are interested in these
papers or = multimedia
streaming/communication, consider attending the = conference. Details
at: http://pv2013.itec.aau.at/
and = list of accepted papers at:
http://pv2013.= itec.aau.at/list-of-accepted-papers/

Also, chapter 6 of a = master thesis titled: Performance analysis of
topologies for = Web-based Real-Time Communication (WebRTC)
maybe of interest to some = of you (it is a slightly different version
from our paper accepted at = PV2013).
https://aaltodoc.aalto.fi/bitstream/handle/123456789/11093/mas= ter_Abell%C3%B3_Lozano_Albert_2013.pdf?sequence=3D1

Cheers,
Varu= n

On Sun, Oct 20, 2013 at 9:55 AM, Safiqul Islam = <safiquli@ifi.uio.no> wrote:
Hi = all,

In addition, = the following poster has also been accepted = :

"One Control to Rule Them All - Coupled Congestion Control = for RTP Media";
S. Islam, M. = Welzl, and S. Gjessing
http://safiquli.at.ifi.uio.no/paper/pv2013-fse-poster-final.= pdf

Cheers,
Safiqul


On 20. okt. = 2013, at 09:19, Varun Singh <vsingh.ietf@gmail.com> = wrote:

Hi = all,

Following is = the list of papers that have recently been = published
about RMCAT = proposals. I do not have pointers to all the papers, = but
if you know of any other = evaluations or have links to the papers
listed below.

Experimental = Investigation of the Google Congestion Control = for
Real-Time Flows, L. De = Cicco, G. Carlucci, and S. Mascolo:
http://c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf

Performance Analysis of Receive-Side Real-Time Congestion = Control for
WebRTC; Singh V., = Lozano A.A., Ott J.,
http://www.netlab.tkk.fi/~varun/singh2013rrtcc.pdf

Understanding the Dynamic Behaviour of the Google = Congestion Control,
L. De = Cicco, G. Carlucci, and S. Mascolo

NADA: A Unified = Congestion Control Scheme for Low-Latency = Interactive
Video, Xiaoqing = Zhu, Rong Pan

DFlow: Low = latency congestion control: Piers O'Hanlon; Kenneth = Carlberg


Cheers,
Varun
--
http://www.netlab.tkk.fi/~varun/





-- =
http://www.netlab.tkk.fi/~varun/

= --Apple-Mail=_130D5E11-DD80-4B1F-9464-3FA169DE89F1-- From michawe@ifi.uio.no Mon Oct 21 03:26:10 2013 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 9209911E8382 for ; Mon, 21 Oct 2013 03:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDPZjyrDZRh5 for ; Mon, 21 Oct 2013 03:26:04 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 7D40511E818C for ; Mon, 21 Oct 2013 03:25:56 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VYCgN-0002GA-4D; Mon, 21 Oct 2013 12:25:55 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VYCgM-0004n7-GX; Mon, 21 Oct 2013 12:25:55 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_05CA4BC2-D1E1-45E6-ABDB-B78487E306C9" From: Michael Welzl In-Reply-To: <7705ACD8-5AE1-4102-8B23-D2704A2A2A2C@ifi.uio.no> Date: Mon, 21 Oct 2013 12:25:54 +0200 Message-Id: <9D3009B5-4604-43C9-8334-7DD69149F33A@ifi.uio.no> References: <12F6450E-BE8A-4472-97BA-5DAB196EB6E9@ifi.uio.no> <7705ACD8-5AE1-4102-8B23-D2704A2A2A2C@ifi.uio.no> To: Varun Singh X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 8834 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E55B5FC8BC701FB27D617C10F59B8C00ECA7F02E X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 3471 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] Recent papers evaluating RMCAT proposals X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 10:26:10 -0000 --Apple-Mail=_05CA4BC2-D1E1-45E6-ABDB-B78487E306C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, I wasn't aware that the IETF Wiki is open for everyone to edit. Now that = I know that, I moved this page here: http://trac.tools.ietf.org/wg/rmcat/trac/wiki/Bibliography Cheers, Michael On 21. okt. 2013, at 10:08, Michael Welzl wrote: > Hi all, >=20 > I created this page now: > http://www.openwiki.com/ow.asp?rmcat_bib >=20 > Do with it whatever you wish - I thought it's useful to have such a = collection somewhere and it took < 5 minutes to create, that's why I did = it. > openwiki has a rather messy look to it, but it's the only page of its = kind that I know... (zero security, everyone can edit) > moving this to a somewhat "cleaner" page wouldn't hurt I guess.=20 >=20 >=20 > On 20. okt. 2013, at 17:59, Varun Singh wrote: >=20 >> Hi all, >>=20 >> As a side note, some of the papers will be presented at the Packet >> Video Workshop >> on the 12-13 December in San Jose. If you are interested in these >> papers or multimedia >> streaming/communication, consider attending the conference. Details >> at: http://pv2013.itec.aau.at/ >> and list of accepted papers at: >> http://pv2013.itec.aau.at/list-of-accepted-papers/ >>=20 >> Also, chapter 6 of a master thesis titled: Performance analysis of >> topologies for Web-based Real-Time Communication (WebRTC) >> maybe of interest to some of you (it is a slightly different version >> from our paper accepted at PV2013). >> = https://aaltodoc.aalto.fi/bitstream/handle/123456789/11093/master_Abell%C3= %B3_Lozano_Albert_2013.pdf?sequence=3D1 >>=20 >> Cheers, >> Varun >>=20 >> On Sun, Oct 20, 2013 at 9:55 AM, Safiqul Islam = wrote: >>> Hi all, >>>=20 >>> In addition, the following poster has also been accepted : >>>=20 >>> "One Control to Rule Them All - Coupled Congestion Control for RTP = Media"; >>> S. Islam, M. Welzl, and S. Gjessing >>> http://safiquli.at.ifi.uio.no/paper/pv2013-fse-poster-final.pdf >>>=20 >>> Cheers, >>> Safiqul >>>=20 >>>=20 >>> On 20. okt. 2013, at 09:19, Varun Singh = wrote: >>>=20 >>> Hi all, >>>=20 >>> Following is the list of papers that have recently been published >>> about RMCAT proposals. I do not have pointers to all the papers, but >>> if you know of any other evaluations or have links to the papers >>> listed below. >>>=20 >>> Experimental Investigation of the Google Congestion Control for >>> Real-Time Flows, L. De Cicco, G. Carlucci, and S. Mascolo: >>> http://c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf >>>=20 >>> Performance Analysis of Receive-Side Real-Time Congestion Control = for >>> WebRTC; Singh V., Lozano A.A., Ott J., >>> http://www.netlab.tkk.fi/~varun/singh2013rrtcc.pdf >>>=20 >>> Understanding the Dynamic Behaviour of the Google Congestion = Control, >>> L. De Cicco, G. Carlucci, and S. Mascolo >>>=20 >>> NADA: A Unified Congestion Control Scheme for Low-Latency = Interactive >>> Video, Xiaoqing Zhu, Rong Pan >>>=20 >>> DFlow: Low latency congestion control: Piers O'Hanlon; Kenneth = Carlberg >>>=20 >>>=20 >>> Cheers, >>> Varun >>> -- >>> http://www.netlab.tkk.fi/~varun/ >>>=20 >>>=20 >>=20 >>=20 >>=20 >> --=20 >> http://www.netlab.tkk.fi/~varun/ >=20 --Apple-Mail=_05CA4BC2-D1E1-45E6-ABDB-B78487E306C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 http:/= /trac.tools.ietf.org/wg/rmcat/trac/wiki/Bibliography

Cheers,
Michael


O= n 21. okt. 2013, at 10:08, Michael Welzl wrote:

Hi all,

I = created this page now:

Do with it whatever you = wish - I thought it's useful to have such a collection somewhere and it = took < 5 minutes to create, that's why I did it.
openwiki = has a rather messy look to it, but it's the only page of its kind = that I know... (zero security, everyone can edit)
moving this = to a somewhat "cleaner" page wouldn't hurt I = guess. 


On 20. okt. 2013, at = 17:59, Varun Singh wrote:

Hi = all,

As a side note, some of the papers will be presented at the = Packet
Video Workshop
on the 12-13 December in San Jose. If you = are interested in these
papers or = multimedia
streaming/communication, consider attending the = conference. Details
at: http://pv2013.itec.aau.at/
and = list of accepted papers at:
http://pv2013.= itec.aau.at/list-of-accepted-papers/

Also, chapter 6 of a = master thesis titled: Performance analysis of
topologies for = Web-based Real-Time Communication (WebRTC)
maybe of interest to some = of you (it is a slightly different version
from our paper accepted at = PV2013).
https://aaltodoc.aalto.fi= /bitstream/handle/123456789/11093/master_Abell%C3%B3_Lozano_Albert_2013.pd= f?sequence=3D1

Cheers,
Varun

On Sun, Oct 20, 2013 = at 9:55 AM, Safiqul Islam <safiquli@ifi.uio.no> = wrote:
Hi all,

In addition, = the following poster has also been accepted = :

"One Control to Rule Them All - Coupled Congestion Control = for RTP Media";
S. Islam, M. = Welzl, and S. Gjessing
http://safiquli.at.ifi.uio.no/paper/pv2013-fse-poster-final.= pdf

Cheers,
Safiqul


On 20. okt. = 2013, at 09:19, Varun Singh <vsingh.ietf@gmail.com> = wrote:

Hi = all,

Following is = the list of papers that have recently been = published
about RMCAT = proposals. I do not have pointers to all the papers, = but
if you know of any other = evaluations or have links to the papers
listed below.

Experimental = Investigation of the Google Congestion Control = for
Real-Time Flows, L. De = Cicco, G. Carlucci, and S. Mascolo:
http://c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf

Performance Analysis of Receive-Side Real-Time Congestion = Control for
WebRTC; Singh V., = Lozano A.A., Ott J.,
http://www.netlab.tkk.fi/~varun/singh2013rrtcc.pdf

Understanding the Dynamic Behaviour of the Google = Congestion Control,
L. De = Cicco, G. Carlucci, and S. Mascolo

NADA: A Unified = Congestion Control Scheme for Low-Latency = Interactive
Video, Xiaoqing = Zhu, Rong Pan

DFlow: Low = latency congestion control: Piers O'Hanlon; Kenneth = Carlberg


Cheers,
Varun
--
http://www.netlab.tkk.fi/~varun/





-- =
http://www.netlab.tkk.fi/~varun/


= --Apple-Mail=_05CA4BC2-D1E1-45E6-ABDB-B78487E306C9-- From Emmanuel.LOCHIN@isae.fr Mon Oct 21 03:40:56 2013 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 D6C6011E818C for ; Mon, 21 Oct 2013 03:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu0tbP5iV145 for ; Mon, 21 Oct 2013 03:40:51 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6E14611E814D for ; Mon, 21 Oct 2013 03:39:47 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with ESMTP id 975B422E4B7 for ; Mon, 21 Oct 2013 12:39:40 +0200 (CEST) Received: from [10.33.1.1] (pc-lochin.isae.fr [10.33.1.1]) by catalpa (Postfix) with ESMTP id 5C444B7D5E; Mon, 21 Oct 2013 12:39:45 +0200 (CEST) Message-ID: <526504C4.60908@isae.fr> Date: Mon, 21 Oct 2013 12:41:08 +0200 From: Emmanuel Lochin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <2322-52622a80-5b-21cb4240@161088665> <9781A74D-1E09-4462-9A08-19BF1D99B4E4@ifi.uio.no> <20131020235658.GA14037@cisco.com> <6D8E353D-1D42-4E8A-ADEE-9A4A73F05A83@ifi.uio.no> In-Reply-To: <6D8E353D-1D42-4E8A-ADEE-9A4A73F05A83@ifi.uio.no> Content-Type: multipart/alternative; boundary="------------040409070508020009000408" Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 10:40:56 -0000 This is a multi-part message in MIME format. --------------040409070508020009000408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 21/10/2013 09:12, Michael Welzl wrote: > On 21. okt. 2013, at 01:56, Toerless Eckert wrote: > >> Michael, >> >> I really think it's hard to see how to build this mechanism efficiently >> into HW. Even in general purpose CPU/memory it seems to be quite >> expensive. > > 1) you said yourself that you target edge equipment. I think we can be > a bit more relaxed about such constraints there... > 2) So what about CHOKe? Was that not implementable? CHOKe, upon > arrival of a packet, picked a random packet from the queue and dropped > both if they were from the same sender. This way it punished > aggressive senders. A variation of Mirja's suggestion could be a > simple extension to CHOKe: if the rule I just described says "yes, > drop!", then you only drop the packet with the higher drop precedence, > not both. Hi Michael, As far I understand and to follow Mirja proposal, this could be based on my algorithm which in this case, would drop a low priority packet if it belongs to another flow inside the queue. I've proposed to Mirja to look at the way to implement this starting from my own code. Emmanuel > > Someone could argue that dropping both is a key requirement of CHOKe, > but then my rule would make it less aggressive at dropping? So > consider gCHOKe, a scheme investigated by Addisu Eshete in his Ph.D. > thesis: http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:583155 > a related paper: > http://www.sciencedirect.com/science/article/pii/S138912861200326X > gCHOKe applies the CHOKe rule not once, but up to N times ("up to" > because it also stops if the check on a similar packet fails) in a > row, thereby dropping multiple packets from the queue in one go. As a > variation of gCHOKe that incorporates drop precedence, one could apply > "only drop the higher drop precedence packet" from iteration M onward or something. > > Just an example. > > >> Given how we want low-latency, i think it is unlikley and undesirable >> that a single flow would have to have another low-priority frame in the >> queue if it has a high-priority frame that randomnly got elected to >> be dropped. > > Well yes, the scheme would operate only quite rarely, given that the > queues are supposed to be small anyway. This would potentially limit > its benefits - by how much would have to be investigated (I think this > is one of the issues Toerless mentioned early on in this > conversation). Then again, I can't see how you can guarantee to a flow > that setting higher drop precedence for some of its packets wouldn't > give the flow a worse overall treatment than other flows in the > network - and so there is no incentive to use higher drop precedence > marking in applications, as today. > > Cheers, > Michael > > > >> >> On Sun, Oct 20, 2013 at 10:06:34PM +0200, Michael Welzl wrote: >>> I think it would be extremely important to avoid such unfairness >>> (giving the right incentives is the whole point!), and it should >>> also be quite easy, by simply requiring: *only* drop a packet from a >>> flow if you would have dropped a packet from that flow anyway, based >>> on the "regular" AQM rules => *only* change *which* of the packets >>> from that flow are dropped, i.e. if there's a higher drop precedence >>> packet, drop this one instead of a lower drop precedence one. >>> >>> ...or am I completely off track?? >>> >>> Cheers, >>> Michael >>> >>> >>> >>> >>>> If I have a bit of time, I'll send you some simulation results >>>> based on your proposal to check this intuition. >>>> >>>> Emmanuel >>>> >>>>> Hi Emmanuel, >>>>> >>>>>>>> If this is a problem, the only solution is, I think, to implement a >>>>>>>> pushout mechanism that drops marked packets when the queue is full. >>>>>>> >>>>>>> Yes, maybe. But how do you determine eligible packets? >>>>>>> Starting from the front of the queue, considering makred packets of >>>>>>> all flows, of only your own microflow or by using some randomized >>>>>>> selection scheme? >>>>>> >>>>>> Considering a simple Push-Out implementation, as soon as the queue is >>>>>> full and you get an incoming non-marked packet, you have to drop one >>>>>> marked packet previously enqueued. >>>>>> Might be the last one or the first one enqueued. This has to be >>>>>> evaluated. >>>>> >>>>> If you do this, there is a disincentive to mark packets (as 'drop >>>>> precedence') >>>>> as this will treat you worse than flows that don't mark at all or >>>>> at least >>>>> less. >>>>> >>>>> That's why I proposed to look for a marked packet of the same flow >>>>> only. If >>>>> there is no marked packet of the same flow in the queue, you drop the >>>>> original packets. Because than this flow presumably does not have >>>>> any packets >>>>> that are important to not get dropped or the flow did just ignore the >>>>> possibility of marking but than it's its own fault. >>>>> >>>>> Mirja >>>> >>>> >>>> >>>> >>>> >>> >> >> -- >> --- >> Toerless Eckert, eckert@cisco.com >> Cisco NSSTG Systems & Technology Architecture >> SDN: Let me play with the network, mommy! >> > -- Emmanuel Lochin Professeur ISAE - OSSI Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" --------------040409070508020009000408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 21/10/2013 09:12, Michael Welzl wrote:
On 21. okt. 2013, at 01:56, Toerless Eckert wrote:

Michael,

I really think it's hard to see how to build this mechanism efficiently
into HW. Even in general purpose CPU/memory it seems to be quite expensive.

1) you said yourself that you target edge equipment. I think we can be a bit more relaxed about such constraints there...
2) So what about CHOKe? Was that not implementable? CHOKe, upon arrival of a packet, picked a random packet from the queue and dropped both if they were from the same sender. This way it punished aggressive senders. A variation of Mirja's suggestion could be a simple extension to CHOKe: if the rule I just described says "yes, drop!", then you only drop the packet with the higher drop precedence, not both.

Hi Michael,

As far I understand and to follow Mirja proposal, this could be based on my algorithm which in this case, would drop a low priority packet if it belongs to another flow inside the queue.
I've proposed to Mirja to look at the way to implement this starting from my own code.

Emmanuel


Someone could argue that dropping both is a key requirement of CHOKe, but then my rule would make it less aggressive at dropping? So consider gCHOKe, a scheme investigated by Addisu Eshete in his Ph.D. thesis:  http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:583155
gCHOKe applies the CHOKe rule not once, but up to N times ("up to" because it also stops if the check on a similar packet fails) in a row, thereby dropping multiple packets from the queue in one go. As a variation of gCHOKe that incorporates drop precedence, one could apply "only drop the higher drop precedence packet" from iteration M<N onward or something.

Just an example.


Given how we want low-latency, i think it is unlikley and undesirable
that a single flow would have to have another low-priority frame in the
queue if it has a high-priority frame that randomnly got elected to be dropped.

Well yes, the scheme would operate only quite rarely, given that the queues are supposed to be small anyway. This would potentially limit its benefits - by how much would have to be investigated (I think this is one of the issues Toerless mentioned early on in this conversation). Then again, I can't see how you can guarantee to a flow that setting higher drop precedence for some of its packets wouldn't give the flow a worse overall treatment than other flows in the network - and so there is no incentive to use higher drop precedence marking in applications, as today.

Cheers,
Michael




On Sun, Oct 20, 2013 at 10:06:34PM +0200, Michael Welzl wrote:
I think it would be extremely important to avoid such unfairness (giving the right incentives is the whole point!), and it should also be quite easy, by simply requiring: *only* drop a packet from a flow if you would have dropped a packet from that flow anyway, based on the "regular" AQM rules => *only* change *which* of the packets from that flow are dropped, i.e. if there's a higher drop precedence packet, drop this one instead of a lower drop precedence one.

...or am I completely off track??

Cheers,
Michael




If I have a bit of time, I'll send you some simulation results based on your proposal to check this intuition.

Emmanuel

Hi Emmanuel,

If this is a problem, the only solution is, I think, to implement a
pushout mechanism that drops marked packets when the queue is full.

Yes, maybe. But how do you determine eligible packets?
Starting from the front of the queue, considering makred packets of
all flows, of only your own microflow or by using some randomized
selection scheme?

Considering a simple Push-Out implementation, as soon as the queue is
full and you get an incoming non-marked packet, you have to drop one
marked packet previously enqueued.
Might be the last one or the first one enqueued. This has to be evaluated.

If you do this, there is a disincentive to mark packets (as 'drop precedence')
as this will treat you worse than flows that don't mark at all or at least
less.

That's why I proposed to look for a marked packet of the same flow only. If
there is no marked packet of the same flow in the queue, you drop the
original packets. Because than this flow presumably does not have any packets
that are important to not get dropped or the flow did just ignore the
possibility of marking but than it's its own fault.

Mirja







--
---
Toerless Eckert, eckert@cisco.com
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!




-- 
Emmanuel Lochin
Professeur ISAE - OSSI
Institut Supérieur de l'Aéronautique et de l'Espace (ISAE)
Issu du rapprochement SUPAERO et ENSICA
10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4
Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88
Web : http://personnel.isae.fr/emmanuel-lochin/
---
"This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed"
--------------040409070508020009000408-- From mramalho@cisco.com Mon Oct 21 07:18:16 2013 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 7D07111E8587 for ; Mon, 21 Oct 2013 07:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15SdApfZwPcx for ; Mon, 21 Oct 2013 07:18:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E5FC921E8056 for ; Mon, 21 Oct 2013 07:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3076; q=dns/txt; s=iport; t=1382365076; x=1383574676; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Bb+iyqfK0DMcQ4xjxQ7KdJLQuPuRZ5NPJPYoghiTazo=; b=igSAXCgzxIvtrbFqluCz35JpPVABIdx5tZr24W08o8d/s/rAmPVPAlzJ cTfnJ/c4SMl+w31kbWMHmf8R6vGbuLCt/1SmbtGk2+kauu5LqQzPndo31 sdHHS0OWStMis4v7YgYOwJJAxnah2SeZwckmoWKiGy2/kJo/QRZA6z+zh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFADE3ZVKtJV2Z/2dsb2JhbABZFoJxOFS+L4ErFnSCJQEBAQRJIwoDDAQCAQgOAwQBAQEKCxIHMhQJCAIEAQ0FCId+ugSOEwqBDjABBwYEgxWBCgOJB5tVhTSDJIFoCRci X-IronPort-AV: E=Sophos;i="4.93,539,1378857600"; d="scan'208";a="274602721" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 21 Oct 2013 14:17:45 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9LEHjYu019791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 14:17:45 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.29]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 09:17:45 -0500 From: "Michael Ramalho (mramalho)" To: Varun Singh , Mirja Kuehlewind Thread-Topic: [rmcat] application/traffic model Thread-Index: AQHOzBCO6m6oPKWYuE+7MX42UjtiIJn7gkcAgACpVICAAe8ogIABHabw Date: Mon, 21 Oct 2013 14:17:44 +0000 Message-ID: References: <201310181644.19038.mirja.kuehlewind@ikr.uni-stuttgart.de> <201310191242.51095.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.125.236] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] application/traffic model X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 14:18:16 -0000 +1 to both as well. Michael Ramalho -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of V= arun Singh Sent: Sunday, October 20, 2013 11:15 AM To: Mirja Kuehlewind Cc: ; Xiaoqing Zhu (xiaoqzhu) Subject: Re: [rmcat] application/traffic model +1, evaluations that do not use video sequences would definitely gain from having a consistent media stream traffic generator. +1 also for a meeting on Sunday to discuss the traffic generator and input from application designers. Cheers, Varun On Sat, Oct 19, 2013 at 5:42 AM, Mirja Kuehlewind wrote: > Hi Xiaoqing, > > it would be definitely good to have this documented in a way that=20 > others can easily access and use your model. I guess a draft is the=20 > easiest way to do this. Can't tell you yet what we will do with this=20 > draft in the working group. But please go ahead an write it. > > Mirja > > > On Saturday 19 October 2013 02:36:48 Xiaoqing Zhu (xiaoqzhu) wrote: >> I will be happy to contribute to this one and describe the video=20 >> source model we used for NADA. >> >> You want this to be a draft? >> >> Best, >> Xiaoqing >> >> On Oct 18, 2013, at 9:44 AM, Mirja K=FChlewind > wrote: >> > Hi group, >> > >> > looking at the current status and proposed scenarios regarding the=20 >> > evaluation criteria, and taking previous comments on the mic into=20 >> > account, I believe one crucial thing we need to proceed is some=20 >> > kind of application/traffic model. >> > >> > Obviously assuming greedy sources is not enough for the evaluation=20 >> > of media traffic scenarios. Under the assumption that there will be=20 >> > an interface between transport congestion control and the=20 >> > application (see milestone app-interactions), a simple traffic that=20 >> > is from time to time application-limited might also not be enough.=20 >> > And using a real set of examples videos in simulation is propably quit= e hard. >> > >> > I believe we could actually need more input from the application=20 >> > designers itself meaning the people that are (also) involved in rtcweb= . >> > If considered useful, we can try to book a room on Sunday to=20 >> > discuss this topic and also announce this to rtcweb...? >> > >> > Any interested? >> > >> > Otherwise let us know if you, and especially the design team, need=20 >> > a room to further discuss the evaluation criteria anyway! >> > >> > Mirja > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR)=20 > University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- -- http://www.netlab.tkk.fi/~varun/ From harald@alvestrand.no Mon Oct 21 08:54:11 2013 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 C892A11E85B0 for ; Mon, 21 Oct 2013 08:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xndx4WqMeRfG for ; Mon, 21 Oct 2013 08:54:05 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 28E3D11E863D for ; Mon, 21 Oct 2013 08:53:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC70239E095 for ; Mon, 21 Oct 2013 17:53:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pka3PfuE+MVP for ; Mon, 21 Oct 2013 17:53:27 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 162AA39E070 for ; Mon, 21 Oct 2013 17:53:27 +0200 (CEST) Message-ID: <52654DFB.8070800@alvestrand.no> Date: Mon, 21 Oct 2013 17:53:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <20131021154723.29508.49957.idtracker@ietfa.amsl.com> In-Reply-To: <20131021154723.29508.49957.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131021154723.29508.49957.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010505080309050506090206" Subject: [rmcat] Fwd: New Version Notification for draft-alvestrand-rmcat-remb-03.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 15:54:11 -0000 This is a multi-part message in MIME format. --------------010505080309050506090206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Lots of reasons why you haven't heard much from us lately, but I've updated the draft about a format for congestion control information, and also added to it the info on a timestamp option it turned out we needed. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rmcat-remb-03.txt Date: Mon, 21 Oct 2013 08:47:23 -0700 From: internet-drafts@ietf.org To: Harald T. Alvestrand , Harald Alvestrand A new version of I-D, draft-alvestrand-rmcat-remb-03.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rmcat-remb Revision: 03 Title: RTCP message for Receiver Estimated Maximum Bitrate Creation date: 2013-10-21 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-rmcat-remb-03.txt Status: http://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb Htmlized: http://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-alvestrand-rmcat-remb-03 Abstract: This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. It also describes an absolute-value timestamp option for use in bandwidth estimatoin. 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. The IETF Secretariat --------------010505080309050506090206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Lots of reasons why you haven't heard much from us lately, but I've updated the draft about a format for congestion control information, and also added to it the info on a timestamp option it turned out we needed.

               Harald



-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rmcat-remb-03.txt
Date: Mon, 21 Oct 2013 08:47:23 -0700
From: internet-drafts@ietf.org
To: Harald T. Alvestrand <harald@alvestrand.no>, Harald Alvestrand <harald@alvestrand.no> 


A new version of I-D, draft-alvestrand-rmcat-remb-03.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-alvestrand-rmcat-remb
Revision:	 03
Title:		 RTCP message for Receiver Estimated Maximum Bitrate
Creation date:	 2013-10-21
Group:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-rmcat-remb-03.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-alvestrand-rmcat-remb-03

Abstract:
   This document proposes an RTCP message for use in experimentally-
   deployed congestion control algorithms for RTP-based media flows.

   It also describes an absolute-value timestamp option for use in
   bandwidth estimatoin.


                                                                                  


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.

The IETF Secretariat


--------------010505080309050506090206-- From eckert@cisco.com Mon Oct 21 09:17:48 2013 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 B8A2711E822B for ; Mon, 21 Oct 2013 09:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.281 X-Spam-Level: X-Spam-Status: No, score=-10.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoKNg3ZZ4c7E for ; Mon, 21 Oct 2013 09:17:43 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA1A11E8145 for ; Mon, 21 Oct 2013 09:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5557; q=dns/txt; s=iport; t=1382372263; x=1383581863; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=NKr1wqO9WRG5NumB9p6AfIxI58RG8AI5G/1fn4F/yv4=; b=Weq8mhtez/MtAg7qGBLLKD1vbtgaMT/FASlTUpb0fviohYueT5O7P25V pX8NsEHKeE3aHWWbsaE/oPsVTLitCqwTu2JVJJLCIjX0vm7jYLNwQsOK/ eVSJHxYIGX7yGCPkiPzC8xgxY3iwHo5FdZXeFNTDaSeGzT3sIy/F7hC8P A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAFFTZVKrRDoJ/2dsb2JhbABZgwe/O4EuFnSCJQEBAQMBOj8FCwsOCgklDwVJLodlBboCjh6BPgeDH4EKA4k/jkkBkgeDRByBLQ X-IronPort-AV: E=Sophos;i="4.93,539,1378857600"; d="scan'208";a="95212380" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 21 Oct 2013 16:17:42 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9LGHen1001610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 16:17:41 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9LGHdcs007696; Mon, 21 Oct 2013 09:17:39 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9LGHcab007694; Mon, 21 Oct 2013 09:17:38 -0700 Date: Mon, 21 Oct 2013 09:17:38 -0700 From: Toerless Eckert To: Michael Welzl Message-ID: <20131021161738.GC14037@cisco.com> References: <2322-52622a80-5b-21cb4240@161088665> <9781A74D-1E09-4462-9A08-19BF1D99B4E4@ifi.uio.no> <20131020235658.GA14037@cisco.com> <6D8E353D-1D42-4E8A-ADEE-9A4A73F05A83@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D8E353D-1D42-4E8A-ADEE-9A4A73F05A83@ifi.uio.no> User-Agent: Mutt/1.4.2.2i Cc: rmcat@ietf.org, "Bless, Roland \(TM\)" , LOCHIN Emmanuel Subject: Re: [rmcat] About the importance of packets in a single data stream X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 16:17:49 -0000 On Mon, Oct 21, 2013 at 09:12:56AM +0200, Michael Welzl wrote: > On 21. okt. 2013, at 01:56, Toerless Eckert wrote: > > > Michael, > > > > I really think it's hard to see how to build this mechanism efficiently > > into HW. Even in general purpose CPU/memory it seems to be quite expensive. > > 1) you said yourself that you target edge equipment. I think we can be a bit more relaxed about such constraints there... Sure. But i'd still like to find the most easily implementable solution. Also: There is important edge equipment thats not generl purpose CPU. For example MetroE edge equipment (both PE/CE) is often all ASIC based. > 2) So what about CHOKe? ... No final opinions on any of the new innovative AQM methods. I am certainly a fan of getting as much flow awareness into solutions as feasible, but thats just a personal preference. Pragmatically speaking, i think AQM-WG will have to vet and decide on AQM methods, and i would like to track that and see how priority-dropping can be done via eiter parameterizing or enhancing those AQM methods - and not adding unreasonalbe implementation complexity in the process. And (W)RED seems to be the only really currently widely availabl AQM method and it also serves as a reference for better AQM methods, so from that perspective it seems most appropriate to have a WRED based priority-dropping reference. > > Given how we want low-latency, i think it is unlikley and undesirable > > that a single flow would have to have another low-priority frame in the > > queue if it has a high-priority frame that randomnly got elected to be dropped. > > Well yes, the scheme would operate only quite rarely, given that the queues are supposed to be small anyway. This would potentially limit its benefits - by how much would have to be investigated (I think this is one of the issues Toerless mentioned early on in this conversation). Then again, I can't see how you can guarantee to a flow that setting higher drop precedence for some of its packets wouldn't give the flow a worse overall treatment than other flows in the network - and so there is no incentive to use higher drop precedence marking in applications, as today. As i said in other emails. Lets think of the most stripped down priority scheme: There is a standard definition to mark flows with 20% high-prio, 60% normal, 20% low-prio packets (long term average) - or not to mark at all. Whatever the marking is going to be. Edge-equipment that today authenticates and permit existing markings (like DSCP) would equally have to authenticate this new priority-marking. Hoever that authentication is done. Could just be trust for specific senders or could be a policer. So, that leaves authenticated 20/60/20 or unmarked flows, and those IMHO could essily be made to fairly co-exist in a single queue with an appropriate WRED profile or hopefully in the future better AQM that is parameterized/enhanced to do priority-dropping.. And IMHO, the real cool goal would be that all flows with priority markings would experience only low-priority packet loss under all rasonable situations. And that not only helps video quality under congestion, it also permits a simple improvement to the rate adaptation to hopefully become better than what's possible without low-prio dropping. Cheers Toerless > > > > > On Sun, Oct 20, 2013 at 10:06:34PM +0200, Michael Welzl wrote: > >> I think it would be extremely important to avoid such unfairness (giving the right incentives is the whole point!), and it should also be quite easy, by simply requiring: *only* drop a packet from a flow if you would have dropped a packet from that flow anyway, based on the "regular" AQM rules => *only* change *which* of the packets from that flow are dropped, i.e. if there's a higher drop precedence packet, drop this one instead of a lower drop precedence one. > >> > >> ...or am I completely off track?? > >> > >> Cheers, > >> Michael > >> > >> > >> > >> > >>> If I have a bit of time, I'll send you some simulation results based on your proposal to check this intuition. > >>> > >>> Emmanuel > >>> > >>>> Hi Emmanuel, > >>>> > >>>>>>> If this is a problem, the only solution is, I think, to implement a > >>>>>>> pushout mechanism that drops marked packets when the queue is full. > >>>>>> > >>>>>> Yes, maybe. But how do you determine eligible packets? > >>>>>> Starting from the front of the queue, considering makred packets of > >>>>>> all flows, of only your own microflow or by using some randomized > >>>>>> selection scheme? > >>>>> > >>>>> Considering a simple Push-Out implementation, as soon as the queue is > >>>>> full and you get an incoming non-marked packet, you have to drop one > >>>>> marked packet previously enqueued. > >>>>> Might be the last one or the first one enqueued. This has to be evaluated. > >>>> > >>>> If you do this, there is a disincentive to mark packets (as 'drop precedence') > >>>> as this will treat you worse than flows that don't mark at all or at least > >>>> less. > >>>> > >>>> That's why I proposed to look for a marked packet of the same flow only. If > >>>> there is no marked packet of the same flow in the queue, you drop the > >>>> original packets. Because than this flow presumably does not have any packets > >>>> that are important to not get dropped or the flow did just ignore the > >>>> possibility of marking but than it's its own fault. > >>>> > >>>> Mirja > >>> > >>> From p.ohanlon@gmail.com Wed Oct 23 07:19:58 2013 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 E217E11E8388 for ; Wed, 23 Oct 2013 07:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAgRfXsr5sYo for ; Wed, 23 Oct 2013 07:19:58 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1F04511E81B2 for ; Wed, 23 Oct 2013 07:19:57 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ey11so7435079wid.6 for ; Wed, 23 Oct 2013 07:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lEdXEF4RKjHZ0qn1TwMWbaNp70xSmoU6M6WrUQo3UgY=; b=YvhNj8i+WNERHWYZ/F8mmfZzbs2InsmTJa3/AZsSWkVTvMg6VEH7muYEofUKPjqoSu 2nRVOoVSDT9xPPWHp/g7SsR8N1v4vKF05hqepMqJxR4cNXDu9I+dpapHp+xtr82yj2t9 2CltkQhVnaPIiDinoHzNum+tulk/lmwl9cabyiSUfhV9DhflgDiNGdCWkqCuC1LGxTWs 8ncoUMETad2/uScnhh30ZeLgX39Vn6kLdwUVZtUdiC8rtJi9GnTNW0XI/YUtQWNg8ww0 MrlovsiLVAC0LCJMqpOv5QccAg+oyBpR1g6oZB6BGaDELhnYydQ2ft/P/YOTUAseoyxT QgUQ== X-Received: by 10.180.98.105 with SMTP id eh9mr2383723wib.56.1382537997394; Wed, 23 Oct 2013 07:19:57 -0700 (PDT) Received: from black.lan ([149.241.129.101]) by mx.google.com with ESMTPSA id e5sm17335418wiy.2.2013.10.23.07.19.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 07:19:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Piers O'Hanlon In-Reply-To: Date: Wed, 23 Oct 2013 15:19:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <14641FD2-C995-4E3A-BC21-A98781D1DB02@gmail.com> References: <51FAA413.8060403@jesup.org> To: "Xiaoqing Zhu (xiaoqzhu)" , "Rong Pan (ropan)" X-Mailer: Apple Mail (2.1283) Cc: rmcat WG Subject: [rmcat] NADA questions X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 14:19:59 -0000 Hi Xiaoqing and Rong, I was reading over your draft and wanted to check a couple of things = about the draft: 1) Whilst not explicitly laid out in the draft, from your presentation = in RMCAT@IETF86, d_n =3D t_{r,n} - t_{s,n} - which I understood to mean = that it was calculating the absolute one-way delay for each packet - = which would imply that one would need synchronised clocks on the sender = and receiver? Is that correct or was there an additional difference = factor that I missed? 2) On a related issue in Section "6.3 Reference rate calculator" in = equation (2) it seems that the selection of x_ref is dependent upon = knowledge of the absolute one-way delay? 3) Also in section 6.3 - the parameter tau_o says it is the 'reference = RTT' - does this mean it is like the baseRTT which accumulated over some = sort of minima of the RTTs, or another configurable parameter? Thanks, Piers O'Hanlon =20 From xiaoqzhu@cisco.com Wed Oct 23 16:07:16 2013 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 A62CD11E828A for ; Wed, 23 Oct 2013 16:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Dbdh++Jtl4W for ; Wed, 23 Oct 2013 16:07:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2781F11E8224 for ; Wed, 23 Oct 2013 16:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2638; q=dns/txt; s=iport; t=1382569627; x=1383779227; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qMRwocA50qwDUdpn5BgEDHO/k6/EHz8CKdHXI5g9tDM=; b=cjus7pLcV0dgm+FAu/OrKtTHDj2nAV5oRVAWq89DwCm7W4Os3N63UfpY EjAlEZRAwb7OQAkobQ6JQL3F/jAv3sxKgSpR37ukVqCrMCQE/xxk/Iv03 miHYxVuBNqU7jivCw47gb90rsgwP2ulC1/bJ8nqACgL5Yt3beb41sNCtH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAC1WaFKtJXHA/2dsb2JhbABZgmYhgQy+V4ErFnSCJQEBAQMBOj8FCwIBCCIUECERJQIEDgUIh2wDCQYBsU4NiWuMYIEkgRcCMQeDH4ELA5YejjuFN4Mkgio X-IronPort-AV: E=Sophos;i="4.93,557,1378857600"; d="scan'208";a="275895642" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 23 Oct 2013 23:07:06 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9NN76B0014570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 23:07:06 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 18:07:06 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "Piers O'Hanlon" Thread-Topic: [rmcat] NADA questions Thread-Index: AQHOz/r5x9IK43P2gkikJ3I+aBD/nJoDPQmA Date: Wed, 23 Oct 2013 23:07:05 +0000 Message-ID: References: <51FAA413.8060403@jesup.org> <14641FD2-C995-4E3A-BC21-A98781D1DB02@gmail.com> In-Reply-To: <14641FD2-C995-4E3A-BC21-A98781D1DB02@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.12.22] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rong Pan \(ropan\)" , rmcat WG Subject: Re: [rmcat] NADA questions X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 23:07:16 -0000 Hi Piers,=20 Thanks for going through our draft in detail. Please see answers below.=20 Best, Xiaoqing On Oct 23, 2013, at 9:19 AM, Piers O'Hanlon wrote: > Hi Xiaoqing and Rong, >=20 > I was reading over your draft and wanted to check a couple of things abou= t the draft: >=20 > 1) Whilst not explicitly laid out in the draft, from your presentation in= RMCAT@IETF86, d_n =3D t_{r,n} - t_{s,n} - which I understood to mean that = it was calculating the absolute one-way delay for each packet - which would= imply that one would need synchronised clocks on the sender and receiver? = Is that correct or was there an additional difference factor that I missed? >=20 Your understanding is correct. For now, we are using one-way delay as the = baseline for congestion signal. We are aware of all the drawbacks and limit= ations associated with one-way delay measurements, and are planning to addr= ess those issues once we start playing around with a testbed setup. One ten= tative plan is to subtract out a minimum OWD and work with relative OWD ins= tead, another option is to move the per-packet statistical handling to the = sender instead, and use RTT in lieu of OWD. Yet another measure could be t= o employ a separate mechanism for clock synchronization between sender and = receiver. We are, of course, also open to suggestions on that matter.=20 > 2) On a related issue in Section "6.3 Reference rate calculator" in equat= ion (2) it seems that the selection of x_ref is dependent upon knowledge of= the absolute one-way delay? The rationale of choose x_ref to be the value of absolute one-way delay (ba= sically, propagation delay along the path) is that ideally, we would want t= he video stream to reach the highest possible rate when the queue stays is = empty, e.g., when bottleneck link rate exceeds r_max of video. In practice,= the stream can simply set x_ref as the minimum OWD it has observed so far.= =20 >=20 > 3) Also in section 6.3 - the parameter tau_o says it is the 'reference RT= T' - does this mean it is like the baseRTT which accumulated over some sort= of minima of the RTTs, or another configurable parameter? >=20 The parameter tau_o is a fixed value but configurable. The purpose of the p= rediction is to compensate for the effect of the time delay in the feedback= control loop. That's why its value should be comparable to the RTT of the = flow, but does not need to match exactly. Throughout all our simulations, w= e used a fixed value of tau_o =3D 200ms. =20 > Thanks, >=20 > Piers O'Hanlon =20 >=20 From p.ohanlon@gmail.com Thu Oct 24 09:43:05 2013 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 5522611E8327 for ; Thu, 24 Oct 2013 09:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeYip-ZGe3vH for ; Thu, 24 Oct 2013 09:43:01 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4E83511E8365 for ; Thu, 24 Oct 2013 09:42:48 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id q58so2652421wes.28 for ; Thu, 24 Oct 2013 09:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oPtTijb866BlS76MyGIMtk6hS77nNrtBn9Qf3Rf/h+A=; b=xyiA6noSC2Z1lALqpB3oLQSKnZQObHgIPMn/a77WXod3jhzJ/dIa3spx2D+vshxCxX uPrc1mJsMb3zUiKj+oVTTdHDKenTd3wqdMXiHpbBqkSZFu1igm7BtR799hjOsG/PufjJ YRkoOlm1jspb6jGiHLujn8ZTZUw8aGHd7CNtBsEn988Db2fKBe8E+3EM0qhK7AhyP9SR fAvwtzbHRr+Triu4irfW+0xo/sSQGfDSBwUaILfq087nsCiOD0OwhnGKVObNeHJeQRgz usCQzaMBPBFqzP60aCzZaYz2Npx311N0KPIW73spBmGfUFHu17g4hT00TtiaLEUtVuAT /GOQ== X-Received: by 10.180.98.105 with SMTP id eh9mr3045841wib.56.1382632967488; Thu, 24 Oct 2013 09:42:47 -0700 (PDT) Received: from black.lan ([149.241.129.101]) by mx.google.com with ESMTPSA id ev4sm28656570wib.7.2013.10.24.09.42.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Oct 2013 09:42:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Piers O'Hanlon In-Reply-To: Date: Thu, 24 Oct 2013 17:42:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2398BFCD-D4DA-4792-A117-A8D105848702@gmail.com> References: <51FAA413.8060403@jesup.org> <14641FD2-C995-4E3A-BC21-A98781D1DB02@gmail.com> To: "Xiaoqing Zhu (xiaoqzhu)" X-Mailer: Apple Mail (2.1283) Cc: "Rong Pan \(ropan\)" , rmcat WG Subject: Re: [rmcat] NADA questions X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 16:43:05 -0000 Hi Xiaoqing, Thanks for your clarifications - it would be useful to add these to the = next version of the draft. Some comments inline. On 24 Oct 2013, at 00:07, Xiaoqing Zhu (xiaoqzhu) wrote: > Hi Piers,=20 >=20 > Thanks for going through our draft in detail. Please see answers = below.=20 >=20 > Best, > Xiaoqing >=20 >=20 > On Oct 23, 2013, at 9:19 AM, Piers O'Hanlon = wrote: >=20 >> Hi Xiaoqing and Rong, >>=20 >> I was reading over your draft and wanted to check a couple of things = about the draft: >>=20 >> 1) Whilst not explicitly laid out in the draft, from your = presentation in RMCAT@IETF86, d_n =3D t_{r,n} - t_{s,n} - which I = understood to mean that it was calculating the absolute one-way delay = for each packet - which would imply that one would need synchronised = clocks on the sender and receiver? Is that correct or was there an = additional difference factor that I missed? >>=20 >=20 > Your understanding is correct. For now, we are using one-way delay as = the baseline for congestion signal. We are aware of all the drawbacks = and limitations associated with one-way delay measurements, and are = planning to address those issues once we start playing around with a = testbed setup. One tentative plan is to subtract out a minimum OWD and = work with relative OWD instead, another option is to move the per-packet = statistical handling to the sender instead, and use RTT in lieu of OWD. = Yet another measure could be to employ a separate mechanism for clock = synchronization between sender and receiver. We are, of course, also = open to suggestions on that matter.=20 >=20 Ok. Yes it would be nice to have a scheme that doesn't rely on absolute = OWD, though there are some environments where one could expect = synchronised clocks. >> 2) On a related issue in Section "6.3 Reference rate calculator" in = equation (2) it seems that the selection of x_ref is dependent upon = knowledge of the absolute one-way delay? >=20 > The rationale of choose x_ref to be the value of absolute one-way = delay (basically, propagation delay along the path) is that ideally, we = would want the video stream to reach the highest possible rate when the = queue stays is empty, e.g., when bottleneck link rate exceeds r_max of = video. In practice, the stream can simply set x_ref as the minimum OWD = it has observed so far. =20 >=20 ok - though it might also be useful to have some sort of mechanism to = accommodate path changes in the setting of x_ref. >>=20 >> 3) Also in section 6.3 - the parameter tau_o says it is the = 'reference RTT' - does this mean it is like the baseRTT which = accumulated over some sort of minima of the RTTs, or another = configurable parameter? >>=20 >=20 > The parameter tau_o is a fixed value but configurable. The purpose of = the prediction is to compensate for the effect of the time delay in the = feedback control loop. That's why its value should be comparable to the = RTT of the flow, but does not need to match exactly. Throughout all our = simulations, we used a fixed value of tau_o =3D 200ms. =20 >=20 I see - so I guess you could use tau_o =3D 2*x_ref Cheers, Piers. >> Thanks, >>=20 >> Piers O'Hanlon =20 >>=20 >=20 From mirja.kuehlewind@ikr.uni-stuttgart.de Sat Oct 26 12:46:17 2013 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 1CAD111E8176 for ; Sat, 26 Oct 2013 12:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woRtv9iv4OzH for ; Sat, 26 Oct 2013 12:46:12 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2444F21F9E14 for ; Sat, 26 Oct 2013 12:46:10 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4F5D96028D for ; Sat, 26 Oct 2013 21:46:06 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 357D060156 for ; Sat, 26 Oct 2013 21:46:06 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Sat, 26 Oct 2013 21:46:05 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201310181628.11870.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201310181628.11870.mirja.kuehlewind@ikr.uni-stuttgart.de> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310262146.05821.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [rmcat] Agenda uploaded X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 19:46:18 -0000 Hi, I updated the agenda. Please let me know (until Monday) if any further chan= ges=20 are needed! Mirja On Friday 18 October 2013 16:28:11 Mirja K=FChlewind wrote: > Hi working group, > > I've just uploaded the current version of the next meeting's agenda: > > http://www.ietf.org/proceedings/88/agenda/agenda-88-rmcat > > Please let me know, if something needs to be changed or added! > > Mirja =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From vsingh.ietf@gmail.com Sun Oct 27 03:57:35 2013 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 8B66511E8162; Sun, 27 Oct 2013 03:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDG+d24J07X4; Sun, 27 Oct 2013 03:57:34 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCAB11E8144; Sun, 27 Oct 2013 03:57:34 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id u16so9158984iet.4 for ; Sun, 27 Oct 2013 03:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=mymBHQPqvBP7FJmEqZ+rUEcI3Mc1FnVw+ZxkAaruUBg=; b=esd2rUZmHNV84VUnnZXB0b00Yh8JcvzG5PmnUYzm0fo3/Xxz/0l3HVMhuXmN/W54g7 MsRyxGz1HTYfOpEWluRJL8b3+80N6qCmeqpgI1VM2PDvbJYeSxA0VELGvfl5i07Ck77y q2o3F4xD5enTbVkJcApDXV/PEK5poAuHAXAQ87KaIrlC40RRF7N+8qL5yEAWYJZKnDCd WLipNbDQ2Vgyh4AiKiaPv9Y3RgoXWtk9QRbTXXfofUGsRVnHrIiF6+Fg21W1x2fob2Ma DiMJBXqeg48qQ3uDe69MAhWXlHVGMpK0y+9utUUHKFDDVDBE1QEnjJTUpDfoNbzwZnDS kTjA== X-Received: by 10.50.77.72 with SMTP id q8mr4891071igw.14.1382871453857; Sun, 27 Oct 2013 03:57:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sun, 27 Oct 2013 03:57:13 -0700 (PDT) From: Varun Singh Date: Sun, 27 Oct 2013 12:57:13 +0200 Message-ID: To: "rtcweb@ietf.org" , "avt@ietf.org" , rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Cc: "Eggert, Lars" , Mirja Kuehlewind , Colin Perkins Subject: [rmcat] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 10:57:35 -0000 Hi all, In RMCAT WG there has been discussion surrounding the use of a media traffic generator and to facilitate discussion, RMCAT is hosting a side meeting on Sunday, 03 November at 1300-1500. I suppose the room details will be announced shortly. Below is a list of questions that will help design or choose an appropriate traffic generator for Interactive multimedia traffic. The list is an initial set and mainly to foster discussion both on the mailing list and at the meeting. Mirja and Lars are not available that day, hence on their behalf, the meeting is hosted by Colin and I . Cheers, Varun --- Traffic generator: to model the intrinsic variability of video: - what target bit rates can be achieved? (max?, min?) - how much variability in media bit rate for a given target bit rate - how to model motion? capturing high motion leads to bursty video (higher than target bit rate), but by how much? can this even be done? Traffic generator: on responsiveness to a new target bitrate: - how quickly can the codec generate a lower bit rate? - immediately? does this depend on the new or requested bit rate? - what is immediately? is it next frame or a few frames later, until then does it generates at the current rate? - if not immediately, what bitrates (and duration) will it generate before meeting the target bitrate. - how quickly can the codec generate a higher bit rate? - immediately in the next frame? does this also depend on the new or requested bit rate? - not immediately but in steps of intermediate bitrates, i.e., intermediate bitrate for a short duration then an increase in step, repeating until reaching the target bit rate. - If the target bit rate is achieved in steps, can they be announced to the congestion controller, i.e., the congestion controller knows the ramp up curve to meet the target bit rate. - If the media bit rate has not yet reached the requested target bit rate and the congestion control requests a new target bit rate, how does the codec respond? Application design related: - should the congestion control be able to change the frame rate (video) or packetization time (audio) or is this something that the application controls. - should the congestion control be able to change video resolution? - should error-repair: NACKs, FEC be considered part of congestion control or outside it, i.e., it is something that the application does and not congestion control - If FEC is controlled by the congestion control, how quickly can the sending rate be adapted by reducing/adding redundancy (FEC)? is something link this done? Does this makes sense at all? - Apart from loss and RTT, what other congestion cues are currently used by congestion control algorithms? e.g., Decoding rate/goodput, application decode error rate, ECN, PCN, etc. - If the codec is data limited, i.e., producing a sending rate smaller than the one calculated by the congestion control, can the congestion control probe the bandwidth by sending additional data packets in a certain pattern (e.g., PathChirp)? would somehting link this help? - application input on prioritization: audio vs video (vs data) -- http://www.netlab.tkk.fi/~varun/ From michawe@ifi.uio.no Sun Oct 27 04:08:57 2013 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 81CB521F9F99 for ; Sun, 27 Oct 2013 04:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seb3CfTJTeEl for ; Sun, 27 Oct 2013 04:08:52 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 1675011E8144 for ; Sun, 27 Oct 2013 04:08:52 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VaOCq-0000cm-9a; Sun, 27 Oct 2013 12:08:28 +0100 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VaOCp-000421-MA; Sun, 27 Oct 2013 12:08:28 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Sun, 27 Oct 2013 12:08:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> References: To: Varun Singh X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 9019 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 34F0ABF58BA7542410A91F8FD74647EB3A8FFBFB X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 430 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 11:08:57 -0000 [removing the other lists except rmcat] Great initiative, count me in! (sorry for saying this only so late) Re: discussion on the mailing list, here's a question I have, since you = mention "how to model motion". Does a list of standard test sequences = (like these http://media.xiph.org/video/derf/ ) for interactive use = exist? If not, maybe a subset of those could be picked (I'd imagine that = foreman is rather representative for interactive use, but many others = are not :) ). Now, next, what if we'd have a set of such sequences, and then stack = them over a codec that produces quite arbitrary bitrates, assuming that = the network can always follow it - as a sort of extreme case test? Then = we'd have standard test sequences of bit rates that could be used to = check how good a particular cc. is at following along. I'm not saying = that "follow along" is all a controller's supposed to do, indeed a codec = can react to feedback from the network, but couldn't this be a useful = way of separating out at least one side of the story and having = something to test? I also wonder about the related work in this regard... there must be = tons of papers out there on this problem? Cheers, Michael On 27. okt. 2013, at 11:57, Varun Singh wrote: > Hi all, >=20 > In RMCAT WG there has been discussion surrounding the use > of a media traffic generator and to facilitate discussion, > RMCAT is hosting a side meeting on Sunday, 03 November > at 1300-1500. I suppose the room details will be announced > shortly. >=20 > Below is a list of questions that will help design or choose > an appropriate traffic generator for Interactive multimedia traffic. > The list is an initial set and mainly to foster discussion both > on the mailing list and at the meeting. >=20 > Mirja and Lars are not available that day, hence on their behalf, > the meeting is hosted by Colin and I . >=20 > Cheers, > Varun > --- >=20 > Traffic generator: to model the intrinsic variability of video: >=20 > - what target bit rates can be achieved? (max?, min?) > - how much variability in media bit rate for a given target bit rate > - how to model motion? capturing high motion leads to bursty video > (higher than target bit rate), but by how much? can this even be = done? >=20 > Traffic generator: on responsiveness to a new target bitrate: >=20 > - how quickly can the codec generate a lower bit rate? > - immediately? does this depend on the new or requested bit rate? > - what is immediately? is it next frame or a few frames later, until = then > does it generates at the current rate? > - if not immediately, what bitrates (and duration) will it generate = before > meeting the target bitrate. >=20 >=20 > - how quickly can the codec generate a higher bit rate? > - immediately in the next frame? does this also depend on the new > or requested bit rate? > - not immediately but in steps of intermediate bitrates, i.e., = intermediate > bitrate for a short duration then an increase in step, repeating = until > reaching the target bit rate. >=20 > - If the target bit rate is achieved in steps, can they be announced = to the > congestion controller, i.e., the congestion controller knows the ramp = up > curve to meet the target bit rate. >=20 > - If the media bit rate has not yet reached the requested target bit = rate and > the congestion control requests a new target bit rate, how does the = codec > respond? >=20 > Application design related: > - should the congestion control be able to change the frame rate = (video) or > packetization time (audio) or is this something that the application = controls. > - should the congestion control be able to change video resolution? > - should error-repair: NACKs, FEC be considered part of congestion = control or > outside it, i.e., it is something that the application does and not > congestion control > - If FEC is controlled by the congestion control, how quickly can the = sending > rate be adapted by reducing/adding redundancy (FEC)? is something = link this > done? Does this makes sense at all? > - Apart from loss and RTT, what other congestion cues are currently = used by > congestion control algorithms? e.g., Decoding rate/goodput, = application > decode error rate, ECN, PCN, etc. > - If the codec is data limited, i.e., producing a sending rate smaller = than the > one calculated by the congestion control, can the congestion control = probe > the bandwidth by sending additional data packets in a certain pattern = (e.g., > PathChirp)? would somehting link this help? > - application input on prioritization: audio vs video (vs data) >=20 >=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From vsingh.ietf@gmail.com Sun Oct 27 04:25:45 2013 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 2F89621E80B2 for ; Sun, 27 Oct 2013 04:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kcX6ATT+YaQ for ; Sun, 27 Oct 2013 04:25:33 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 34E5B21E80B6 for ; Sun, 27 Oct 2013 04:25:25 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id at1so9682843iec.29 for ; Sun, 27 Oct 2013 04:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Zo7WoOOLzb3dMgMwRLuNS8vji/TQndqfHYAuR6z/6aQ=; b=mGLQKXTvXpryAn3/zp1G84Vu/bbkV+xBu0wWYVwMHid6W3bg2jpDDn01HjH6AsV+Uj 5ZJdaHcqx5agONn/Nr2mFNYVodP0Gt2wj2jwYxCzmTmUkwGJ1+SCXWQM26GK0wQ4nm6+ fs6pscPWNR+eDc0x4Hk32pOHjHIw3mtfTerAKPLJ+FeGEfC64ACYrd3jxO2XcDBqKx6y tIQeJvhdewF9xPsrK0wcZmZKO8ZFbByzHMwjMecoJW2UnNQUm/O2nSLtqxGS/SCyZ0pt 5yeRX+7Bqze3SOzH0KniGFwXuGDhn4aEQfrUb8WyoxEJUtfwW235BiQpr8ZjP/iw5/dy z7ig== X-Received: by 10.42.40.83 with SMTP id k19mr10045248ice.3.1382873124673; Sun, 27 Oct 2013 04:25:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sun, 27 Oct 2013 04:25:04 -0700 (PDT) In-Reply-To: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> From: Varun Singh Date: Sun, 27 Oct 2013 13:25:04 +0200 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 11:25:45 -0000 On Sun, Oct 27, 2013 at 1:08 PM, Michael Welzl wrote: > [removing the other lists except rmcat] > > Great initiative, count me in! (sorry for saying this only so late) > > Re: discussion on the mailing list, here's a question I have, since you m= ention "how to model motion". Does a list of standard test sequences (like = these http://media.xiph.org/video/derf/ ) for interactive use exist? If not= , maybe a subset of those could be picked (I'd imagine that foreman is rath= er representative for interactive use, but many others are not :) ). > There is also the "news" sequence which is quite popular for mimicking heads and shoulders but it has a pirouetting ballerina in the background. > Now, next, what if we'd have a set of such sequences, and then stack them= over a codec that produces quite arbitrary bitrates, assuming that the net= work can always follow it - as a sort of extreme case test? Then we'd have = standard test sequences of bit rates that could be used to check how good a= particular cc. is at following along. I'm not saying that "follow along" i= s all a controller's supposed to do, indeed a codec can react to feedback f= rom the network, but couldn't this be a useful way of separating out at lea= st one side of the story and having something to test? > > I also wonder about the related work in this regard... there must be tons= of papers out there on this problem? > > Cheers, > Michael > > > On 27. okt. 2013, at 11:57, Varun Singh wrote: > >> Hi all, >> >> In RMCAT WG there has been discussion surrounding the use >> of a media traffic generator and to facilitate discussion, >> RMCAT is hosting a side meeting on Sunday, 03 November >> at 1300-1500. I suppose the room details will be announced >> shortly. >> >> Below is a list of questions that will help design or choose >> an appropriate traffic generator for Interactive multimedia traffic. >> The list is an initial set and mainly to foster discussion both >> on the mailing list and at the meeting. >> >> Mirja and Lars are not available that day, hence on their behalf, >> the meeting is hosted by Colin and I . >> >> Cheers, >> Varun >> --- >> >> Traffic generator: to model the intrinsic variability of video: >> >> - what target bit rates can be achieved? (max?, min?) >> - how much variability in media bit rate for a given target bit rate >> - how to model motion? capturing high motion leads to bursty video >> (higher than target bit rate), but by how much? can this even be done? >> >> Traffic generator: on responsiveness to a new target bitrate: >> >> - how quickly can the codec generate a lower bit rate? >> - immediately? does this depend on the new or requested bit rate? >> - what is immediately? is it next frame or a few frames later, until the= n >> does it generates at the current rate? >> - if not immediately, what bitrates (and duration) will it generate befo= re >> meeting the target bitrate. >> >> >> - how quickly can the codec generate a higher bit rate? >> - immediately in the next frame? does this also depend on the new >> or requested bit rate? >> - not immediately but in steps of intermediate bitrates, i.e., intermedi= ate >> bitrate for a short duration then an increase in step, repeating until >> reaching the target bit rate. >> >> - If the target bit rate is achieved in steps, can they be announced to = the >> congestion controller, i.e., the congestion controller knows the ramp u= p >> curve to meet the target bit rate. >> >> - If the media bit rate has not yet reached the requested target bit rat= e and >> the congestion control requests a new target bit rate, how does the cod= ec >> respond? >> >> Application design related: >> - should the congestion control be able to change the frame rate (video)= or >> packetization time (audio) or is this something that the application co= ntrols. >> - should the congestion control be able to change video resolution? >> - should error-repair: NACKs, FEC be considered part of congestion contr= ol or >> outside it, i.e., it is something that the application does and not >> congestion control >> - If FEC is controlled by the congestion control, how quickly can the se= nding >> rate be adapted by reducing/adding redundancy (FEC)? is something link = this >> done? Does this makes sense at all? >> - Apart from loss and RTT, what other congestion cues are currently used= by >> congestion control algorithms? e.g., Decoding rate/goodput, application >> decode error rate, ECN, PCN, etc. >> - If the codec is data limited, i.e., producing a sending rate smaller t= han the >> one calculated by the congestion control, can the congestion control pr= obe >> the bandwidth by sending additional data packets in a certain pattern (= e.g., >> PathChirp)? would somehting link this help? >> - application input on prioritization: audio vs video (vs data) >> >> >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > --=20 http://www.netlab.tkk.fi/~varun/ From michawe@ifi.uio.no Sun Oct 27 04:33:15 2013 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 85C9511E8228 for ; Sun, 27 Oct 2013 04:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90zSLhF5T9dd for ; Sun, 27 Oct 2013 04:33:10 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6C211E815F for ; Sun, 27 Oct 2013 04:33:10 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VaOai-0000sE-PR; Sun, 27 Oct 2013 12:33:08 +0100 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VaOah-0007ln-Td; Sun, 27 Oct 2013 12:33:08 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Sun, 27 Oct 2013 12:33:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <16A86E0B-509A-4EE0-AA1E-90E167134845@ifi.uio.no> References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> To: Varun Singh X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 9 sum msgs/h 4 total rcpts 9022 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F094046DDD45776368621770E549C7B14F657555 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 431 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 11:33:15 -0000 On 27. okt. 2013, at 12:25, Varun Singh wrote: > On Sun, Oct 27, 2013 at 1:08 PM, Michael Welzl = wrote: >> [removing the other lists except rmcat] >>=20 >> Great initiative, count me in! (sorry for saying this only so late) >>=20 >> Re: discussion on the mailing list, here's a question I have, since = you mention "how to model motion". Does a list of standard test = sequences (like these http://media.xiph.org/video/derf/ ) for = interactive use exist? If not, maybe a subset of those could be picked = (I'd imagine that foreman is rather representative for interactive use, = but many others are not :) ). >>=20 >=20 > There is also the "news" sequence which is quite popular for mimicking > heads and shoulders but it has a pirouetting ballerina in the > background. Indeed I think there are several that could quite easily be picked from = e.g. http://media.xiph.org/video/derf/ as being representative for interactive use. e.g. also carphone... a good handful of fitting ones I'd say. >=20 >=20 >> Now, next, what if we'd have a set of such sequences, and then stack = them over a codec that produces quite arbitrary bitrates, assuming that = the network can always follow it - as a sort of extreme case test? Then = we'd have standard test sequences of bit rates that could be used to = check how good a particular cc. is at following along. I'm not saying = that "follow along" is all a controller's supposed to do, indeed a codec = can react to feedback from the network, but couldn't this be a useful = way of separating out at least one side of the story and having = something to test? >>=20 >> I also wonder about the related work in this regard... there must be = tons of papers out there on this problem? >>=20 >> Cheers, >> Michael >>=20 >>=20 >> On 27. okt. 2013, at 11:57, Varun Singh = wrote: >>=20 >>> Hi all, >>>=20 >>> In RMCAT WG there has been discussion surrounding the use >>> of a media traffic generator and to facilitate discussion, >>> RMCAT is hosting a side meeting on Sunday, 03 November >>> at 1300-1500. I suppose the room details will be announced >>> shortly. >>>=20 >>> Below is a list of questions that will help design or choose >>> an appropriate traffic generator for Interactive multimedia traffic. >>> The list is an initial set and mainly to foster discussion both >>> on the mailing list and at the meeting. >>>=20 >>> Mirja and Lars are not available that day, hence on their behalf, >>> the meeting is hosted by Colin and I . >>>=20 >>> Cheers, >>> Varun >>> --- >>>=20 >>> Traffic generator: to model the intrinsic variability of video: >>>=20 >>> - what target bit rates can be achieved? (max?, min?) >>> - how much variability in media bit rate for a given target bit rate >>> - how to model motion? capturing high motion leads to bursty video >>> (higher than target bit rate), but by how much? can this even be = done? >>>=20 >>> Traffic generator: on responsiveness to a new target bitrate: >>>=20 >>> - how quickly can the codec generate a lower bit rate? >>> - immediately? does this depend on the new or requested bit rate? >>> - what is immediately? is it next frame or a few frames later, until = then >>> does it generates at the current rate? >>> - if not immediately, what bitrates (and duration) will it generate = before >>> meeting the target bitrate. >>>=20 >>>=20 >>> - how quickly can the codec generate a higher bit rate? >>> - immediately in the next frame? does this also depend on the new >>> or requested bit rate? >>> - not immediately but in steps of intermediate bitrates, i.e., = intermediate >>> bitrate for a short duration then an increase in step, repeating = until >>> reaching the target bit rate. >>>=20 >>> - If the target bit rate is achieved in steps, can they be announced = to the >>> congestion controller, i.e., the congestion controller knows the = ramp up >>> curve to meet the target bit rate. >>>=20 >>> - If the media bit rate has not yet reached the requested target bit = rate and >>> the congestion control requests a new target bit rate, how does the = codec >>> respond? >>>=20 >>> Application design related: >>> - should the congestion control be able to change the frame rate = (video) or >>> packetization time (audio) or is this something that the application = controls. >>> - should the congestion control be able to change video resolution? >>> - should error-repair: NACKs, FEC be considered part of congestion = control or >>> outside it, i.e., it is something that the application does and not >>> congestion control >>> - If FEC is controlled by the congestion control, how quickly can = the sending >>> rate be adapted by reducing/adding redundancy (FEC)? is something = link this >>> done? Does this makes sense at all? >>> - Apart from loss and RTT, what other congestion cues are currently = used by >>> congestion control algorithms? e.g., Decoding rate/goodput, = application >>> decode error rate, ECN, PCN, etc. >>> - If the codec is data limited, i.e., producing a sending rate = smaller than the >>> one calculated by the congestion control, can the congestion control = probe >>> the bandwidth by sending additional data packets in a certain = pattern (e.g., >>> PathChirp)? would somehting link this help? >>> - application input on prioritization: audio vs video (vs data) >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> http://www.netlab.tkk.fi/~varun/ >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ From vsingh.ietf@gmail.com Sun Oct 27 04:33:49 2013 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 E859D11E817C for ; Sun, 27 Oct 2013 04:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-qixCp7NW6n for ; Sun, 27 Oct 2013 04:33:49 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 28D2C11E8131 for ; Sun, 27 Oct 2013 04:33:49 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so9220013iec.20 for ; Sun, 27 Oct 2013 04:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Oz7zVSL+r+S24HPO9yvjCQFAia5SH00KXunfpxag+C8=; b=0C9f1GEcxx+/mtIhBtiIqwOSVqk1Po5Tv3H11ZYg8txHrmuZZho3/PQIwt8SESJD2n +EBli6MYSA0zMgN7VuWEdgdGB2wOkVPdXFkrY7qBe6Upy88pYgt18eMMPIbBNqriFlAa gHJ+Te3bOWcmkp5BvdAV2bl7P9vvWVx8s7yH4ZgBBW/tRQtHY3s+IP3hfGm+XTZVgBF7 RGO5DOL9kcODm/b+okLltyZGkG2Cjil6vikF8el0hDHREqcKeIqY2DtoNXjdBwgFLxWI MaSx77ZAWWZ+Jh0VaaKVrzE5t6zdJ8BlDZird1v0cXG4CzZBRgDzJS0twKpnBm4Nrsfz /4mA== X-Received: by 10.50.115.35 with SMTP id jl3mr4832339igb.37.1382873628702; Sun, 27 Oct 2013 04:33:48 -0700 (PDT) References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> From: Varun Singh Mime-Version: 1.0 (1.0) In-Reply-To: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> Date: Sun, 27 Oct 2013 13:33:37 +0200 Message-ID: <-1283924527815223035@unknownmsgid> To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 11:33:50 -0000 Hi Michael, > Now, next, what if we'd have a set of such sequences, and then stack them= over a codec that produces quite arbitrary bitrates, assuming that the net= work can always follow it - Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? > as a sort of extreme case test? Then we'd have standard test sequences of= bit rates that could be used to check how good a particular cc. is at foll= owing along. I'm not saying that "follow along" is all a controller's suppo= sed to do, indeed a codec can react to feedback from the network, but could= n't this be a useful way of separating out at least one side of the story a= nd having something to test? > > I also wonder about the related work in this regard... there must be tons= of papers out there on this problem? > > Cheers, > Michael > > >> On 27. okt. 2013, at 11:57, Varun Singh wrote: >> >> Hi all, >> >> In RMCAT WG there has been discussion surrounding the use >> of a media traffic generator and to facilitate discussion, >> RMCAT is hosting a side meeting on Sunday, 03 November >> at 1300-1500. I suppose the room details will be announced >> shortly. >> >> Below is a list of questions that will help design or choose >> an appropriate traffic generator for Interactive multimedia traffic. >> The list is an initial set and mainly to foster discussion both >> on the mailing list and at the meeting. >> >> Mirja and Lars are not available that day, hence on their behalf, >> the meeting is hosted by Colin and I . >> >> Cheers, >> Varun >> --- >> >> Traffic generator: to model the intrinsic variability of video: >> >> - what target bit rates can be achieved? (max?, min?) >> - how much variability in media bit rate for a given target bit rate >> - how to model motion? capturing high motion leads to bursty video >> (higher than target bit rate), but by how much? can this even be done? >> >> Traffic generator: on responsiveness to a new target bitrate: >> >> - how quickly can the codec generate a lower bit rate? >> - immediately? does this depend on the new or requested bit rate? >> - what is immediately? is it next frame or a few frames later, until the= n >> does it generates at the current rate? >> - if not immediately, what bitrates (and duration) will it generate befo= re >> meeting the target bitrate. >> >> >> - how quickly can the codec generate a higher bit rate? >> - immediately in the next frame? does this also depend on the new >> or requested bit rate? >> - not immediately but in steps of intermediate bitrates, i.e., intermedi= ate >> bitrate for a short duration then an increase in step, repeating until >> reaching the target bit rate. >> >> - If the target bit rate is achieved in steps, can they be announced to = the >> congestion controller, i.e., the congestion controller knows the ramp up >> curve to meet the target bit rate. >> >> - If the media bit rate has not yet reached the requested target bit rat= e and >> the congestion control requests a new target bit rate, how does the code= c >> respond? >> >> Application design related: >> - should the congestion control be able to change the frame rate (video)= or >> packetization time (audio) or is this something that the application con= trols. >> - should the congestion control be able to change video resolution? >> - should error-repair: NACKs, FEC be considered part of congestion contr= ol or >> outside it, i.e., it is something that the application does and not >> congestion control >> - If FEC is controlled by the congestion control, how quickly can the se= nding >> rate be adapted by reducing/adding redundancy (FEC)? is something link t= his >> done? Does this makes sense at all? >> - Apart from loss and RTT, what other congestion cues are currently used= by >> congestion control algorithms? e.g., Decoding rate/goodput, application >> decode error rate, ECN, PCN, etc. >> - If the codec is data limited, i.e., producing a sending rate smaller t= han the >> one calculated by the congestion control, can the congestion control pro= be >> the bandwidth by sending additional data packets in a certain pattern (e= .g., >> PathChirp)? would somehting link this help? >> - application input on prioritization: audio vs video (vs data) >> >> >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From vsingh.ietf@gmail.com Sun Oct 27 04:35:45 2013 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 D0BA011E8276 for ; Sun, 27 Oct 2013 04:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy2MmMX75v+k for ; Sun, 27 Oct 2013 04:35:40 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 522C111E8228 for ; Sun, 27 Oct 2013 04:35:32 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so9372893iec.41 for ; Sun, 27 Oct 2013 04:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3mB84OUHU77X0yPQYs4AN0j9u8ZmROCiiJ6YRAQNuPU=; b=RkzMP+DqutkhLJJlkyjMv6f5LicCsT+w4YrUeFzVyMGDmw4eCOFrslKff+BCTZKgp5 TVLbRglIgL6G5eFWLl7TPRCSd5JvHhDpJYhHQNdw/G38pN5NzWMKiawpquI/s3mHue+/ IyC3+HyPzsiIn4fSGeS/FdCh7FNb4UFoEDrvDXFYJzPJOOxhqs3iI0q2qJJpecsYAOOi bfbQWiTuX3S3qw1OoAdAD/Ae9icrey7M79RmenZgcKiyG0Rtq1pZitPFXzyvFgZm/yLW 2TkgqUO1AvS1GELUe/VnuYRQVCIqQH7HjEIJUd5DJQhjsisO6zEJbV4/5Sj4XXZwDh/+ tJZw== X-Received: by 10.50.1.78 with SMTP id 14mr4837138igk.37.1382873731852; Sun, 27 Oct 2013 04:35:31 -0700 (PDT) References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> <16A86E0B-509A-4EE0-AA1E-90E167134845@ifi.uio.no> From: Varun Singh Mime-Version: 1.0 (1.0) In-Reply-To: <16A86E0B-509A-4EE0-AA1E-90E167134845@ifi.uio.no> Date: Sun, 27 Oct 2013 13:35:26 +0200 Message-ID: <892751837518189280@unknownmsgid> To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 11:35:45 -0000 > On 27.10.2013, at 13.33, Michael Welzl wrote: > > >> On 27. okt. 2013, at 12:25, Varun Singh wrote: >> >>> On Sun, Oct 27, 2013 at 1:08 PM, Michael Welzl wro= te: >>> [removing the other lists except rmcat] >>> >>> Great initiative, count me in! (sorry for saying this only so late) >>> >>> Re: discussion on the mailing list, here's a question I have, since you= mention "how to model motion". Does a list of standard test sequences (lik= e these http://media.xiph.org/video/derf/ ) for interactive use exist? If n= ot, maybe a subset of those could be picked (I'd imagine that foreman is ra= ther representative for interactive use, but many others are not :) ). >>> >> >> There is also the "news" sequence which is quite popular for mimicking >> heads and shoulders but it has a pirouetting ballerina in the >> background. > > Indeed I think there are several that could quite easily be picked from e= .g. > http://media.xiph.org/video/derf/ > as being representative for interactive use. > > e.g. also carphone... a good handful of fitting ones I'd say. > I'm all for picking a handful of sequences. :) We used foreman and news for our circuit breaker, rrtcc and FEC paper. >> >>> Now, next, what if we'd have a set of such sequences, and then stack th= em over a codec that produces quite arbitrary bitrates, assuming that the n= etwork can always follow it - as a sort of extreme case test? Then we'd hav= e standard test sequences of bit rates that could be used to check how good= a particular cc. is at following along. I'm not saying that "follow along"= is all a controller's supposed to do, indeed a codec can react to feedback= from the network, but couldn't this be a useful way of separating out at l= east one side of the story and having something to test? >>> >>> I also wonder about the related work in this regard... there must be to= ns of papers out there on this problem? >>> >>> Cheers, >>> Michael >>> >>> >>>> On 27. okt. 2013, at 11:57, Varun Singh wrote: >>>> >>>> Hi all, >>>> >>>> In RMCAT WG there has been discussion surrounding the use >>>> of a media traffic generator and to facilitate discussion, >>>> RMCAT is hosting a side meeting on Sunday, 03 November >>>> at 1300-1500. I suppose the room details will be announced >>>> shortly. >>>> >>>> Below is a list of questions that will help design or choose >>>> an appropriate traffic generator for Interactive multimedia traffic. >>>> The list is an initial set and mainly to foster discussion both >>>> on the mailing list and at the meeting. >>>> >>>> Mirja and Lars are not available that day, hence on their behalf, >>>> the meeting is hosted by Colin and I . >>>> >>>> Cheers, >>>> Varun >>>> --- >>>> >>>> Traffic generator: to model the intrinsic variability of video: >>>> >>>> - what target bit rates can be achieved? (max?, min?) >>>> - how much variability in media bit rate for a given target bit rate >>>> - how to model motion? capturing high motion leads to bursty video >>>> (higher than target bit rate), but by how much? can this even be done? >>>> >>>> Traffic generator: on responsiveness to a new target bitrate: >>>> >>>> - how quickly can the codec generate a lower bit rate? >>>> - immediately? does this depend on the new or requested bit rate? >>>> - what is immediately? is it next frame or a few frames later, until t= hen >>>> does it generates at the current rate? >>>> - if not immediately, what bitrates (and duration) will it generate be= fore >>>> meeting the target bitrate. >>>> >>>> >>>> - how quickly can the codec generate a higher bit rate? >>>> - immediately in the next frame? does this also depend on the new >>>> or requested bit rate? >>>> - not immediately but in steps of intermediate bitrates, i.e., interme= diate >>>> bitrate for a short duration then an increase in step, repeating until >>>> reaching the target bit rate. >>>> >>>> - If the target bit rate is achieved in steps, can they be announced t= o the >>>> congestion controller, i.e., the congestion controller knows the ramp = up >>>> curve to meet the target bit rate. >>>> >>>> - If the media bit rate has not yet reached the requested target bit r= ate and >>>> the congestion control requests a new target bit rate, how does the co= dec >>>> respond? >>>> >>>> Application design related: >>>> - should the congestion control be able to change the frame rate (vide= o) or >>>> packetization time (audio) or is this something that the application c= ontrols. >>>> - should the congestion control be able to change video resolution? >>>> - should error-repair: NACKs, FEC be considered part of congestion con= trol or >>>> outside it, i.e., it is something that the application does and not >>>> congestion control >>>> - If FEC is controlled by the congestion control, how quickly can the = sending >>>> rate be adapted by reducing/adding redundancy (FEC)? is something link= this >>>> done? Does this makes sense at all? >>>> - Apart from loss and RTT, what other congestion cues are currently us= ed by >>>> congestion control algorithms? e.g., Decoding rate/goodput, applicatio= n >>>> decode error rate, ECN, PCN, etc. >>>> - If the codec is data limited, i.e., producing a sending rate smaller= than the >>>> one calculated by the congestion control, can the congestion control p= robe >>>> the bandwidth by sending additional data packets in a certain pattern = (e.g., >>>> PathChirp)? would somehting link this help? >>>> - application input on prioritization: audio vs video (vs data) >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> http://www.netlab.tkk.fi/~varun/ >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ > From michawe@ifi.uio.no Sun Oct 27 04:51:06 2013 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 19DE811E827B for ; Sun, 27 Oct 2013 04:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+MiMNWIgngs for ; Sun, 27 Oct 2013 04:51:00 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id E65B211E817C for ; Sun, 27 Oct 2013 04:50:59 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VaOrz-0004mB-8z; Sun, 27 Oct 2013 12:50:59 +0100 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VaOry-0000i6-PK; Sun, 27 Oct 2013 12:50:59 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <-1283924527815223035@unknownmsgid> Date: Sun, 27 Oct 2013 12:50:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> <-1283924527815223035@unknownmsgid> To: Varun Singh X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 3 sum rcpts/h 12 sum msgs/h 5 total rcpts 9025 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 737DEB06879F33AFB3C5C2D66A57705574260340 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 432 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 11:51:06 -0000 On 27. okt. 2013, at 12:33, Varun Singh wrote: > Hi Michael, >=20 >=20 >> Now, next, what if we'd have a set of such sequences, and then stack = them over a codec that produces quite arbitrary bitrates, assuming that = the network can always follow it - >=20 > Do you mean preparing the same video sequence at multiple rates and > the congestion controller picking the appropriate media rate that fits > its estimate? ie rate switch between different media rates of the same > sequence? I think that could be a very good idea! I was actually thinking of the opposite, but I'm not sure if that makes = sense: by their nature, if you assume no congestion control and just = send data following these videos with a fixed frame rate, such that the = data has to arrive at the receiver in time, the videos will translate = into rate fluctuations, and an "ideal" congestion controller dealing = with a non-reactive codec would then follow along with these videos. Or are these fluctuations too small to play a role, and changing the = encoding rate of these videos is the only real effect that you would = really "feel" on the network side? In this case, my proposal doesn't make sense I guess, but yours = certainly does? Cheers, Michael From vsingh.ietf@gmail.com Sun Oct 27 09:07:29 2013 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 CDB2421E80CC for ; Sun, 27 Oct 2013 09:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCS7LxqeMyNh for ; Sun, 27 Oct 2013 09:07:28 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3945021E80D0 for ; Sun, 27 Oct 2013 09:07:25 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id at1so9775463iec.1 for ; Sun, 27 Oct 2013 09:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=2hOrNzTIaaslSP7QZIHdD+NeHTuYKmn1i83pW90+U8U=; b=f4/kQQqJGedadJQ+Ye2M5qObxGXYJcp1pHYWm5Hh8bjbbtT2/o8MA9CeMImRBxOCFV Z396MsVBX2EMbEwuha03w3CSeXXOuGijiOpYa20dFPDMw0UGs/HoWegp3W8O3dsvMc4F clc0uAarc/sHslpgHEg2ZLxEFMWH0sbLox19iTwl94z3vJ71Kcliwclr5hAJzGAYhoHB n4rV9ER2/Ug7+mMi2hRcdHkrI/FzHxfwPKEOojaxLoF56gqNCyaVMZCQ5lNpXijXFJYO ppaXMhQtC7+5fX+KorMOgiHohJ6m/Oyl0kCRLPXrzPVj1r+XiemCLMww6WSBEqR3GPUa aGrA== X-Received: by 10.43.58.141 with SMTP id wk13mr11049390icb.1.1382890018271; Sun, 27 Oct 2013 09:06:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sun, 27 Oct 2013 09:06:38 -0700 (PDT) In-Reply-To: References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> <-1283924527815223035@unknownmsgid> From: Varun Singh Date: Sun, 27 Oct 2013 18:06:38 +0200 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 16:07:30 -0000 Hi Michael, comments inline. Cheers, Varun On Sun, Oct 27, 2013 at 1:50 PM, Michael Welzl wrote: > > On 27. okt. 2013, at 12:33, Varun Singh wrote: > >> Hi Michael, >> >> >>> Now, next, what if we'd have a set of such sequences, and then stack th= em over a codec that produces quite arbitrary bitrates, assuming that the n= etwork can always follow it - >> >> Do you mean preparing the same video sequence at multiple rates and >> the congestion controller picking the appropriate media rate that fits >> its estimate? ie rate switch between different media rates of the same >> sequence? > > I think that could be a very good idea! > > I was actually thinking of the opposite, but I'm not sure if that makes s= ense: by their nature, if you assume no congestion control and just send da= ta following these videos with a fixed frame rate, such that the data has t= o arrive at the receiver in time, the videos will translate into rate fluct= uations, and an "ideal" congestion controller dealing with a non-reactive c= odec would then follow along with these videos. > Would require that the sending buffer would have to pace out packets (or drop them) based on the congestion controller estimate? > Or are these fluctuations too small to play a role, and changing the enco= ding rate of these videos is the only real effect that you would really "fe= el" on the network side? > > In this case, my proposal doesn't make sense I guess, but yours certainly= does? > I am not particularly fond of the rate-switching idea, because it depends o= n the number of target rates per sequence, i.e., if too few rates are used, switc= hing would be coarse grained leading to too slow ramp-up (or sometimes not even possible), the ramp-downs may undershoot by too much. The alternative would be to have sequences at several intermediate rates. The other issue is, if we would like to playback the received video (to observe) the rate-switching between the different sequences would have to occur at particular instances (e.g., at key frame boundaries?). These techniques are used for in video streaming, therefore, if we go ahead with such a technique, it should be possible to carefully select a set of target rates for evaluating the RMCAT congestion control mechanisms. > Cheers, > Michael > --=20 http://www.netlab.tkk.fi/~varun/ From michawe@ifi.uio.no Sun Oct 27 09:31:01 2013 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 DF39F11E828F for ; Sun, 27 Oct 2013 09:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeFG9Oip9XZs for ; Sun, 27 Oct 2013 09:30:56 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id AAE0B11E8295 for ; Sun, 27 Oct 2013 09:30:55 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VaTEo-0000yu-2R; Sun, 27 Oct 2013 17:30:50 +0100 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VaTEn-0004z7-76; Sun, 27 Oct 2013 17:30:50 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Sun, 27 Oct 2013 17:30:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <252DB004-AA1E-4FBB-89A5-87F4DBF200FF@ifi.uio.no> References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> <-1283924527815223035@unknownmsgid> To: Varun Singh X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 9033 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EB7A67BEBE63E6D6B22592239B04D94D82F5E31D X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 436 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 16:31:02 -0000 On 27. okt. 2013, at 17:06, Varun Singh wrote: > Hi Michael, >=20 > comments inline. >=20 > Cheers, > Varun >=20 > On Sun, Oct 27, 2013 at 1:50 PM, Michael Welzl = wrote: >>=20 >> On 27. okt. 2013, at 12:33, Varun Singh = wrote: >>=20 >>> Hi Michael, >>>=20 >>>=20 >>>> Now, next, what if we'd have a set of such sequences, and then = stack them over a codec that produces quite arbitrary bitrates, assuming = that the network can always follow it - >>>=20 >>> Do you mean preparing the same video sequence at multiple rates and >>> the congestion controller picking the appropriate media rate that = fits >>> its estimate? ie rate switch between different media rates of the = same >>> sequence? >>=20 >> I think that could be a very good idea! >>=20 >> I was actually thinking of the opposite, but I'm not sure if that = makes sense: by their nature, if you assume no congestion control and = just send data following these videos with a fixed frame rate, such that = the data has to arrive at the receiver in time, the videos will = translate into rate fluctuations, and an "ideal" congestion controller = dealing with a non-reactive codec would then follow along with these = videos. >>=20 >=20 > Would require that the sending buffer would have to pace out packets > (or drop them) based on the congestion controller estimate? I was not considering a congestion controller at all, but imagining that = packets are sent out from the sender buffer at a rate of FS / T, where = FS =3D the size of the next frame in the buffer, and T =3D a fixed time = interval over which the frame is sent (some fixed parameter). Wouldn't this give us the rates at which a congestion controller would = have to drain the send buffer, assuming: - a codec that doesn't react to anything - that every frame arrives on the receiving end within a certain fixed = time interval (of course assuming a perfect network) Maybe there's a flaw somewhere here, but that was my thinking... to = produce some kind of workload that can be used to test congestion = controllers. >> Or are these fluctuations too small to play a role, and changing the = encoding rate of these videos is the only real effect that you would = really "feel" on the network side? >>=20 >> In this case, my proposal doesn't make sense I guess, but yours = certainly does? >>=20 >=20 > I am not particularly fond of the rate-switching idea, because it = depends on the > number of target rates per sequence, i.e., if too few rates are used, = switching > would be coarse grained leading to too slow ramp-up (or sometimes not > even possible), the ramp-downs may undershoot by too much. The = alternative > would be to have sequences at several intermediate rates. >=20 > The other issue is, if we would like to playback the received video > (to observe) > the rate-switching between the different sequences would have to occur > at particular > instances (e.g., at key frame boundaries?). >=20 > These techniques are used for in video streaming, therefore, if we go = ahead > with such a technique, it should be possible to carefully select a set > of target rates > for evaluating the RMCAT congestion control mechanisms. Argh, yes, too many problems on the table. Maybe we have to separate two things here. If I consider a non-reactive = application that produces data at rates which fluctuate, like I'm = imagining, then I can create some sort of "worst case" scenario for a = congestion controller from this, and see if my congestion controller = deals well in the presence of such workload. As far as I'm concerned, as a congestion control designer, once I have = investigated how my control operates: 1) with a bulk data transfer (i.e. always-full buffer) 2) with occasionally stopping traffic (i.e. buffer running empty) 3) with a buffer that is filled at varying speeds, and that my = controller is supposed to drain at varying speeds ... then my work is done?! I mean, then we do have a good idea of how good the control is. What we = don't know is if it would be a better system design to give the = controller a workload of type 1 above and let the codec react to make = that happen, or a workload of type 3 above and not react, or exactly = where in between we should place ourselves. This has a big effect on the = quality experienced by the user, of course - but I think this decision = will probably be a function of how well a congestion control deals with = cases 1, 2, 3 above (plus other things, but regarding the congestion = control, this is probably all we need to know?!). So maybe this is where = the line between "congestion control design" and "overall system design" = goes? If so, maybe we don't really need to consider the case of a codec that = reacts to the congestion control when evaluating a congestion controller = at all. I guess so?? Or am I being really stupid right now? If I'm not, this separation could perhaps simplify things a great = deal... Cheers, Michael From vsingh.ietf@gmail.com Sun Oct 27 10:46:33 2013 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 9DA1B11E81A1 for ; Sun, 27 Oct 2013 10:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD4xmDCXGVmI for ; Sun, 27 Oct 2013 10:46:31 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 41C9A11E819A for ; Sun, 27 Oct 2013 10:46:31 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so9728325iec.41 for ; Sun, 27 Oct 2013 10:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=WcRBldmBr5Wlw9WlrBs1v32eOP/4u1to1Crt0rimjms=; b=OIPtGQsCPnSPg/bb1pYOOMBrufh6DRZtIzBp2jl2Rkc9cVLdqFYaIZ09RaecwWn0kp j9P6pfvQ183fpcmGtuYwtYYmEZA42r7C9xhuxXMBDyFiPlRdlb0lGwje5GP4NLm8L0U3 pi0pVgAPCRNPKSq4AhuCjywkhquKsHcnbHEHI6xFwSl69p+hyIGSsP/fddJOJznBI3A3 APVWiOC51/ZAyX7OnKWJtpREErZrnM0i1Jo+ZJjYUNUzYaS/GWwi2BPDylfWJGommzuK dYPe6UGPYDUzcXv+1Uuyi9CAa8DdtSZ9b1mj45ecz6zOQXraji7CLOmghvedIyOoVHGW zImA== X-Received: by 10.42.126.18 with SMTP id c18mr96311ics.46.1382895989306; Sun, 27 Oct 2013 10:46:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sun, 27 Oct 2013 10:46:09 -0700 (PDT) In-Reply-To: <252DB004-AA1E-4FBB-89A5-87F4DBF200FF@ifi.uio.no> References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> <-1283924527815223035@unknownmsgid> <252DB004-AA1E-4FBB-89A5-87F4DBF200FF@ifi.uio.no> From: Varun Singh Date: Sun, 27 Oct 2013 19:46:09 +0200 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 17:46:33 -0000 On Sun, Oct 27, 2013 at 6:30 PM, Michael Welzl wrote: > > On 27. okt. 2013, at 17:06, Varun Singh wrote: > [snip!] >>> I was actually thinking of the opposite, but I'm not sure if that makes= sense: by their nature, if you assume no congestion control and just send = data following these videos with a fixed frame rate, such that the data has= to arrive at the receiver in time, the videos will translate into rate flu= ctuations, and an "ideal" congestion controller dealing with a non-reactive= codec would then follow along with these videos. >>> >> >> Would require that the sending buffer would have to pace out packets >> (or drop them) based on the congestion controller estimate? > > I was not considering a congestion controller at all, but imagining that = packets are sent out from the sender buffer at a rate of FS / T, where FS = =3D the size of the next frame in the buffer, and T =3D a fixed time inter= val over which the frame is sent (some fixed parameter). > > Wouldn't this give us the rates at which a congestion controller would ha= ve to drain the send buffer, assuming: > - a codec that doesn't react to anything > - that every frame arrives on the receiving end within a certain fixed ti= me interval (of course assuming a perfect network) > Agree, a non-reactive codec will produce one of the two behaviours: If the FS/T is less than or matches the available end-to-end capacity, it should arrive in link latency time. If FS/T is more than the end-to-end capacity, the network will add queuing delay. > Maybe there's a flaw somewhere here, but that was my thinking... to produ= ce some kind of workload that can be used to test congestion controllers. > i.e., model the workload such that at some instances it exceeds the capacity and some other instance it doesn't and observe how the sending buffer (controlled by the cc) handles this situation? > >>> Or are these fluctuations too small to play a role, and changing the en= coding rate of these videos is the only real effect that you would really "= feel" on the network side? >>> >>> In this case, my proposal doesn't make sense I guess, but yours certain= ly does? >>> >> >> I am not particularly fond of the rate-switching idea, because it depend= s on the >> number of target rates per sequence, i.e., if too few rates are used, sw= itching >> would be coarse grained leading to too slow ramp-up (or sometimes not >> even possible), the ramp-downs may undershoot by too much. The alternati= ve >> would be to have sequences at several intermediate rates. >> >> The other issue is, if we would like to playback the received video >> (to observe) >> the rate-switching between the different sequences would have to occur >> at particular >> instances (e.g., at key frame boundaries?). >> >> These techniques are used for in video streaming, therefore, if we go ah= ead >> with such a technique, it should be possible to carefully select a set >> of target rates >> for evaluating the RMCAT congestion control mechanisms. > > Argh, yes, too many problems on the table. > > Maybe we have to separate two things here. If I consider a non-reactive a= pplication that produces data at rates which fluctuate, like I'm imagining,= then I can create some sort of "worst case" scenario for a congestion cont= roller from this, and see if my congestion controller deals well in the pre= sence of such workload. > > As far as I'm concerned, as a congestion control designer, once I have in= vestigated how my control operates: > 1) with a bulk data transfer (i.e. always-full buffer) but the size of the buffer would vary depending on the rate generated by the codec, I am not sure if for a variable sized buffer we can say it is full or not. Perhaps the controller can only say if it can drain it as fast as it is filling up. If we have a fixed size buffer, what happens when it overflows? did the controller fail? > 2) with occasionally stopping traffic (i.e. buffer running empty) > 3) with a buffer that is filled at varying speeds, and that my controller= is supposed to drain at varying speeds Agree... > ... then my work is done?! > > I mean, then we do have a good idea of how good the control is. What we d= on't know is if it would be a better system design to give the controller a= workload of type 1 above and let the codec react to make that happen, or a= workload of type 3 above and not react, or exactly where in between we sho= uld place ourselves. This has a big effect on the quality experienced by th= e user, of course - but I think this decision will probably be a function o= f how well a congestion control deals with cases 1, 2, 3 above (plus other = things, but regarding the congestion control, this is probably all we need = to know?!). So maybe this is where the line between "congestion control des= ign" and "overall system design" goes? > This is a good discussion to have :) > If so, maybe we don't really need to consider the case of a codec that re= acts to the congestion control when evaluating a congestion controller at a= ll. I guess so?? Or am I being really stupid right now? > We really should discuss this in the context of **evaluating** RMCAT congestion control, while in the real-world we'd expect some coupling between the codec and the congestion control. > If I'm not, this separation could perhaps simplify things a great deal... > > Cheers, > Michael > Cheers, Varun --=20 http://www.netlab.tkk.fi/~varun/ From dave.taht@gmail.com Sun Oct 27 10:55:12 2013 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 97E1E11E80E7 for ; Sun, 27 Oct 2013 10:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKbgeRlWgKBu for ; Sun, 27 Oct 2013 10:55:00 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 536F011E81A1 for ; Sun, 27 Oct 2013 10:54:59 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so2630092wgh.4 for ; Sun, 27 Oct 2013 10:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NmW5sk2rw3tKiP4cc+4mYGt77irWWac+k1aNgsikFNo=; b=Qqg0G/MgYeNEvPKyKCzY4olQI/GRzzBMdECybDyPZJisDfoHU67m+lG6BGhV1P4GOV Vm2qO84Vb0lmQn8GC02u87nViNs1M0ixe60Dtn/kxJWBAu5HJuagV2uMNztOuHFCgkjM QrlEklSiWRSuElzijY1DbNaRT34BTa3PJ84gZ0RDwlpWr8XD4roDQWY+8RJif2qm0DZS IaQ3B/jKYkhOSdREF7XD2le12c3jOmwh0Tj7abrUp9EkjtSnYtVZVAfpq7GcLfdM+8Bm zlTVBHsQUUZPqFIkaI/jYFCTObv2+GGmBM/vLIsXXz9rGAz17ZJXn2Ji2h0s4u8Gv7LA LoVA== MIME-Version: 1.0 X-Received: by 10.180.13.113 with SMTP id g17mr6014256wic.19.1382896498111; Sun, 27 Oct 2013 10:54:58 -0700 (PDT) Received: by 10.217.67.202 with HTTP; Sun, 27 Oct 2013 10:54:58 -0700 (PDT) In-Reply-To: References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> <-1283924527815223035@unknownmsgid> <252DB004-AA1E-4FBB-89A5-87F4DBF200FF@ifi.uio.no> Date: Sun, 27 Oct 2013 10:54:58 -0700 Message-ID: From: Dave Taht To: Varun Singh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Colin Perkins , Michael Welzl Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 17:55:12 -0000 Given that this is mostly a peer to peer technology, would it be possible to just setup a bunch of laptops and fiddle? I'll bring a router. On Sun, Oct 27, 2013 at 10:46 AM, Varun Singh wrote= : > On Sun, Oct 27, 2013 at 6:30 PM, Michael Welzl wrote= : >> >> On 27. okt. 2013, at 17:06, Varun Singh wrote: >> > [snip!] >>>> I was actually thinking of the opposite, but I'm not sure if that make= s sense: by their nature, if you assume no congestion control and just send= data following these videos with a fixed frame rate, such that the data ha= s to arrive at the receiver in time, the videos will translate into rate fl= uctuations, and an "ideal" congestion controller dealing with a non-reactiv= e codec would then follow along with these videos. >>>> >>> >>> Would require that the sending buffer would have to pace out packets >>> (or drop them) based on the congestion controller estimate? >> >> I was not considering a congestion controller at all, but imagining that= packets are sent out from the sender buffer at a rate of FS / T, where FS = =3D the size of the next frame in the buffer, and T =3D a fixed time inter= val over which the frame is sent (some fixed parameter). >> >> Wouldn't this give us the rates at which a congestion controller would h= ave to drain the send buffer, assuming: >> - a codec that doesn't react to anything >> - that every frame arrives on the receiving end within a certain fixed t= ime interval (of course assuming a perfect network) >> > > Agree, a non-reactive codec will produce one of the two behaviours: > > If the FS/T is less than or matches the available end-to-end capacity, > it should arrive in link latency time. > If FS/T is more than the end-to-end capacity, the network will > add queuing delay. > >> Maybe there's a flaw somewhere here, but that was my thinking... to prod= uce some kind of workload that can be used to test congestion controllers. >> > i.e., model the workload such that at some instances it exceeds the > capacity and some other instance it doesn't and observe how the > sending buffer (controlled by the cc) handles this situation? > >> >>>> Or are these fluctuations too small to play a role, and changing the e= ncoding rate of these videos is the only real effect that you would really = "feel" on the network side? >>>> >>>> In this case, my proposal doesn't make sense I guess, but yours certai= nly does? >>>> >>> >>> I am not particularly fond of the rate-switching idea, because it depen= ds on the >>> number of target rates per sequence, i.e., if too few rates are used, s= witching >>> would be coarse grained leading to too slow ramp-up (or sometimes not >>> even possible), the ramp-downs may undershoot by too much. The alternat= ive >>> would be to have sequences at several intermediate rates. >>> >>> The other issue is, if we would like to playback the received video >>> (to observe) >>> the rate-switching between the different sequences would have to occur >>> at particular >>> instances (e.g., at key frame boundaries?). >>> >>> These techniques are used for in video streaming, therefore, if we go a= head >>> with such a technique, it should be possible to carefully select a set >>> of target rates >>> for evaluating the RMCAT congestion control mechanisms. >> >> Argh, yes, too many problems on the table. >> >> Maybe we have to separate two things here. If I consider a non-reactive = application that produces data at rates which fluctuate, like I'm imagining= , then I can create some sort of "worst case" scenario for a congestion con= troller from this, and see if my congestion controller deals well in the pr= esence of such workload. >> >> As far as I'm concerned, as a congestion control designer, once I have i= nvestigated how my control operates: >> 1) with a bulk data transfer (i.e. always-full buffer) > > but the size of the buffer would vary depending on the rate generated > by the codec, > I am not sure if for a variable sized buffer we can say it is full or > not. Perhaps > the controller can only say if it can drain it as fast as it is filling u= p. > > If we have a fixed size buffer, what happens when it overflows? did > the controller fail? > >> 2) with occasionally stopping traffic (i.e. buffer running empty) >> 3) with a buffer that is filled at varying speeds, and that my controlle= r is supposed to drain at varying speeds > > Agree... > >> ... then my work is done?! >> >> I mean, then we do have a good idea of how good the control is. What we = don't know is if it would be a better system design to give the controller = a workload of type 1 above and let the codec react to make that happen, or = a workload of type 3 above and not react, or exactly where in between we sh= ould place ourselves. This has a big effect on the quality experienced by t= he user, of course - but I think this decision will probably be a function = of how well a congestion control deals with cases 1, 2, 3 above (plus other= things, but regarding the congestion control, this is probably all we need= to know?!). So maybe this is where the line between "congestion control de= sign" and "overall system design" goes? >> > > This is a good discussion to have :) > >> If so, maybe we don't really need to consider the case of a codec that r= eacts to the congestion control when evaluating a congestion controller at = all. I guess so?? Or am I being really stupid right now? >> > > We really should discuss this in the context of **evaluating** RMCAT > congestion control, while in the real-world we'd expect some coupling > between the codec and the congestion control. > >> If I'm not, this separation could perhaps simplify things a great deal..= . >> >> Cheers, >> Michael >> > > Cheers, > Varun > > > > -- > http://www.netlab.tkk.fi/~varun/ --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From michawe@ifi.uio.no Sun Oct 27 11:49:27 2013 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 3C5A111E81D9 for ; Sun, 27 Oct 2013 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS2L27EOS-Ou for ; Sun, 27 Oct 2013 11:49:21 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 632DD11E81A9 for ; Sun, 27 Oct 2013 11:49:19 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VaVOn-0003mI-QV; Sun, 27 Oct 2013 19:49:17 +0100 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VaVOn-0001s7-2C; Sun, 27 Oct 2013 19:49:17 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Sun, 27 Oct 2013 19:49:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A217CFB-57A1-43F7-A391-1CADA2CF9203@ifi.uio.no> References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> <-1283924527815223035@unknownmsgid> <252DB004-AA1E-4FBB-89A5-87F4DBF200FF@ifi.uio.no> To: Varun Singh X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 8 sum msgs/h 3 total rcpts 9038 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 425672B439DA5DBBA167696BFA8999C221BB4285 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 439 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 18:49:27 -0000 On 27. okt. 2013, at 18:46, Varun Singh wrote: > On Sun, Oct 27, 2013 at 6:30 PM, Michael Welzl = wrote: >>=20 >> On 27. okt. 2013, at 17:06, Varun Singh = wrote: >>=20 > [snip!] >>>> I was actually thinking of the opposite, but I'm not sure if that = makes sense: by their nature, if you assume no congestion control and = just send data following these videos with a fixed frame rate, such that = the data has to arrive at the receiver in time, the videos will = translate into rate fluctuations, and an "ideal" congestion controller = dealing with a non-reactive codec would then follow along with these = videos. >>>>=20 >>>=20 >>> Would require that the sending buffer would have to pace out packets >>> (or drop them) based on the congestion controller estimate? >>=20 >> I was not considering a congestion controller at all, but imagining = that packets are sent out from the sender buffer at a rate of FS / T, = where FS =3D the size of the next frame in the buffer, and T =3D a = fixed time interval over which the frame is sent (some fixed parameter). >>=20 >> Wouldn't this give us the rates at which a congestion controller = would have to drain the send buffer, assuming: >> - a codec that doesn't react to anything >> - that every frame arrives on the receiving end within a certain = fixed time interval (of course assuming a perfect network) >>=20 >=20 > Agree, a non-reactive codec will produce one of the two behaviours: >=20 > If the FS/T is less than or matches the available end-to-end capacity, > it should arrive in link latency time. > If FS/T is more than the end-to-end capacity, the network will > add queuing delay. >=20 >> Maybe there's a flaw somewhere here, but that was my thinking... to = produce some kind of workload that can be used to test congestion = controllers. >>=20 > i.e., model the workload such that at some instances it exceeds the > capacity and some other instance it doesn't and observe how the > sending buffer (controlled by the cc) handles this situation? The way I envision it there is no link capacity in this model, which = would make it more generally applicable. The link capacity is unlimited, = you don't care about the link, you just send with the rate the codec = tells you, and so you simply get a sequence of application-desired = rates. Add a link with a given capacity to this, and you get what you describe = - but just having a set of rates would be more general I think. >> Argh, yes, too many problems on the table. >>=20 >> Maybe we have to separate two things here. If I consider a = non-reactive application that produces data at rates which fluctuate, = like I'm imagining, then I can create some sort of "worst case" scenario = for a congestion controller from this, and see if my congestion = controller deals well in the presence of such workload. >>=20 >> As far as I'm concerned, as a congestion control designer, once I = have investigated how my control operates: >> 1) with a bulk data transfer (i.e. always-full buffer) >=20 > but the size of the buffer would vary depending on the rate generated > by the codec, > I am not sure if for a variable sized buffer we can say it is full or > not. Perhaps > the controller can only say if it can drain it as fast as it is = filling up. The only constraint of concern for item #1 is that whenever the = controller wants to send, there is something available. > If we have a fixed size buffer, what happens when it overflows? did > the controller fail? No, it that happens then the application failed to react to the = congestion controller's speed of draining the buffer, and again it's a = larger system problem and we're not really evaluating a congestion = controller anymore. >> 2) with occasionally stopping traffic (i.e. buffer running empty) >> 3) with a buffer that is filled at varying speeds, and that my = controller is supposed to drain at varying speeds >=20 > Agree... >=20 >> ... then my work is done?! >>=20 >> I mean, then we do have a good idea of how good the control is. What = we don't know is if it would be a better system design to give the = controller a workload of type 1 above and let the codec react to make = that happen, or a workload of type 3 above and not react, or exactly = where in between we should place ourselves. This has a big effect on the = quality experienced by the user, of course - but I think this decision = will probably be a function of how well a congestion control deals with = cases 1, 2, 3 above (plus other things, but regarding the congestion = control, this is probably all we need to know?!). So maybe this is where = the line between "congestion control design" and "overall system design" = goes? >>=20 >=20 > This is a good discussion to have :) >=20 >> If so, maybe we don't really need to consider the case of a codec = that reacts to the congestion control when evaluating a congestion = controller at all. I guess so?? Or am I being really stupid right now? >>=20 >=20 > We really should discuss this in the context of **evaluating** RMCAT > congestion control, while in the real-world we'd expect some coupling > between the codec and the congestion control. Yes, I'm only trying to separate these two here for simplicity. I think = we're making the "evaluate congestion control" bit too hard for = ourselves by considering interactions with applications beyond 1) and 2) = and 3) above. Cheers, Michael From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Oct 28 04:32:12 2013 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 9D8F011E818F for ; Mon, 28 Oct 2013 04:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoYqLJU6SGwY for ; Mon, 28 Oct 2013 04:32:08 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4276311E8250 for ; Mon, 28 Oct 2013 04:31:58 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 1757960289; Mon, 28 Oct 2013 12:31:57 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 12036601BA; Mon, 28 Oct 2013 12:31:57 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Mon, 28 Oct 2013 12:31:56 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310281231.56941.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 11:32:12 -0000 Hi Varun, just one comment on one point only: [snip] > I am not particularly fond of the rate-switching idea, because it depends > on the number of target rates per sequence, i.e., if too few rates are > used, switching would be coarse grained leading to too slow ramp-up (or > sometimes not even possible), the ramp-downs may undershoot by too much. > The alternative would be to have sequences at several intermediate rates. What do you me by 'too slow ramp-up'? Of the congestion control? Again my=20 proposal that the transport should potentially probe for available rate and= =20 by this maybe even be able to 'jump' to a higher rate (potentially not to t= he=20 maximum measure available, but safely to something below that). Mirja > The other issue is, if we would like to playback the received video > (to observe) > the rate-switching between the different sequences would have to occur > at particular > instances (e.g., at key frame boundaries?). > > These techniques are used for in video streaming, therefore, if we go ahe= ad > with such a technique, it should be possible to carefully select a set > of target rates > for evaluating the RMCAT congestion control mechanisms. > > > Cheers, > > Michael =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From vsingh.ietf@gmail.com Mon Oct 28 04:52:29 2013 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 1CDA311E81A4 for ; Mon, 28 Oct 2013 04:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ielYzqx+a0z9 for ; Mon, 28 Oct 2013 04:52:28 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 43DD211E8144 for ; Mon, 28 Oct 2013 04:52:28 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so11160030iec.27 for ; Mon, 28 Oct 2013 04:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Kk3dHOrpGb1zoct8dwK06DFhGg1B2hdo0cq9vJf7rzI=; b=qN7RNx8IcDIKf+2D6SEJU3+Xrhg9VcRazVd/z6vc1mynvNsbqXtW97oAkK1caDvXwP utjbPIvn1BG7nEh3a0G0o/Or3SkhZpOK6o7xPU5w+tKnZ+h53vFSokv+dTw27hvoEUT7 i1s+KRJ89fSzcFXiBGA+PKQSi6b3URRklezzHjTbfjpp90LcPSRf81o5KuMwnjOCfpcG HTczmGGNw/QEYv2xocNLlMQnVgLa9uTq3/xivmrm68YsDl04TxM2MDN+6bEdDhlVLWoP wJjU5tDRbMoBFATcq2hBICnkxWsAs5ma8rJOYX1tWKQLexwlKONoExVNdV2nM9SXjVAQ b58A== X-Received: by 10.50.77.72 with SMTP id q8mr8291905igw.14.1382961147720; Mon, 28 Oct 2013 04:52:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Mon, 28 Oct 2013 04:52:07 -0700 (PDT) In-Reply-To: <201310281231.56941.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201310281231.56941.mirja.kuehlewind@ikr.uni-stuttgart.de> From: Varun Singh Date: Mon, 28 Oct 2013 13:52:07 +0200 Message-ID: To: Mirja Kuehlewind Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 11:52:29 -0000 Hi Mirja, On Mon, Oct 28, 2013 at 1:31 PM, Mirja Kuehlewind wrote: > Hi Varun, > > just one comment on one point only: > > [snip] > >> I am not particularly fond of the rate-switching idea, because it depend= s >> on the number of target rates per sequence, i.e., if too few rates are >> used, switching would be coarse grained leading to too slow ramp-up (or >> sometimes not even possible), the ramp-downs may undershoot by too much. >> The alternative would be to have sequences at several intermediate rates= . > What do you me by 'too slow ramp-up'? Of the congestion control? Again my Clarifying what I meant: If the congestion control recommends a new estimate for which there is no media file, the system has to approximate what to do, either pick the file with a higher rate or nearest lower rate. For example: media files with 200, 500, 1000, 1500, 2000 Kbps exist and if the the estimate by the controller is 800 kbps, it can either pick 500 or 1000 kbps. if it picks 500 kbps, it is going to ramp-up more slowly compared to a set of sequences which perhaps has an additional media file for a target bit rate of 750 kbps. In the above example, I arbitrarily picked a set of 5 target rates, if I'd picked 3 or 7 the evaluation would be different. Picking the right number of sequences and/or target rate would affect how quickly the media flow ramps up and down. > proposal that the transport should potentially probe for available rate a= nd > by this maybe even be able to 'jump' to a higher rate (potentially not to= the > maximum measure available, but safely to something below that). > Agree, a congestion controller should be capable of probing when the application is data limited (i.e., media rate is lower than estimate). I suppose this could be done, as long as the probing does not affect the timeliness of the media stream? -Varun > Mirja > > >> The other issue is, if we would like to playback the received video >> (to observe) >> the rate-switching between the different sequences would have to occur >> at particular >> instances (e.g., at key frame boundaries?). >> >> These techniques are used for in video streaming, therefore, if we go ah= ead >> with such a technique, it should be possible to carefully select a set >> of target rates >> for evaluating the RMCAT congestion control mechanisms. >> >> > Cheers, >> > Michael > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- --=20 http://www.netlab.tkk.fi/~varun/ From csp@csperkins.org Mon Oct 28 10:50:05 2013 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 910CF11E81A5 for ; Mon, 28 Oct 2013 10:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.832 X-Spam-Level: X-Spam-Status: No, score=-103.832 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VimgaV6uNKgS for ; Mon, 28 Oct 2013 10:50:05 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD4411E8290 for ; Mon, 28 Oct 2013 10:50:04 -0700 (PDT) Received: from [130.209.247.112] (port=57864 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Vaqwt-0006Pk-Ac; Mon, 28 Oct 2013 17:49:55 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: Date: Mon, 28 Oct 2013 17:49:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <36A884CD-80DE-4AAC-87DD-8550896675F2@csperkins.org> References: <9B69754F-101D-4F62-B77D-2A4A2A6A7388@ifi.uio.no> <-1283924527815223035@unknownmsgid> To: Michael Welzl X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rmcat WG , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 17:50:05 -0000 On 27 Oct 2013, at 11:50, Michael Welzl wrote: > On 27. okt. 2013, at 12:33, Varun Singh wrote: >>> Now, next, what if we'd have a set of such sequences, and then stack = them over a codec that produces quite arbitrary bitrates, assuming that = the network can always follow it - >>=20 >> Do you mean preparing the same video sequence at multiple rates and = the congestion controller picking the appropriate media rate that fits = its estimate? ie rate switch between different media rates of the same = sequence? >=20 > I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test = sequences, that we can use to test the combination of video codec and = congestion control. If we're building something for interactive video = congestion control we should assume live encoding, with the codec = potentially having the flexibility to react to the network, and our = testbed ought to reflect that. --=20 Colin Perkins http://csperkins.org/ From mzanaty@cisco.com Mon Oct 28 11:39:12 2013 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 40F1311E80E7 for ; Mon, 28 Oct 2013 11:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx-LiXHeDezp for ; Mon, 28 Oct 2013 11:39:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1402511E82C5 for ; Mon, 28 Oct 2013 11:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2324; q=dns/txt; s=iport; t=1382985547; x=1384195147; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rK/RisdO4ah0QTFUW5MZzGaZVEWf5Fz+bbecfoBO2qY=; b=RuNXmvWwyQO8OCOz/CDD/9wlt5Q9yx3HMWBkpnUwQVBX3FAFAOlQKt/w 9HGAzGJPaFz6y/PPF8Jr1TB8Wd3xGDwpn1rzUoxqywPUCjgKoMr4bI2x5 JlAuxSWWF/8L+stkPzcKe/uLBGSLCGd0sx+qpHjYHu3JKbRU3taW81mYh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFANeublKtJXG//2dsb2JhbABZgwc4VL5kgSkWdIIlAQEBBDo/EgEIDgoKFDERJQIEAQ0FCIdtAw+uXg2Ja4xlgj8xB4MfgQ0Dlh+DGoshhTeBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,587,1378857600"; d="scan'208";a="277667103" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 28 Oct 2013 18:39:06 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9SId6ej004750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 18:39:06 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 13:39:06 -0500 From: "Mo Zanaty (mzanaty)" To: Colin Perkins , Michael Welzl Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1Az7cIsoFJLa10u7yiGXQQ0oog== Date: Mon, 28 Oct 2013 18:39:05 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> In-Reply-To: <36A884CD-80DE-4AAC-87DD-8550896675F2@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.233.187] Content-Type: text/plain; charset="us-ascii" Content-ID: <7B658721CC2DB04E903A917211349E10@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rmcat WG , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 18:39:12 -0000 I agree with Colin. We should be focused on live encoding where the encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small set of fixed bitrates like DASH/HLS. A more formal approach to the problem would be to decompose the factors contributing to the final rate placed onto the network. 1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the encoded frame size using constant quantization, i.e. no encoder rate control. 2. Video encoder rate control behavior, which modulates the source statistics to fit into network constraints over rather large time intervals (>0.5s). 3. Network transmission pacing / shaper, which smooths out bursts in encoder output to fit into network constraints over fine time intervals (<0.5s). It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors). Mo On 10/28/13, 1:49 PM, Colin Perkins wrote: On 27 Oct 2013, at 11:50, Michael Welzl wrote: > On 27. okt. 2013, at 12:33, Varun Singh wrote: >>> Now, next, what if we'd have a set of such sequences, and then stack >>>them over a codec that produces quite arbitrary bitrates, assuming that >>>the network can always follow it - >>=20 >> Do you mean preparing the same video sequence at multiple rates and the >>congestion controller picking the appropriate media rate that fits its >>estimate? ie rate switch between different media rates of the same >>sequence? >=20 > I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that. --=20 Colin Perkins http://csperkins.org/ From xiaoqzhu@cisco.com Mon Oct 28 13:15:18 2013 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 A375E11E81C9 for ; Mon, 28 Oct 2013 13:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5ZDOD7c2zsG for ; Mon, 28 Oct 2013 13:15:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 967BB11E81BB for ; Mon, 28 Oct 2013 13:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8639; q=dns/txt; s=iport; t=1382991312; x=1384200912; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5UDAIXWWKLaKw8BEN6277XkIOErncY06wxYww2WugRI=; b=iI3msqnDJ4la6WhReA7PR9XF+LWdlnNhgjrq/MqDFta5I4wXlRDaC52q T4HFUBb9WRK36J83dqeyISnfljquyjAKUy5GzEnMECfazuV4E+UdZTVjt 21WDukx/8l3RL8mFWrmxM9U9JRCDE+OH2p83H37XdMs2D7lZq+rAY9viM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMHABTFblKtJV2Z/2dsb2JhbABZgmYhOEgMrDKJZohMgSoWdIImAQEEeRACAQgiHQchERQRAgQOBQgBh2wDDwEMrjUNiWuMZYI/MQcJgxaBDQOWH4MaiyGFN4FogT6CKg X-IronPort-AV: E=Sophos;i="4.93,587,1378857600"; d="scan'208,217";a="277709602" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 28 Oct 2013 20:15:08 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9SKF8JV010691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 20:15:08 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 15:15:08 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "Mo Zanaty (mzanaty)" Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1A0MgwVs6QKB+UiBda2MQkwFlZoK4IGA Date: Mon, 28 Oct 2013 20:15:07 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.12.119] Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA216BCAAAxmbalnx13ciscoc_" MIME-Version: 1.0 Cc: rmcat WG , Colin Perkins , Michael Welzl , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 20:15:18 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA216BCAAAxmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree with Colin and Mo. For a statistical video traffic model, I would propose to break down the 2n= d point (encoder rate control) in Mo's list further, to three sub-component= s: a) delayed response to a rate change request (e.g., > 0.5s) b) deviations from the requested rate (maybe as randomly fluctuating around= the target?) c) the different frame types or coding modes inside the encoder will yield = some encoded frames much larger than others. This will lead to burstiness on time scale = of frame intervals (typically 33ms), and later smoothed out by the pacing/shaper. Also, if we go for the approach of using uncompressed test video sequence f= or testing the combination of video codec and congestion control, we should= also recommend a reference codec and default configurations. So that focus= of the evaluations remains on the congestion control module. What do folk= s think of x264 (http://www.videolan.org/developers/x264.html)? Best, Xiaoqing On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) > wrote: I agree with Colin. We should be focused on live encoding where the encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small set of fixed bitrates like DASH/HLS. A more formal approach to the problem would be to decompose the factors contributing to the final rate placed onto the network. 1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the encoded frame size using constant quantization, i.e. no encoder rate control. 2. Video encoder rate control behavior, which modulates the source statistics to fit into network constraints over rather large time intervals (>0.5s). 3. Network transmission pacing / shaper, which smooths out bursts in encoder output to fit into network constraints over fine time intervals (<0.5s). It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors). Mo On 10/28/13, 1:49 PM, Colin Perkins > wrote: On 27 Oct 2013, at 11:50, Michael Welzl > wrote: On 27. okt. 2013, at 12:33, Varun Singh > wrote: Now, next, what if we'd have a set of such sequences, and then stack them over a codec that produces quite arbitrary bitrates, assuming that the network can always follow it - Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that. -- Colin Perkins http://csperkins.org/ --_000_E7175A8E3DC14048A7D3020E0338C1FA216BCAAAxmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <94A120B9F9C2F44694F5D443E77A7C50@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Agree with Colin and Mo. 

For a statistical video traffic model, I would propose to break down t= he 2nd point (encoder rate control) in Mo's list further, to three sub-comp= onents:

a) delayed response to a rate change request (e.g., > 0.5s)
b) deviations from the requested rate (maybe as randomly fluctuating a= round the target?) 
c) the different frame types or coding modes inside the encoder will y= ield some encoded
frames much larger than others. This will lead to burstiness on time s= cale of frame intervals
(typically 33ms), and later smoothed out by the pacing/shaper. 

Also, if we go for the approach of using uncompressed test video seque= nce for testing the combination of video codec and congestion control,= we should also recommend a reference codec and default configurations= . So that focus of the evaluations remains on the congestion control module.  What do folks think of x264 (http://www.videolan.org= /developers/x264.html)? 

Best,
Xiaoqing

 

On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

I agree with Colin. We should be focused on live = encoding where the
encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any
real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> wrote:
On 27. okt. 2013, at 12:33, Varun Singh <vsingh.ietf@gmail.com> wrote:
Now, next, what if we'd have a set of such sequen= ces, and then stack
them over a codec that produces quite arbitrary bitrates, assuming that
the network can always follow it -

Do you mean preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?

I think that could be a very good idea!

I'd be more interested in a standard set of *uncompressed* video test
sequences, that we can use to test the combination of video codec and
congestion control. If we're building something for interactive video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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





--_000_E7175A8E3DC14048A7D3020E0338C1FA216BCAAAxmbalnx13ciscoc_-- From geertv@qti.qualcomm.com Mon Oct 28 13:43:53 2013 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 381B921E80D0 for ; Mon, 28 Oct 2013 13:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHwTH7v+kFh0 for ; Mon, 28 Oct 2013 13:43:49 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAC111E81BB for ; Mon, 28 Oct 2013 13:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1382993029; x=1414529029; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=38YPSejxADi2rqX0fb2OQTsR5cad49yTHlBKwuVPhaA=; b=LlRJhuSEEWKudCTsJGYOmntAYMPYVIPhkgplzixQ+ar9hYDm6HtLoU+H zTmsV14kSgdPcZpiZkkLX1P+6sRSGLpIvzxWMgeq6EubuzLQ/XanJmT5j 9EYg4fKWqMbBGP0j6BciO3/btGfBttA/fsYIp1hfFpq0wA3WT3NXJAmSE o=; X-IronPort-AV: E=McAfee;i="5400,1158,7242"; a="54650370" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 28 Oct 2013 13:43:48 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7242"; a="540256999" Received: from nasanexhc02.na.qualcomm.com ([172.30.48.24]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 Oct 2013 13:43:48 -0700 Received: from NASANEXD02B.na.qualcomm.com ([169.254.2.138]) by NASANEXHC02.na.qualcomm.com ([172.30.48.24]) with mapi id 14.03.0158.001; Mon, 28 Oct 2013 13:43:48 -0700 From: "Van Der Auwera, Geert" To: "Xiaoqing Zhu (xiaoqzhu)" , "Mo Zanaty (mzanaty)" Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1A0EG0YvF8AS50yTfPkYRpKfaZoLAgiA//+NtdA= Date: Mon, 28 Oct 2013 20:43:47 +0000 Message-ID: <4FC1F85139E6FE4D9A55BD6798B29A4816AD5D34@NASANEXD02B.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_4FC1F85139E6FE4D9A55BD6798B29A4816AD5D34NASANEXD02Bnaqu_" MIME-Version: 1.0 Cc: rmcat WG , Colin Perkins , Michael Welzl , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 20:43:53 -0000 --_000_4FC1F85139E6FE4D9A55BD6798B29A4816AD5D34NASANEXD02Bnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also agree. For initial evaluations of CC proposals and to find consensus q= uickly, a statistical video traffic model should be sufficient. However, pr= oponents should be allowed and perhaps encouraged from producing additional= results with a complete live video encoding testbed of their choice (video= quality?). Agreeing on a particular codec at this point may be a bit hard.= Regarding the uncompressed test video sequences (VT type), Qualcomm could = provide a set of long sequences (> 1min). Best regards, Geert From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of X= iaoqing Zhu (xiaoqzhu) Sent: Monday, October 28, 2013 1:15 PM To: Mo Zanaty (mzanaty) Cc: rmcat WG; Colin Perkins; Michael Welzl; Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouve= r (03 Nov, 1300-1500) Agree with Colin and Mo. For a statistical video traffic model, I would propose to break down the 2n= d point (encoder rate control) in Mo's list further, to three sub-component= s: a) delayed response to a rate change request (e.g., > 0.5s) b) deviations from the requested rate (maybe as randomly fluctuating around= the target?) c) the different frame types or coding modes inside the encoder will yield = some encoded frames much larger than others. This will lead to burstiness on time scale = of frame intervals (typically 33ms), and later smoothed out by the pacing/shaper. Also, if we go for the approach of using uncompressed test video sequence f= or testing the combination of video codec and congestion control, we should= also recommend a reference codec and default configurations. So that focus= of the evaluations remains on the congestion control module. What do folk= s think of x264 (http://www.videolan.org/developers/x264.html)? Best, Xiaoqing On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) > wrote: I agree with Colin. We should be focused on live encoding where the encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small set of fixed bitrates like DASH/HLS. A more formal approach to the problem would be to decompose the factors contributing to the final rate placed onto the network. 1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the encoded frame size using constant quantization, i.e. no encoder rate control. 2. Video encoder rate control behavior, which modulates the source statistics to fit into network constraints over rather large time intervals (>0.5s). 3. Network transmission pacing / shaper, which smooths out bursts in encoder output to fit into network constraints over fine time intervals (<0.5s). It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors). Mo On 10/28/13, 1:49 PM, Colin Perkins > wrote: On 27 Oct 2013, at 11:50, Michael Welzl > wrote: On 27. okt. 2013, at 12:33, Varun Singh > wrote: Now, next, what if we'd have a set of such sequences, and then stack them over a codec that produces quite arbitrary bitrates, assuming that the network can always follow it - Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that. -- Colin Perkins http://csperkins.org/ --_000_4FC1F85139E6FE4D9A55BD6798B29A4816AD5D34NASANEXD02Bnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Also agree. For initial e= valuations of CC proposals and to find consensus quickly, a statistical vid= eo traffic model should be sufficient. However, proponents should be allowed and perhaps encouraged from producing additional results= with a complete live video encoding testbed of their choice (video quality= ?). Agreeing on a particular codec at this point may be a bit hard. Regardi= ng the uncompressed test video sequences (VT type), Qualcomm could provide a set of long sequences (> 1min).

 <= /p>

Best regards,<= /span>

 <= /p>

Geert

 <= /p>

From: rmcat-bo= unces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Xiaoqing Zhu (xiaoqzhu)
Sent: Monday, October 28, 2013 1:15 PM
To: Mo Zanaty (mzanaty)
Cc: rmcat WG; Colin Perkins; Michael Welzl; Varun Singh
Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in V= ancouver (03 Nov, 1300-1500)

 

Agree with Colin and Mo. 

 

For a statistical video traffic model, I would propo= se to break down the 2nd point (encoder rate control) in Mo's list further,= to three sub-components:

 

a) delayed response to a rate change request (e.g., = > 0.5s)

b) deviations from the requested rate (maybe as rand= omly fluctuating around the target?) 

c) the different frame types or coding modes inside = the encoder will yield some encoded

frames much larger than others. This will lead to bu= rstiness on time scale of frame intervals

(typically 33ms), and later smoothed out by the paci= ng/shaper. 

 

Also, if we go for the approach of using uncompresse= d test video sequence for testing the combination of video codec and c= ongestion control, we should also recommend a reference codec and defa= ult configurations. So that focus of the evaluations remains on the congestion control module.  What do folks think of x26= 4 (http://www.vide= olan.org/developers/x264.html)? 

 

Best,

Xiaoqing

 

 

 

On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) <= ;mzanaty@cisco.com> wrote:=



I agree with Colin. We should be focused on live enc= oding where the
encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any
real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> wrote:

On 27. okt. 2013, at 12:33, Varun Singh <vsingh.ietf@gmail.com> wrote:

Now, next, what if we'd have a set of such sequences= , and then stack
them over a codec that produces quite arbitrary bitrates, assuming that
the network can always follow it -


Do you mean preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?


I think that could be a very good idea!


I'd be more interested in a standard set of *uncompressed* video test
sequences, that we can use to test the combination of video codec and
congestion control. If we're building something for interactive video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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



 

--_000_4FC1F85139E6FE4D9A55BD6798B29A4816AD5D34NASANEXD02Bnaqu_-- From bernard_aboba@hotmail.com Mon Oct 28 14:58:43 2013 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 413FB11E8350 for ; Mon, 28 Oct 2013 14:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEI8Ks34whKX for ; Mon, 28 Oct 2013 14:58:37 -0700 (PDT) Received: from blu0-omc3-s35.blu0.hotmail.com (blu0-omc3-s35.blu0.hotmail.com [65.55.116.110]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA411E834C for ; Mon, 28 Oct 2013 14:58:35 -0700 (PDT) Received: from BLU405-EAS185 ([65.55.116.73]) by blu0-omc3-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Oct 2013 14:58:34 -0700 X-TMN: [mgBxdHK4FGMdDSjr2+vUveSI+DLZLKBC] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Van Der Auwera, Geert'" , "'Xiaoqing Zhu \(xiaoqzhu\)'" , "'Mo Zanaty \(mzanaty\)'" References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> <4FC1F85139E6FE4D9A55BD6798B29A4816AD5D34@NASANEXD02B.na.qualcomm.com> In-Reply-To: <4FC1F85139E6FE4D9A55BD6798B29A4816AD5D34@NASANEXD02B.na.qualcomm.com> Date: Mon, 28 Oct 2013 14:58:32 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CED3EE.2BDB69C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQABAgMEFyJKCF+upfAY8y2LvQEgcgDnhNONANA3oyEA+EiamgAhdZxhAC7DyRsAFcmRxp2Nmn6Q Content-Language: en-us X-OriginalArrivalTime: 28 Oct 2013 21:58:34.0612 (UTC) FILETIME=[D914C340:01CED428] Cc: 'rmcat WG' , 'Colin Perkins' , 'Michael Welzl' , 'Varun Singh' Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 21:58:43 -0000 ------=_NextPart_000_0001_01CED3EE.2BDB69C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Colin said: "Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? " [BA] I like this approach, because it somewhat approximates the situation of simulcast/layered coding. Previous work has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, so as to be able to send at least one video stream as well as issues with TFRFC) that would be likely to be missed in a model in which an encoder has fully smooth rate control. I agree with Colin. We should be focused on live encoding where the encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small set of fixed bitrates like DASH/HLS. A more formal approach to the problem would be to decompose the factors contributing to the final rate placed onto the network. 1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the encoded frame size using constant quantization, i.e. no encoder rate control. 2. Video encoder rate control behavior, which modulates the source statistics to fit into network constraints over rather large time intervals (>0.5s). 3. Network transmission pacing / shaper, which smooths out bursts in encoder output to fit into network constraints over fine time intervals (<0.5s). It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors). Mo On 10/28/13, 1:49 PM, Colin Perkins > wrote: On 27 Oct 2013, at 11:50, Michael Welzl > wrote: On 27. okt. 2013, at 12:33, Varun Singh > wrote: Now, next, what if we'd have a set of such sequences, and then stack them over a codec that produces quite arbitrary bitrates, assuming that the network can always follow it - Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that. -- Colin Perkins http://csperkins.org/ ------=_NextPart_000_0001_01CED3EE.2BDB69C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colin said:

 

“Do you mean preparing the same video sequence at = multiple rates and the
congestion controller picking the appropriate = media rate that fits its
estimate? ie rate switch between different = media rates of the same
sequence?

”

 

[BA] I like this approach, because it somewhat approximates the = situation of simulcast/layered coding.  Previous work has indicated = a number of considerations that arise in those implementations (such as = the need for rapid rampup, so as to be able to send at least one video = stream as well as issues with TFRFC) that would be likely to be missed = in a model in which an encoder has fully smooth rate control. =   

 

I agree with Colin. We should be focused = on live encoding where the
encoder rate control is highly granular = (often fully smooth) and coupled
to the network congestion control, = not pre-encoded streaming of a small
set of fixed bitrates like = DASH/HLS.

A more formal approach to the problem would be to = decompose the factors
contributing to the final rate placed onto the = network.
1. Video content / source statistics, using a large set of = representative
sequences. An estimate of the entropy per frame could = simply be the
encoded frame size using constant quantization, i.e. no = encoder rate
control.
2. Video encoder rate control behavior, = which modulates the source
statistics to fit into network constraints = over rather large time
intervals (>0.5s).
3. Network = transmission pacing / shaper, which smooths out bursts in
encoder = output to fit into network constraints over fine time = intervals
(<0.5s).

It should be possible to model all three = in an abstract way to arrive at
some statistical model that can then = be used for all tests without any
real video content or encoding (to = avoid introducing noise in comparisons
if there was any variability = in any of the factors).

Mo



On 10/28/13, 1:49 PM, = Colin Perkins <csp@csperkins.org> = wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> = wrote:

On 27. okt. 2013, at 12:33, Varun Singh = <vsingh.ietf@gmail.com> = wrote:

Now, = next, what if we'd have a set of such sequences, and then stack
them = over a codec that produces quite arbitrary bitrates, assuming = that
the network can always follow it -


Do you mean preparing the same video sequence at = multiple rates and the
congestion controller picking the appropriate = media rate that fits its
estimate? ie rate switch between different = media rates of the same
sequence?


I think that could be a very good = idea!


I'd be more interested in a standard = set of *uncompressed* video test
sequences, that we can use to test = the combination of video codec and
congestion control. If we're = building something for interactive video
congestion control we should = assume live encoding, with the codec
potentially having the = flexibility to react to the network, and our
testbed ought to reflect = that.

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


=

 

------=_NextPart_000_0001_01CED3EE.2BDB69C0-- From mzanaty@cisco.com Mon Oct 28 15:10:38 2013 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 6BCF611E81CC for ; Mon, 28 Oct 2013 15:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1I3-cEy4tEk for ; Mon, 28 Oct 2013 15:10:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E640D21F9FE5 for ; Mon, 28 Oct 2013 15:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12021; q=dns/txt; s=iport; t=1382998233; x=1384207833; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=vEDiPImRcMcGpPKWD3JOP8uuDBZcAsAjk9Lf4JwrLn0=; b=Q0LdyHxpSQNquHzw6pJkMwZeNToYOfcpU4ePQ+YFim+dSHCgZy28Pbqq uOroeTO0Bj9lehBBMQvLfLsyPbwG69vGfvcnq+6yttyEJSonUyzQsd4m7 mNdBMrhm82RYdpSvSHIIXRgJuRw06V8K+y4rvdmdypVJpBprjdJRJ2wzs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMHAFLgblKtJV2Y/2dsb2JhbABZgkNEOFSsBjKJZohMgSoWdIInAQQtTBIBCCIdKBEUEQIEAQ0FCIdtAw+uWg2Ja4xlgTGBDjEHCYMWgQ0Dlh8BgxmLIYU3gWiBPoFoQg X-IronPort-AV: E=Sophos;i="4.93,588,1378857600"; d="scan'208,217";a="277741797" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 28 Oct 2013 22:10:32 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9SMAWiq005261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 22:10:32 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 17:10:32 -0500 From: "Mo Zanaty (mzanaty)" To: Bernard Aboba , "'Van Der Auwera, Geert'" , "Xiaoqing Zhu (xiaoqzhu)" Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1CqEgwVs6QKB+UiBda2MQkwFlQ== Date: Mon, 28 Oct 2013 22:10:31 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91E124D16@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.233.187] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91E124D16xmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: 'rmcat WG' , 'Colin Perkins' , 'Michael Welzl' , 'Varun Singh' Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 22:10:38 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91E124D16xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is true for simulcast layers, but not necessarily scalable layers. For= the latter, arbitrary rates can be achieved within a limited range (like d= own to half the bitrate) by selectively dropping some packets of the highes= t enhancement layer with minimal visual quality impact. If the stream is hi= ghly scalable (many layers, which is rare), the limited range expands (like= down to maybe a third, quarter, or less of the bitrate). If the stream is = coarsely scalable (e.g. two layers, which is common), dropping below the li= mited range incurs changing encoding parameters, at which point arbitrary r= ates are again possible. Mo On 10/28/13, 5:58 PM, Bernard Aboba > wrote: Colin said: =93Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? =94 [BA] I like this approach, because it somewhat approximates the situation o= f simulcast/layered coding. Previous work has indicated a number of consid= erations that arise in those implementations (such as the need for rapid ra= mpup, so as to be able to send at least one video stream as well as issues = with TFRFC) that would be likely to be missed in a model in which an encode= r has fully smooth rate control. I agree with Colin. We should be focused on live encoding where the encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small set of fixed bitrates like DASH/HLS. A more formal approach to the problem would be to decompose the factors contributing to the final rate placed onto the network. 1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the encoded frame size using constant quantization, i.e. no encoder rate control. 2. Video encoder rate control behavior, which modulates the source statistics to fit into network constraints over rather large time intervals (>0.5s). 3. Network transmission pacing / shaper, which smooths out bursts in encoder output to fit into network constraints over fine time intervals (<0.5s). It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors). Mo On 10/28/13, 1:49 PM, Colin Perkins > wrote: On 27 Oct 2013, at 11:50, Michael Welzl > wrote: On 27. okt. 2013, at 12:33, Varun Singh > wrote: Now, next, what if we'd have a set of such sequences, and then stack them over a codec that produces quite arbitrary bitrates, assuming that the network can always follow it - Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that. -- Colin Perkins http://csperkins.org/ --_000_3879D71E758A7E4AA99A35DD8D41D3D91E124D16xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <77D5280BB928C74E840F1E7170DBB648@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
This is true for simulcast layers, but not necessarily scalable layers= . For the latter, arbitrary rates can be achieved within a limited range (l= ike down to half the bitrate) by selectively dropping some packets of the h= ighest enhancement layer with minimal visual quality impact. If the stream is highly scalable (many layers, whic= h is rare), the limited range expands (like down to maybe a third, quarter,= or less of the bitrate). If the stream is coarsely scalable (e.g. two laye= rs, which is common), dropping below the limited range incurs changing encoding parameters, at which point arbi= trary rates are again possible.

Mo


On 10/28/13, 5:58 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

Colin said:

 

=93Do you mean preparing the= same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?

=94

 

[BA] I like this approach, because = it somewhat approximates the situation of simulcast/layered coding.  P= revious work has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, so= as to be able to send at least one video stream as well as issues with TFR= FC) that would be likely to be missed in a model in which an encoder has fu= lly smooth rate control.   

 

I agree with Colin. W= e should be focused on live encoding where the
encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any
real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> wrote:

On 27. okt. 2013, at = 12:33, Varun Singh <vsingh.ietf= @gmail.com> wrote:

Now, next, what if we'd have a set of such sequences= , and then stack
them over a codec that produces quite arbitrary bitrates, assuming that
the network can always follow it -


Do you mean preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?


I think that could be a very good idea!


I'd be more interested in a standard set of *uncompressed* video test
sequences, that we can use to test the combination of video codec and
congestion control. If we're building something for interactive video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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


 

 --_000_3879D71E758A7E4AA99A35DD8D41D3D91E124D16xmbrcdx14ciscoc_-- From bernard_aboba@hotmail.com Mon Oct 28 16:46:28 2013 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 453AD11E81D1 for ; Mon, 28 Oct 2013 16:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.212 X-Spam-Level: X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61M5nGzRiF8q for ; Mon, 28 Oct 2013 16:45:36 -0700 (PDT) Received: from blu0-omc3-s2.blu0.hotmail.com (blu0-omc3-s2.blu0.hotmail.com [65.55.116.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0A411E81AF for ; Mon, 28 Oct 2013 16:45:36 -0700 (PDT) Received: from BLU405-EAS263 ([65.55.116.74]) by blu0-omc3-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Oct 2013 16:45:27 -0700 X-TMN: [PNOJN0Hwwc9yHrOOSmmMGSnG9Zf/nb3V] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-ED3D013D-28F2-4158-B402-2B8652CA5B19" Content-Transfer-Encoding: 7bit References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D16@xmb-rcd-x14.cisco.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91E124D16@xmb-rcd-x14.cisco.com> Date: Mon, 28 Oct 2013 16:45:21 -0700 To: "Mo Zanaty (mzanaty)" X-OriginalArrivalTime: 28 Oct 2013 23:45:27.0154 (UTC) FILETIME=[C7410520:01CED437] Cc: "Van Der Auwera, Geert" , Michael Welzl , rmcat WG , "Xiaoqing Zhu \(xiaoqzhu\)" , Colin Perkins , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 23:46:28 -0000 X-List-Received-Date: Mon, 28 Oct 2013 23:46:28 -0000 --Apple-Mail-ED3D013D-28F2-4158-B402-2B8652CA5B19 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91J3JlIHJpZ2h0IHRoYXQgdGhlcmUgaXMgZmxleGliaWxpdHkgaW4gZW5oYW5jZW1lbnQgbGF5 ZXJzLiBCdXQgYmVjYXVzZSBvZiB0aGUgbGF5ZXJpbmcgc3RydWN0dXJlLCB0aGUgYmFzZSBpcyBu b3QgZmxleGlibGUgLSBzaW5jZSB0aGUgZW5oYW5jZW1lbnQgbGF5ZXJzIGRlcGVuZCBvbiBpdCwg aXQgaXMgdHlwaWNhbGx5IHByb3RlY3RlZCB2aWEgRkVDIG9yIFJUWC4gVGhpcyBhZmZlY3RzIHRo ZSB2aWFiaWxpdHkgb2YgInNsb3cgc3RhcnQiIHNjaGVtZXMgYXMgd2VsbCBvdGhlciBhc3BlY3Rz IC0gbm8gcG9pbnQgc2VuZGluZyB2aWRlbyBhdCBhbGwgaWYgeW91IGNhbm5vdCBzdXBwb3J0IHRo ZSBiYXNlIGxheWVyLCBhdCBsZWFzdC4NCg0KPiBPbiBPY3QgMjgsIDIwMTMsIGF0IDM6MTAgUE0s ICJNbyBaYW5hdHkgKG16YW5hdHkpIiA8bXphbmF0eUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4g VGhpcyBpcyB0cnVlIGZvciBzaW11bGNhc3QgbGF5ZXJzLCBidXQgbm90IG5lY2Vzc2FyaWx5IHNj YWxhYmxlIGxheWVycy4gRm9yIHRoZSBsYXR0ZXIsIGFyYml0cmFyeSByYXRlcyBjYW4gYmUgYWNo aWV2ZWQgd2l0aGluIGEgbGltaXRlZCByYW5nZSAobGlrZSBkb3duIHRvIGhhbGYgdGhlIGJpdHJh dGUpIGJ5IHNlbGVjdGl2ZWx5IGRyb3BwaW5nIHNvbWUgcGFja2V0cyBvZiB0aGUgaGlnaGVzdCBl bmhhbmNlbWVudCBsYXllciB3aXRoIG1pbmltYWwgdmlzdWFsIHF1YWxpdHkgaW1wYWN0LiBJZiB0 aGUgc3RyZWFtIGlzIGhpZ2hseSBzY2FsYWJsZSAobWFueSBsYXllcnMsIHdoaWNoIGlzIHJhcmUp LCB0aGUgbGltaXRlZCByYW5nZSBleHBhbmRzIChsaWtlIGRvd24gdG8gbWF5YmUgYSB0aGlyZCwg cXVhcnRlciwgb3IgbGVzcyBvZiB0aGUgYml0cmF0ZSkuIElmIHRoZSBzdHJlYW0gaXMgY29hcnNl bHkgc2NhbGFibGUgKGUuZy4gdHdvIGxheWVycywgd2hpY2ggaXMgY29tbW9uKSwgZHJvcHBpbmcg YmVsb3cgdGhlIGxpbWl0ZWQgcmFuZ2UgaW5jdXJzIGNoYW5naW5nIGVuY29kaW5nIHBhcmFtZXRl cnMsIGF0IHdoaWNoIHBvaW50IGFyYml0cmFyeSByYXRlcyBhcmUgYWdhaW4gcG9zc2libGUuDQo+ IA0KPiBNbw0KPiANCj4gDQo+IE9uIDEwLzI4LzEzLCA1OjU4IFBNLCBCZXJuYXJkIEFib2JhIDxi ZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tPiB3cm90ZToNCj4gDQo+IENvbGluIHNhaWQ6DQo+ICAN Cj4g4oCcRG8geW91IG1lYW4gcHJlcGFyaW5nIHRoZSBzYW1lIHZpZGVvIHNlcXVlbmNlIGF0IG11 bHRpcGxlIHJhdGVzIGFuZCB0aGUNCj4gY29uZ2VzdGlvbiBjb250cm9sbGVyIHBpY2tpbmcgdGhl IGFwcHJvcHJpYXRlIG1lZGlhIHJhdGUgdGhhdCBmaXRzIGl0cw0KPiBlc3RpbWF0ZT8gaWUgcmF0 ZSBzd2l0Y2ggYmV0d2VlbiBkaWZmZXJlbnQgbWVkaWEgcmF0ZXMgb2YgdGhlIHNhbWUNCj4gc2Vx dWVuY2U/DQo+IOKAnQ0KPiAgDQo+IFtCQV0gSSBsaWtlIHRoaXMgYXBwcm9hY2gsIGJlY2F1c2Ug aXQgc29tZXdoYXQgYXBwcm94aW1hdGVzIHRoZSBzaXR1YXRpb24gb2Ygc2ltdWxjYXN0L2xheWVy ZWQgY29kaW5nLiAgUHJldmlvdXMgd29yayBoYXMgaW5kaWNhdGVkIGEgbnVtYmVyIG9mIGNvbnNp ZGVyYXRpb25zIHRoYXQgYXJpc2UgaW4gdGhvc2UgaW1wbGVtZW50YXRpb25zIChzdWNoIGFzIHRo ZSBuZWVkIGZvciByYXBpZCByYW1wdXAsIHNvIGFzIHRvIGJlIGFibGUgdG8gc2VuZCBhdCBsZWFz dCBvbmUgdmlkZW8gc3RyZWFtIGFzIHdlbGwgYXMgaXNzdWVzIHdpdGggVEZSRkMpIHRoYXQgd291 bGQgYmUgbGlrZWx5IHRvIGJlIG1pc3NlZCBpbiBhIG1vZGVsIGluIHdoaWNoIGFuIGVuY29kZXIg aGFzIGZ1bGx5IHNtb290aCByYXRlIGNvbnRyb2wuICAgDQo+ICANCj4gDQo+IEkgYWdyZWUgd2l0 aCBDb2xpbi4gV2Ugc2hvdWxkIGJlIGZvY3VzZWQgb24gbGl2ZSBlbmNvZGluZyB3aGVyZSB0aGUN Cj4gZW5jb2RlciByYXRlIGNvbnRyb2wgaXMgaGlnaGx5IGdyYW51bGFyIChvZnRlbiBmdWxseSBz bW9vdGgpIGFuZCBjb3VwbGVkDQo+IHRvIHRoZSBuZXR3b3JrIGNvbmdlc3Rpb24gY29udHJvbCwg bm90IHByZS1lbmNvZGVkIHN0cmVhbWluZyBvZiBhIHNtYWxsDQo+IHNldCBvZiBmaXhlZCBiaXRy YXRlcyBsaWtlIERBU0gvSExTLg0KPiANCj4gQSBtb3JlIGZvcm1hbCBhcHByb2FjaCB0byB0aGUg cHJvYmxlbSB3b3VsZCBiZSB0byBkZWNvbXBvc2UgdGhlIGZhY3RvcnMNCj4gY29udHJpYnV0aW5n IHRvIHRoZSBmaW5hbCByYXRlIHBsYWNlZCBvbnRvIHRoZSBuZXR3b3JrLg0KPiAxLiBWaWRlbyBj b250ZW50IC8gc291cmNlIHN0YXRpc3RpY3MsIHVzaW5nIGEgbGFyZ2Ugc2V0IG9mIHJlcHJlc2Vu dGF0aXZlDQo+IHNlcXVlbmNlcy4gQW4gZXN0aW1hdGUgb2YgdGhlIGVudHJvcHkgcGVyIGZyYW1l IGNvdWxkIHNpbXBseSBiZSB0aGUNCj4gZW5jb2RlZCBmcmFtZSBzaXplIHVzaW5nIGNvbnN0YW50 IHF1YW50aXphdGlvbiwgaS5lLiBubyBlbmNvZGVyIHJhdGUNCj4gY29udHJvbC4NCj4gMi4gVmlk ZW8gZW5jb2RlciByYXRlIGNvbnRyb2wgYmVoYXZpb3IsIHdoaWNoIG1vZHVsYXRlcyB0aGUgc291 cmNlDQo+IHN0YXRpc3RpY3MgdG8gZml0IGludG8gbmV0d29yayBjb25zdHJhaW50cyBvdmVyIHJh dGhlciBsYXJnZSB0aW1lDQo+IGludGVydmFscyAoPjAuNXMpLg0KPiAzLiBOZXR3b3JrIHRyYW5z bWlzc2lvbiBwYWNpbmcgLyBzaGFwZXIsIHdoaWNoIHNtb290aHMgb3V0IGJ1cnN0cyBpbg0KPiBl bmNvZGVyIG91dHB1dCB0byBmaXQgaW50byBuZXR3b3JrIGNvbnN0cmFpbnRzIG92ZXIgZmluZSB0 aW1lIGludGVydmFscw0KPiAoPDAuNXMpLg0KPiANCj4gSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRv IG1vZGVsIGFsbCB0aHJlZSBpbiBhbiBhYnN0cmFjdCB3YXkgdG8gYXJyaXZlIGF0DQo+IHNvbWUg c3RhdGlzdGljYWwgbW9kZWwgdGhhdCBjYW4gdGhlbiBiZSB1c2VkIGZvciBhbGwgdGVzdHMgd2l0 aG91dCBhbnkNCj4gcmVhbCB2aWRlbyBjb250ZW50IG9yIGVuY29kaW5nICh0byBhdm9pZCBpbnRy b2R1Y2luZyBub2lzZSBpbiBjb21wYXJpc29ucw0KPiBpZiB0aGVyZSB3YXMgYW55IHZhcmlhYmls aXR5IGluIGFueSBvZiB0aGUgZmFjdG9ycykuDQo+IA0KPiBNbw0KPiANCj4gDQo+IA0KPiBPbiAx MC8yOC8xMywgMTo0OSBQTSwgQ29saW4gUGVya2lucyA8Y3NwQGNzcGVya2lucy5vcmc+IHdyb3Rl Og0KPiANCj4gT24gMjcgT2N0IDIwMTMsIGF0IDExOjUwLCBNaWNoYWVsIFdlbHpsIDxtaWNoYXdl QGlmaS51aW8ubm8+IHdyb3RlOg0KPiANCj4gT24gMjcuIG9rdC4gMjAxMywgYXQgMTI6MzMsIFZh cnVuIFNpbmdoIDx2c2luZ2guaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gTm93LCBuZXh0 LCB3aGF0IGlmIHdlJ2QgaGF2ZSBhIHNldCBvZiBzdWNoIHNlcXVlbmNlcywgYW5kIHRoZW4gc3Rh Y2sNCj4gdGhlbSBvdmVyIGEgY29kZWMgdGhhdCBwcm9kdWNlcyBxdWl0ZSBhcmJpdHJhcnkgYml0 cmF0ZXMsIGFzc3VtaW5nIHRoYXQNCj4gdGhlIG5ldHdvcmsgY2FuIGFsd2F5cyBmb2xsb3cgaXQg LQ0KPiANCj4gRG8geW91IG1lYW4gcHJlcGFyaW5nIHRoZSBzYW1lIHZpZGVvIHNlcXVlbmNlIGF0 IG11bHRpcGxlIHJhdGVzIGFuZCB0aGUNCj4gY29uZ2VzdGlvbiBjb250cm9sbGVyIHBpY2tpbmcg dGhlIGFwcHJvcHJpYXRlIG1lZGlhIHJhdGUgdGhhdCBmaXRzIGl0cw0KPiBlc3RpbWF0ZT8gaWUg cmF0ZSBzd2l0Y2ggYmV0d2VlbiBkaWZmZXJlbnQgbWVkaWEgcmF0ZXMgb2YgdGhlIHNhbWUNCj4g c2VxdWVuY2U/DQo+IA0KPiBJIHRoaW5rIHRoYXQgY291bGQgYmUgYSB2ZXJ5IGdvb2QgaWRlYSEN Cj4gDQo+IEknZCBiZSBtb3JlIGludGVyZXN0ZWQgaW4gYSBzdGFuZGFyZCBzZXQgb2YgKnVuY29t cHJlc3NlZCogdmlkZW8gdGVzdA0KPiBzZXF1ZW5jZXMsIHRoYXQgd2UgY2FuIHVzZSB0byB0ZXN0 IHRoZSBjb21iaW5hdGlvbiBvZiB2aWRlbyBjb2RlYyBhbmQNCj4gY29uZ2VzdGlvbiBjb250cm9s LiBJZiB3ZSdyZSBidWlsZGluZyBzb21ldGhpbmcgZm9yIGludGVyYWN0aXZlIHZpZGVvDQo+IGNv bmdlc3Rpb24gY29udHJvbCB3ZSBzaG91bGQgYXNzdW1lIGxpdmUgZW5jb2RpbmcsIHdpdGggdGhl IGNvZGVjDQo+IHBvdGVudGlhbGx5IGhhdmluZyB0aGUgZmxleGliaWxpdHkgdG8gcmVhY3QgdG8g dGhlIG5ldHdvcmssIGFuZCBvdXINCj4gdGVzdGJlZCBvdWdodCB0byByZWZsZWN0IHRoYXQuDQo+ IA0KPiAtLSANCj4gQ29saW4gUGVya2lucw0KPiBodHRwOi8vY3NwZXJraW5zLm9yZy8NCj4gDQo+ IA0KPiANCj4gIA0K --Apple-Mail-ED3D013D-28F2-4158-B402-2B8652CA5B19 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+WW91J3Jl IHJpZ2h0IHRoYXQgdGhlcmUgaXMgZmxleGliaWxpdHkgaW4gZW5oYW5jZW1lbnQgbGF5ZXJzLiBC dXQgYmVjYXVzZSBvZiB0aGUgbGF5ZXJpbmcgc3RydWN0dXJlLCB0aGUgYmFzZSBpcyBub3QgZmxl eGlibGUgLSBzaW5jZSB0aGUgZW5oYW5jZW1lbnQgbGF5ZXJzIGRlcGVuZCBvbiBpdCwgaXQgaXMg dHlwaWNhbGx5IHByb3RlY3RlZCB2aWEgRkVDIG9yIFJUWC4gVGhpcyBhZmZlY3RzIHRoZSB2aWFi aWxpdHkgb2YgInNsb3cgc3RhcnQiIHNjaGVtZXMgYXMgd2VsbCBvdGhlciBhc3BlY3RzIC0gbm8g cG9pbnQgc2VuZGluZyB2aWRlbyBhdCBhbGwgaWYgeW91IGNhbm5vdCBzdXBwb3J0IHRoZSBiYXNl IGxheWVyLCBhdCBsZWFzdC48L2Rpdj48ZGl2Pjxicj5PbiBPY3QgMjgsIDIwMTMsIGF0IDM6MTAg UE0sICJNbyBaYW5hdHkgKG16YW5hdHkpIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm16YW5hdHlAY2lz Y28uY29tIj5temFuYXR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1U eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9V2luZG93cy0xMjUyIj4NCg0KDQo8ZGl2 PlRoaXMgaXMgdHJ1ZSBmb3Igc2ltdWxjYXN0IGxheWVycywgYnV0IG5vdCBuZWNlc3NhcmlseSBz Y2FsYWJsZSBsYXllcnMuIEZvciB0aGUgbGF0dGVyLCBhcmJpdHJhcnkgcmF0ZXMgY2FuIGJlIGFj aGlldmVkIHdpdGhpbiBhIGxpbWl0ZWQgcmFuZ2UgKGxpa2UgZG93biB0byBoYWxmIHRoZSBiaXRy YXRlKSBieSBzZWxlY3RpdmVseSBkcm9wcGluZyBzb21lIHBhY2tldHMgb2YgdGhlIGhpZ2hlc3Qg ZW5oYW5jZW1lbnQgbGF5ZXIgd2l0aCBtaW5pbWFsDQogdmlzdWFsIHF1YWxpdHkgaW1wYWN0LiBJ ZiB0aGUgc3RyZWFtIGlzIGhpZ2hseSBzY2FsYWJsZSAobWFueSBsYXllcnMsIHdoaWNoIGlzIHJh cmUpLCB0aGUgbGltaXRlZCByYW5nZSBleHBhbmRzIChsaWtlIGRvd24gdG8gbWF5YmUgYSB0aGly ZCwgcXVhcnRlciwgb3IgbGVzcyBvZiB0aGUgYml0cmF0ZSkuIElmIHRoZSBzdHJlYW0gaXMgY29h cnNlbHkgc2NhbGFibGUgKGUuZy4gdHdvIGxheWVycywgd2hpY2ggaXMgY29tbW9uKSwgZHJvcHBp bmcgYmVsb3cNCiB0aGUgbGltaXRlZCByYW5nZSBpbmN1cnMgY2hhbmdpbmcgZW5jb2RpbmcgcGFy YW1ldGVycywgYXQgd2hpY2ggcG9pbnQgYXJiaXRyYXJ5IHJhdGVzIGFyZSBhZ2FpbiBwb3NzaWJs ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk1vPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8ZGl2Pg0KPGRpdj5PbiAxMC8yOC8xMywgNTo1OCBQTSwgQmVybmFyZCBBYm9iYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb20iPmJlcm5hcmRfYWJvYmFAaG90 bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29m dCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmlu aXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBh bm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD YWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkNvbGluIHNhaWQ6DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij7igJw8L3NwYW4+RG8geW91 IG1lYW4gcHJlcGFyaW5nIHRoZSBzYW1lIHZpZGVvIHNlcXVlbmNlIGF0IG11bHRpcGxlIHJhdGVz IGFuZCB0aGU8YnI+DQpjb25nZXN0aW9uIGNvbnRyb2xsZXIgcGlja2luZyB0aGUgYXBwcm9wcmlh dGUgbWVkaWEgcmF0ZSB0aGF0IGZpdHMgaXRzPGJyPg0KZXN0aW1hdGU/IGllIHJhdGUgc3dpdGNo IGJldHdlZW4gZGlmZmVyZW50IG1lZGlhIHJhdGVzIG9mIHRoZSBzYW1lPGJyPg0Kc2VxdWVuY2U/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7Ij7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij5bQkFdIEkgbGlrZSB0aGlzIGFwcHJvYWNoLCBiZWNhdXNlIGl0IHNvbWV3aGF0IGFw cHJveGltYXRlcyB0aGUgc2l0dWF0aW9uIG9mIHNpbXVsY2FzdC9sYXllcmVkIGNvZGluZy4mbmJz cDsgUHJldmlvdXMgd29yayBoYXMgaW5kaWNhdGVkIGEgbnVtYmVyIG9mIGNvbnNpZGVyYXRpb25z DQogdGhhdCBhcmlzZSBpbiB0aG9zZSBpbXBsZW1lbnRhdGlvbnMgKHN1Y2ggYXMgdGhlIG5lZWQg Zm9yIHJhcGlkIHJhbXB1cCwgc28gYXMgdG8gYmUgYWJsZSB0byBzZW5kIGF0IGxlYXN0IG9uZSB2 aWRlbyBzdHJlYW0gYXMgd2VsbCBhcyBpc3N1ZXMgd2l0aCBURlJGQykgdGhhdCB3b3VsZCBiZSBs aWtlbHkgdG8gYmUgbWlzc2VkIGluIGEgbW9kZWwgaW4gd2hpY2ggYW4gZW5jb2RlciBoYXMgZnVs bHkgc21vb3RoIHJhdGUgY29udHJvbC4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGFncmVlIHdpdGggQ29saW4uIFdlIHNob3VsZCBi ZSBmb2N1c2VkIG9uIGxpdmUgZW5jb2Rpbmcgd2hlcmUgdGhlPGJyPg0KZW5jb2RlciByYXRlIGNv bnRyb2wgaXMgaGlnaGx5IGdyYW51bGFyIChvZnRlbiBmdWxseSBzbW9vdGgpIGFuZCBjb3VwbGVk PGJyPg0KdG8gdGhlIG5ldHdvcmsgY29uZ2VzdGlvbiBjb250cm9sLCBub3QgcHJlLWVuY29kZWQg c3RyZWFtaW5nIG9mIGEgc21hbGw8YnI+DQpzZXQgb2YgZml4ZWQgYml0cmF0ZXMgbGlrZSBEQVNI L0hMUy48YnI+DQo8YnI+DQpBIG1vcmUgZm9ybWFsIGFwcHJvYWNoIHRvIHRoZSBwcm9ibGVtIHdv dWxkIGJlIHRvIGRlY29tcG9zZSB0aGUgZmFjdG9yczxicj4NCmNvbnRyaWJ1dGluZyB0byB0aGUg ZmluYWwgcmF0ZSBwbGFjZWQgb250byB0aGUgbmV0d29yay48YnI+DQoxLiBWaWRlbyBjb250ZW50 IC8gc291cmNlIHN0YXRpc3RpY3MsIHVzaW5nIGEgbGFyZ2Ugc2V0IG9mIHJlcHJlc2VudGF0aXZl PGJyPg0Kc2VxdWVuY2VzLiBBbiBlc3RpbWF0ZSBvZiB0aGUgZW50cm9weSBwZXIgZnJhbWUgY291 bGQgc2ltcGx5IGJlIHRoZTxicj4NCmVuY29kZWQgZnJhbWUgc2l6ZSB1c2luZyBjb25zdGFudCBx dWFudGl6YXRpb24sIGkuZS4gbm8gZW5jb2RlciByYXRlPGJyPg0KY29udHJvbC48YnI+DQoyLiBW aWRlbyBlbmNvZGVyIHJhdGUgY29udHJvbCBiZWhhdmlvciwgd2hpY2ggbW9kdWxhdGVzIHRoZSBz b3VyY2U8YnI+DQpzdGF0aXN0aWNzIHRvIGZpdCBpbnRvIG5ldHdvcmsgY29uc3RyYWludHMgb3Zl ciByYXRoZXIgbGFyZ2UgdGltZTxicj4NCmludGVydmFscyAoJmd0OzAuNXMpLjxicj4NCjMuIE5l dHdvcmsgdHJhbnNtaXNzaW9uIHBhY2luZyAvIHNoYXBlciwgd2hpY2ggc21vb3RocyBvdXQgYnVy c3RzIGluPGJyPg0KZW5jb2RlciBvdXRwdXQgdG8gZml0IGludG8gbmV0d29yayBjb25zdHJhaW50 cyBvdmVyIGZpbmUgdGltZSBpbnRlcnZhbHM8YnI+DQooJmx0OzAuNXMpLjxicj4NCjxicj4NCkl0 IHNob3VsZCBiZSBwb3NzaWJsZSB0byBtb2RlbCBhbGwgdGhyZWUgaW4gYW4gYWJzdHJhY3Qgd2F5 IHRvIGFycml2ZSBhdDxicj4NCnNvbWUgc3RhdGlzdGljYWwgbW9kZWwgdGhhdCBjYW4gdGhlbiBi ZSB1c2VkIGZvciBhbGwgdGVzdHMgd2l0aG91dCBhbnk8YnI+DQpyZWFsIHZpZGVvIGNvbnRlbnQg b3IgZW5jb2RpbmcgKHRvIGF2b2lkIGludHJvZHVjaW5nIG5vaXNlIGluIGNvbXBhcmlzb25zPGJy Pg0KaWYgdGhlcmUgd2FzIGFueSB2YXJpYWJpbGl0eSBpbiBhbnkgb2YgdGhlIGZhY3RvcnMpLjxi cj4NCjxicj4NCk1vPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMTAvMjgvMTMsIDE6NDkgUE0s IENvbGluIFBlcmtpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpjc3BAY3NwZXJraW5zLm9yZyI+Y3Nw QGNzcGVya2lucy5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQpPbiAyNyBPY3QgMjAxMywg YXQgMTE6NTAsIE1pY2hhZWwgV2VsemwgJmx0OzxhIGhyZWY9Im1haWx0bzptaWNoYXdlQGlmaS51 aW8ubm8iPm1pY2hhd2VAaWZpLnVpby5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiAyNy4g b2t0LiAyMDEzLCBhdCAxMjozMywgVmFydW4gU2luZ2ggJmx0OzxhIGhyZWY9Im1haWx0bzp2c2lu Z2guaWV0ZkBnbWFpbC5jb20iPnZzaW5naC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3csIG5leHQsIHdoYXQgaWYg d2UnZCBoYXZlIGEgc2V0IG9mIHN1Y2ggc2VxdWVuY2VzLCBhbmQgdGhlbiBzdGFjazxicj4NCnRo ZW0gb3ZlciBhIGNvZGVjIHRoYXQgcHJvZHVjZXMgcXVpdGUgYXJiaXRyYXJ5IGJpdHJhdGVzLCBh c3N1bWluZyB0aGF0PGJyPg0KdGhlIG5ldHdvcmsgY2FuIGFsd2F5cyBmb2xsb3cgaXQgLTxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KRG8g eW91IG1lYW4gcHJlcGFyaW5nIHRoZSBzYW1lIHZpZGVvIHNlcXVlbmNlIGF0IG11bHRpcGxlIHJh dGVzIGFuZCB0aGU8YnI+DQpjb25nZXN0aW9uIGNvbnRyb2xsZXIgcGlja2luZyB0aGUgYXBwcm9w cmlhdGUgbWVkaWEgcmF0ZSB0aGF0IGZpdHMgaXRzPGJyPg0KZXN0aW1hdGU/IGllIHJhdGUgc3dp dGNoIGJldHdlZW4gZGlmZmVyZW50IG1lZGlhIHJhdGVzIG9mIHRoZSBzYW1lPGJyPg0Kc2VxdWVu Y2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIHRoaW5rIHRo YXQgY291bGQgYmUgYSB2ZXJ5IGdvb2QgaWRlYSE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KSSdkIGJlIG1vcmUg aW50ZXJlc3RlZCBpbiBhIHN0YW5kYXJkIHNldCBvZiAqdW5jb21wcmVzc2VkKiB2aWRlbyB0ZXN0 PGJyPg0Kc2VxdWVuY2VzLCB0aGF0IHdlIGNhbiB1c2UgdG8gdGVzdCB0aGUgY29tYmluYXRpb24g b2YgdmlkZW8gY29kZWMgYW5kPGJyPg0KY29uZ2VzdGlvbiBjb250cm9sLiBJZiB3ZSdyZSBidWls ZGluZyBzb21ldGhpbmcgZm9yIGludGVyYWN0aXZlIHZpZGVvPGJyPg0KY29uZ2VzdGlvbiBjb250 cm9sIHdlIHNob3VsZCBhc3N1bWUgbGl2ZSBlbmNvZGluZywgd2l0aCB0aGUgY29kZWM8YnI+DQpw b3RlbnRpYWxseSBoYXZpbmcgdGhlIGZsZXhpYmlsaXR5IHRvIHJlYWN0IHRvIHRoZSBuZXR3b3Jr LCBhbmQgb3VyPGJyPg0KdGVzdGJlZCBvdWdodCB0byByZWZsZWN0IHRoYXQuPGJyPg0KPGJyPg0K LS0gPGJyPg0KQ29saW4gUGVya2luczxicj4NCjxhIGhyZWY9Imh0dHA6Ly9jc3BlcmtpbnMub3Jn LyI+aHR0cDovL2NzcGVya2lucy5vcmcvPC9hPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KDQoNCjwvZGl2PjwvYmxv Y2txdW90ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-ED3D013D-28F2-4158-B402-2B8652CA5B19-- From mzanaty@cisco.com Mon Oct 28 17:54:04 2013 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 4597111E81CB for ; Mon, 28 Oct 2013 17:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSlTTzhXjYtC for ; Mon, 28 Oct 2013 17:53:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 069DC11E810A for ; Mon, 28 Oct 2013 17:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13733; q=dns/txt; s=iport; t=1383008034; x=1384217634; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Rk13lMhi90UQy8Dup1ekiLHFRCQOaZnvUV3OrTUquS8=; b=dWTinGD7MlXqAy+9c3U/SzwAF9dZVpAwJ7pJpAgVvtRjnv8bdDxusPko GspeKBgK9H9Xa3ITqHZWEZfTEyU18SWd/wNYzsLeUDjt7BajCAL92awZk Hde5Du3fQ/Wol65zV6naCslYE5akx/qS8s6AJXOajLRXFOuvZOXtSDoKW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMHAMUFb1KtJV2a/2dsb2JhbABZgkNEOFSsBTKJZohMgSoWdIInAQQtTBIBCCIdKBEUEQIEDgUIh20DD65rDYlrjGWBMYEOMQcJgxaBDQOWHwGDGYshhTeBaIE+gWhC X-IronPort-AV: E=Sophos;i="4.93,589,1378857600"; d="scan'208,217";a="277803826" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 29 Oct 2013 00:53:53 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9T0rrFW019103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 00:53:53 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 19:53:52 -0500 From: "Mo Zanaty (mzanaty)" To: Bernard Aboba Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1EFWgwVs6QKB+UiBda2MQkwFlQ== Date: Tue, 29 Oct 2013 00:53:52 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.233.187] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91E124D97xmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "Van Der Auwera, Geert" , Michael Welzl , rmcat WG , "Xiaoqing Zhu \(xiaoqzhu\)" , Colin Perkins , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 00:54:04 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91E124D97xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agreed. The base layer has no flexibility just like a flat non-scalable str= eam. On 10/28/13, 7:45 PM, Bernard Aboba > wrote: You're right that there is flexibility in enhancement layers. But because o= f the layering structure, the base is not flexible - since the enhancement = layers depend on it, it is typically protected via FEC or RTX. This affects= the viability of "slow start" schemes as well other aspects - no point sen= ding video at all if you cannot support the base layer, at least. On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" > wrote: This is true for simulcast layers, but not necessarily scalable layers. For= the latter, arbitrary rates can be achieved within a limited range (like d= own to half the bitrate) by selectively dropping some packets of the highes= t enhancement layer with minimal visual quality impact. If the stream is hi= ghly scalable (many layers, which is rare), the limited range expands (like= down to maybe a third, quarter, or less of the bitrate). If the stream is = coarsely scalable (e.g. two layers, which is common), dropping below the li= mited range incurs changing encoding parameters, at which point arbitrary r= ates are again possible. Mo On 10/28/13, 5:58 PM, Bernard Aboba > wrote: Colin said: =93Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? =94 [BA] I like this approach, because it somewhat approximates the situation o= f simulcast/layered coding. Previous work has indicated a number of consid= erations that arise in those implementations (such as the need for rapid ra= mpup, so as to be able to send at least one video stream as well as issues = with TFRFC) that would be likely to be missed in a model in which an encode= r has fully smooth rate control. I agree with Colin. We should be focused on live encoding where the encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small set of fixed bitrates like DASH/HLS. A more formal approach to the problem would be to decompose the factors contributing to the final rate placed onto the network. 1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the encoded frame size using constant quantization, i.e. no encoder rate control. 2. Video encoder rate control behavior, which modulates the source statistics to fit into network constraints over rather large time intervals (>0.5s). 3. Network transmission pacing / shaper, which smooths out bursts in encoder output to fit into network constraints over fine time intervals (<0.5s). It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors). Mo On 10/28/13, 1:49 PM, Colin Perkins > wrote: On 27 Oct 2013, at 11:50, Michael Welzl > wrote: On 27. okt. 2013, at 12:33, Varun Singh > wrote: Now, next, what if we'd have a set of such sequences, and then stack them over a codec that produces quite arbitrary bitrates, assuming that the network can always follow it - Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that. -- Colin Perkins http://csperkins.org/ --_000_3879D71E758A7E4AA99A35DD8D41D3D91E124D97xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Agreed. The base layer has no flexibility just like a flat non-scalabl= e stream.


On 10/28/13, 7:45 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

You're right that there is flexibility in enhancement layers. But beca= use of the layering structure, the base is not flexible - since the enhance= ment layers depend on it, it is typically protected via FEC or RTX. This af= fects the viability of "slow start" schemes as well other aspects - no point sending video at all if you canno= t support the base layer, at least.

On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> wrote:

This is true for simulcast layers, but not necessarily scalable layers= . For the latter, arbitrary rates can be achieved within a limited range (l= ike down to half the bitrate) by selectively dropping some packets of the h= ighest enhancement layer with minimal visual quality impact. If the stream is highly scalable (many layers, whic= h is rare), the limited range expands (like down to maybe a third, quarter,= or less of the bitrate). If the stream is coarsely scalable (e.g. two laye= rs, which is common), dropping below the limited range incurs changing encoding parameters, at which point arbi= trary rates are again possible.

Mo


On 10/28/13, 5:58 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

Colin said:

 

=93Do you mean preparing the= same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?

=94

 

[BA] I like this approach, because = it somewhat approximates the situation of simulcast/layered coding.  P= revious work has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, so= as to be able to send at least one video stream as well as issues with TFR= FC) that would be likely to be missed in a model in which an encoder has fu= lly smooth rate control.   

 

I agree with Colin. W= e should be focused on live encoding where the
encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any
real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> wrote:

On 27. okt. 2013, at = 12:33, Varun Singh <vsingh.ietf= @gmail.com> wrote:

Now, next, what if we'd have a set of such sequences= , and then stack
them over a codec that produces quite arbitrary bitrates, assuming that
the network can always follow it -


Do you mean preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?


I think that could be a very good idea!


I'd be more interested in a standard set of *uncompressed* video test
sequences, that we can use to test the combination of video codec and
congestion control. If we're building something for interactive video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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


 

 --_000_3879D71E758A7E4AA99A35DD8D41D3D91E124D97xmbrcdx14ciscoc_-- From mzanaty@cisco.com Mon Oct 28 19:27:51 2013 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 F0A8F11E81CB for ; Mon, 28 Oct 2013 19:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI-VLgdyvT3Z for ; Mon, 28 Oct 2013 19:27:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 19BCC11E81EC for ; Mon, 28 Oct 2013 19:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9703; q=dns/txt; s=iport; t=1383013646; x=1384223246; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=tduB0Tf0CJMyTIPZbBm19O5B9qapK8bGOI94sxs3OYw=; b=UrNjcUg5ilq9zcdKMXs74fCmq8E9lyxDcAWh6p2f4XhOK/jdTNh4MXgo xjnkGyYGoUjXFO31+mzG7jf4FUFoYutyIHUCIiSjFiX80vLzzMpZxgOY+ ESVgKhc+uQXX8jn1peFK4AQ66Yd9FIr9ChFVod6sS8vFTBjkclqcJLktU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwGABccb1KtJXHB/2dsb2JhbABZgkNEOEgMrD+JZohMgSwWdIInAQR5EgEIIh0oERQRAgQOBQgBh2wDDw2uZg2Ja4xagjwxBwmDFoENA5YfgxqLIoU3gWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,589,1378857600"; d="scan'208,217";a="277806417" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2013 02:27:09 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9T2R9uP010381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 02:27:09 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 21:27:09 -0500 From: "Mo Zanaty (mzanaty)" To: "Xiaoqing Zhu (xiaoqzhu)" Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1A0MgwVs6QKB+UiBda2MQkwFlZoK4IGAgAAk4oA= Date: Tue, 29 Oct 2013 02:27:09 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91E124DFF@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.233.187] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91E124DFFxmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: rmcat WG , Colin Perkins , Michael Welzl , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 02:27:53 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91E124DFFxmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92m glad you removed rtcweb before recommending a reference codec! Seriously, we should wait on the rtcweb codec decision next week. And in the (likely) case of no decision, use both vp8 and x264. Mo On 10/28/13, 4:15 PM, Xiaoqing Zhu (xiaoqzhu) > wrote: Agree with Colin and Mo. For a statistical video traffic model, I would propose to break down the 2n= d point (encoder rate control) in Mo's list further, to three sub-component= s: a) delayed response to a rate change request (e.g., > 0.5s) b) deviations from the requested rate (maybe as randomly fluctuating around= the target?) c) the different frame types or coding modes inside the encoder will yield = some encoded frames much larger than others. This will lead to burstiness on time scale = of frame intervals (typically 33ms), and later smoothed out by the pacing/shaper. Also, if we go for the approach of using uncompressed test video sequence f= or testing the combination of video codec and congestion control, we should= also recommend a reference codec and default configurations. So that focus= of the evaluations remains on the congestion control module. What do folk= s think of x264 (http://www.videolan.org/developers/x264.html)? Best, Xiaoqing On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) > wrote: I agree with Colin. We should be focused on live encoding where the encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small set of fixed bitrates like DASH/HLS. A more formal approach to the problem would be to decompose the factors contributing to the final rate placed onto the network. 1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the encoded frame size using constant quantization, i.e. no encoder rate control. 2. Video encoder rate control behavior, which modulates the source statistics to fit into network constraints over rather large time intervals (>0.5s). 3. Network transmission pacing / shaper, which smooths out bursts in encoder output to fit into network constraints over fine time intervals (<0.5s). It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors). Mo On 10/28/13, 1:49 PM, Colin Perkins > wrote: On 27 Oct 2013, at 11:50, Michael Welzl > wrote: On 27. okt. 2013, at 12:33, Varun Singh > wrote: Now, next, what if we'd have a set of such sequences, and then stack them over a codec that produces quite arbitrary bitrates, assuming that the network can always follow it - Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that. -- Colin Perkins http://csperkins.org/ --_000_3879D71E758A7E4AA99A35DD8D41D3D91E124DFFxmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I=92m glad you removed rtcweb before recommending a reference codec!
Seriously, we should wait on the rtcweb codec decision next week.
And in the (likely) case of no decision, use both vp8 and x264.

Mo


On 10/28/13, 4:15 PM, Xiaoqing Zhu (xiaoqzhu) <xiaoqzhu@cisco.com> wrote:

Agree with Colin and Mo. 

For a statistical video traffic model, I would propose to break down t= he 2nd point (encoder rate control) in Mo's list further, to three sub-comp= onents:

a) delayed response to a rate change request (e.g., > 0.5s)
b) deviations from the requested rate (maybe as randomly fluctuating a= round the target?) 
c) the different frame types or coding modes inside the encoder will y= ield some encoded
frames much larger than others. This will lead to burstiness on time s= cale of frame intervals
(typically 33ms), and later smoothed out by the pacing/shaper. 

Also, if we go for the approach of using uncompressed test video seque= nce for testing the combination of video codec and congestion control,= we should also recommend a reference codec and default configurations= . So that focus of the evaluations remains on the congestion control module.  What do folks think of x264 (http://www.videolan.org= /developers/x264.html)? 

Best,
Xiaoqing

 

On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

I agree with Colin. We should be focused on live = encoding where the
encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any
real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> wrote:
On 27. okt. 2013, at 12:33, Varun Singh <vsingh.ietf@gmail.com> wrote:
Now, next, what if we'd have a set of such sequen= ces, and then stack
them over a codec that produces quite arbitrary bitrates, assuming that
the network can always follow it -

Do you mean preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?

I think that could be a very good idea!

I'd be more interested in a standard set of *uncompressed* video test
sequences, that we can use to test the combination of video codec and
congestion control. If we're building something for interactive video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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





--_000_3879D71E758A7E4AA99A35DD8D41D3D91E124DFFxmbrcdx14ciscoc_-- From bernard_aboba@hotmail.com Mon Oct 28 21:03:39 2013 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 5235B11E820B for ; Mon, 28 Oct 2013 21:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgS+e5vDHaif for ; Mon, 28 Oct 2013 21:03:34 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by ietfa.amsl.com (Postfix) with ESMTP id 2E70311E80DC for ; Mon, 28 Oct 2013 21:03:34 -0700 (PDT) Received: from BLU169-W19 ([65.55.111.72]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Oct 2013 21:03:33 -0700 X-TMN: [mk+Lp6KN/RJoVFXHvtLlpbXWdNwS6rDi] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_9dd126b3-828b-422a-8920-f2d9be9793bd_" From: Bernard Aboba To: "Mo Zanaty (mzanaty)" , "Xiaoqing Zhu (xiaoqzhu)" Date: Mon, 28 Oct 2013 21:03:32 -0700 Importance: Normal In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91E124DFF@xmb-rcd-x14.cisco.com> References: , <3879D71E758A7E4AA99A35DD8D41D3D91E124DFF@xmb-rcd-x14.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 29 Oct 2013 04:03:33.0881 (UTC) FILETIME=[D6100690:01CED45B] Cc: rmcat WG , Colin Perkins , Michael Welzl , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 04:03:39 -0000 --_9dd126b3-828b-422a-8920-f2d9be9793bd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Heh=2C good point about removing RTCWEB. No need to start a riot :) But now that we've removed them=2C we can speak frankly... the VP8 vs. H.26= 4 battle is "so 2012". The industry has moved on to VP9 and H.265=2C both= of which are likely to be deployed in mixed spatial simulcast/temporal SVC= modes.=20 So while it's certainly convenient to experiment with VP8 and H.264 because= the tools are available... we should be thinking about the future because= =2C as they say in Plan 9 "that is where we expect to spend the rest of our= lives."=20 From: mzanaty@cisco.com To: xiaoqzhu@cisco.com Date: Tue=2C 29 Oct 2013 02:27:09 +0000 CC: rmcat@ietf.org=3B csp@csperkins.org=3B michawe@ifi.uio.no=3B vsingh.iet= f@gmail.com Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouve= r (03 Nov=2C 1300-1500) =0A= =0A= =0A= =0A= =0A= I=92m glad you removed rtcweb before recommending a reference codec!=0A= Seriously=2C we should wait on the rtcweb codec decision next week.=0A= And in the (likely) case of no decision=2C use both vp8 and x264.=0A= =0A= =0A= Mo=0A= =0A= =0A= =0A= =0A= =0A= =0A= On 10/28/13=2C 4:15 PM=2C Xiaoqing Zhu (xiaoqzhu) wrot= e:=0A= =0A= =0A= =0A= =0A= =0A= Agree with Colin and Mo. =0A= =0A= =0A= For a statistical video traffic model=2C I would propose to break down the = 2nd point (encoder rate control) in Mo's list further=2C to three sub-compo= nents:=0A= =0A= =0A= =0A= =0A= a) delayed response to a rate change request (e.g.=2C > 0.5s)=0A= b) deviations from the requested rate (maybe as randomly fluctuating around= the target?) =0A= c) the different frame types or coding modes inside the encoder will yield = some encoded=0A= frames much larger than others. This will lead to burstiness on time scale = of frame intervals=0A= (typically 33ms)=2C and later smoothed out by the pacing/shaper. =0A= =0A= =0A= Also=2C if we go for the approach of using uncompressed test video sequence= for testing the combination of video codec and congestion control=2C we sh= ould also recommend a reference codec and default configurations. So that f= ocus of the evaluations remains=0A= on the congestion control module. What do folks think of x264 (http://www= .videolan.org/developers/x264.html)? =0A= =0A= =0A= Best=2C=0A= Xiaoqing=0A= =0A= =0A= =0A= =0A= =0A= On Oct 28=2C 2013=2C at 1:39 PM=2C Mo Zanaty (mzanaty) = wrote:=0A= =0A= I agree with Colin. We should be focused on live encoding where the =0A= encoder rate control is highly granular (often fully smooth) and coupled =0A= to the network congestion control=2C not pre-encoded streaming of a small =0A= set of fixed bitrates like DASH/HLS. =0A= =0A= A more formal approach to the problem would be to decompose the factors =0A= contributing to the final rate placed onto the network. =0A= 1. Video content / source statistics=2C using a large set of representative =0A= sequences. An estimate of the entropy per frame could simply be the =0A= encoded frame size using constant quantization=2C i.e. no encoder rate =0A= control. =0A= 2. Video encoder rate control behavior=2C which modulates the source =0A= statistics to fit into network constraints over rather large time =0A= intervals (>0.5s). =0A= 3. Network transmission pacing / shaper=2C which smooths out bursts in =0A= encoder output to fit into network constraints over fine time intervals =0A= (<0.5s). =0A= =0A= It should be possible to model all three in an abstract way to arrive at =0A= some statistical model that can then be used for all tests without any =0A= real video content or encoding (to avoid introducing noise in comparisons =0A= if there was any variability in any of the factors). =0A= =0A= Mo =0A= =0A= =0A= =0A= On 10/28/13=2C 1:49 PM=2C Colin Perkins wrote: =0A= =0A= On 27 Oct 2013=2C at 11:50=2C Michael Welzl wrote: =0A= On 27. okt. 2013=2C at 12:33=2C Varun Singh wrote: =0A= =0A= Now=2C next=2C what if we'd have a set of such sequences=2C and then stack =0A= them over a codec that produces quite arbitrary bitrates=2C assuming that =0A= the network can always follow it - =0A= =0A= =0A= Do you mean preparing the same video sequence at multiple rates and the =0A= congestion controller picking the appropriate media rate that fits its =0A= estimate? ie rate switch between different media rates of the same =0A= sequence? =0A= =0A= =0A= I think that could be a very good idea! =0A= =0A= =0A= I'd be more interested in a standard set of *uncompressed* video test =0A= sequences=2C that we can use to test the combination of video codec and =0A= congestion control. If we're building something for interactive video =0A= congestion control we should assume live encoding=2C with the codec =0A= potentially having the flexibility to react to the network=2C and our =0A= testbed ought to reflect that. =0A= =0A= --=20 =0A= Colin Perkins =0A= http://csperkins.org/ =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= = --_9dd126b3-828b-422a-8920-f2d9be9793bd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Heh=2C good point about removing= RTCWEB.  =3BNo need to start a riot :)

But now that= we've removed them=2C we can speak frankly... the VP8 vs. H.264 battle is = "so 2012".  =3B The industry has moved on to VP9 and H.265=2C both of w= hich are likely to be deployed in mixed spatial simulcast/temporal SVC mode= s. =3B

So while it's certainly convenient to e= xperiment with VP8 and H.264 because the tools are available... we should b= e thinking about the future because=2C as they say in Plan 9 "that is where= we expect to spend the rest of our lives." =3B

From: mzanaty@cisco.com
To: xiaoqzhu@cisco.com
Date: Tue= =2C 29 Oct 2013 02:27:09 +0000
CC: rmcat@ietf.org=3B csp@csperkins.org= =3B michawe@ifi.uio.no=3B vsingh.ietf@gmail.com
Subject: Re: [rmcat] [rt= cweb] Discussion on RMCAT traffic model in Vancouver (03 Nov=2C 1300-1500)<= br>
=0A= =0A= =0A= =0A= =0A=
I=92m glad you removed rtcweb before recommending a reference codec!=0A=
Seriously=2C we should wait on the rtcweb codec decision next week.=0A=
And in the (likely) case of no decision=2C use both vp8 and x264.=0A=

=0A=
=0A=
Mo
=0A=

=0A=
=0A=

=0A=
=0A= =0A=
=0A=
On 10/28/13=2C 4:15 PM=2C Xiaoqing Zhu (xiaoqzhu) <=3Bxiaoqzhu@cisco.com>=3B wrote:
=0A=
=0A=

=0A=
=0A=
=0A=
=0A= Agree with Colin and Mo. =3B=0A=

=0A=
=0A=
For a statistical video traffic model=2C I would propose to break down= the 2nd point (encoder rate control) in Mo's list further=2C to three sub-= components:
=0A=

=0A=
=0A=
=0A=
=0A=
a) delayed response to a rate change request (e.g.=2C >=3B 0.5s)=0A=
b) deviations from the requested rate (maybe as randomly fluctuating a= round the target?) =3B
=0A=
c) the different frame types or coding modes inside the encoder will y= ield some encoded
=0A=
frames much larger than others. This will lead to burstiness on time s= cale of frame intervals
=0A=
(typically 33ms)=2C and later smoothed out by the pacing/shaper. = =3B
=0A=

=0A=
=0A=
Also=2C if we go for the approach of using uncompressed test video seq= uence for testing the =3Bcombination of video codec and congestion cont= rol=2C we should also recommend a reference =3Bcodec and default config= urations. So that focus of the evaluations remains=0A= on the congestion control module.  =3BWhat do folks think of x264 (htt= p://www.videolan.org/developers/x264.html)? =3B
=0A=

=0A=
=0A=
Best=2C
=0A=
Xiaoqing
=0A=

=0A=
=0A=
 =3B
=0A=

=0A=
=0A=
On Oct 28=2C 2013=2C at 1:39 PM=2C Mo Zanaty (mzanaty) <=3Bmzanaty@cisco.com>=3B wrote:
=0A=
=0A=
I agree with Colin. We should be focused on live encoding where= the
=0A= encoder rate control is highly granular (often fully smooth) and coupled=0A= to the network congestion control=2C not pre-encoded streaming of a small=0A= set of fixed bitrates like DASH/HLS.
=0A=
=0A= A more formal approach to the problem would be to decompose the factors
= =0A= contributing to the final rate placed onto the network.
=0A= 1. Video content / source statistics=2C using a large set of representative=
=0A= sequences. An estimate of the entropy per frame could simply be the
=0A= encoded frame size using constant quantization=2C i.e. no encoder rate
= =0A= control.
=0A= 2. Video encoder rate control behavior=2C which modulates the source
=0A= statistics to fit into network constraints over rather large time
=0A= intervals (>=3B0.5s).
=0A= 3. Network transmission pacing / shaper=2C which smooths out bursts in
= =0A= encoder output to fit into network constraints over fine time intervals
= =0A= (<=3B0.5s).
=0A=
=0A= It should be possible to model all three in an abstract way to arrive at=0A= some statistical model that can then be used for all tests without any
= =0A= real video content or encoding (to avoid introducing noise in comparisons=0A= if there was any variability in any of the factors).
=0A=
=0A= Mo
=0A=
=0A=
=0A=
=0A= On 10/28/13=2C 1:49 PM=2C Colin Perkins <=3Bcsp@csperkins.org>=3B wrote:
=0A=
=0A= On 27 Oct 2013=2C at 11:50=2C Michael Welzl <=3Bmichawe@ifi.uio.no>=3B wrote:
=0A=
On 27. okt. 2013=2C at 12:33=2C Varun Singh <=3Bvsingh.ietf@gmail.com>=3B wrote:
=0A=
=0A=
Now=2C next=2C what if we'd have a set of such sequences=2C and= then stack
=0A= them over a codec that produces quite arbitrary bitrates=2C assuming that=0A= the network can always follow it -
=0A=
=0A=
=0A= Do you mean preparing the same video sequence at multiple rates and the
= =0A= congestion controller picking the appropriate media rate that fits its
= =0A= estimate? ie rate switch between different media rates of the same
=0A= sequence?
=0A=
=0A=
=0A= I think that could be a very good idea!
=0A=
=0A=
=0A= I'd be more interested in a standard set of *uncompressed* video test
= =0A= sequences=2C that we can use to test the combination of video codec and
= =0A= congestion control. If we're building something for interactive video
= =0A= congestion control we should assume live encoding=2C with the codec
=0A= potentially having the flexibility to react to the network=2C and our
= =0A= testbed ought to reflect that.
=0A=
=0A= --
=0A= Colin Perkins
=0A= http://csperkins.org/
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
= --_9dd126b3-828b-422a-8920-f2d9be9793bd_-- From michawe@ifi.uio.no Tue Oct 29 01:30:52 2013 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 6198121E80F1 for ; Tue, 29 Oct 2013 01:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAu-1BFBfiRg for ; Tue, 29 Oct 2013 01:30:47 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF2C21E80EA for ; Tue, 29 Oct 2013 01:30:46 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Vb4hF-0007R4-95; Tue, 29 Oct 2013 09:30:41 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1Vb4hD-0001aL-Vm; Tue, 29 Oct 2013 09:30:41 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_31B372BB-3F05-4017-8313-FA700A142FCF" From: Michael Welzl In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> Date: Tue, 29 Oct 2013 09:30:38 +0100 Message-Id: <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> To: Mo Zanaty (mzanaty) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 8 sum msgs/h 1 total rcpts 9062 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.052, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1920B9ADA3180CCB68D5E056F4C19876A82264F2 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3519 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: "Van Der Auwera, Geert" , Bernard Aboba , rmcat WG , "Xiaoqing Zhu \(xiaoqzhu\)" , Colin Perkins , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 08:30:52 -0000 --Apple-Mail=_31B372BB-3F05-4017-8313-FA700A142FCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 So - looking at this thread, it seems that consensus is against me :-) Hence I'd like to clarify - my concern was that we're making the system = too complex by involving a codec that reacts to the congestion = controller **when evaluating congestion control mechanisms**. I mean, = once I've done a test, I'd like to know why I see the effects that I = see, and which mechanism is to blame for them. This will get harder with = this setup. Let me give an example to explain my concern: Say, we create a test with a reactive codec over a congestion = controller, and in some network scenarios, we see oscillations: the = congestion controller increased its rate, allowing the codec to switch = to a higher encoding rate; this higher rate was too much, and so quite = fast the congestion controller reduces its rate again, hence the codec = reacts and switches to a lower rate, and so forth. Now, if that is the test setup for evaluating a congestion controller, a = conclusion from such a test could be that the congestion controller has = to be stabilized. I would, however, argue that a congestion controller = should be as quick as it possibly can at seeking out available = bandwidth, and hence such fluctuations are natural (*), and it's rather = the job of the codec to dampen its rate switching. Either way, in this example test, we face a bad result, and two screws = to tune to fix the problem - one on the side of the congestion control, = and one on the side of the codec. This is why I would prefer to evaluate congestion controls (again, not = the whole system, to me that's a different evaluation, and of course a = better congestion control should lead to a better total system) with a = static traffic profile. Is my concern unfounded? Is it a non-problem I'm envisioning? (if so, = see below for 2 more concerns :-) ) Cheers, Michael PS: Concern #2: we can expect a static traffic profile feeding into a = congestion controller to be relatively quickly done, but creating a test = setup with a reactive codec is going to be much harder and take more = time. Will we ever see it? When? Will it be easy to use? PPS: Concern #3: the parameter space for tests might expand quite = significantly when we involve reactive codecs... this will make any = evaluation harder, making the results harder to compare, resulting in = more time necessary to come to a conclusion about which controller does = a better job. (*) TFRC is an argument to the contrary, but I haven't seen a single = evaluation result that shows that its smooth rate is indeed beneficial. = On the contrary, we now seem to have some agreement that TFRC isn't the = best mechanism. On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) wrote: > Agreed. The base layer has no flexibility just like a flat = non-scalable stream. >=20 >=20 > On 10/28/13, 7:45 PM, Bernard Aboba wrote: >=20 > You're right that there is flexibility in enhancement layers. But = because of the layering structure, the base is not flexible - since the = enhancement layers depend on it, it is typically protected via FEC or = RTX. This affects the viability of "slow start" schemes as well other = aspects - no point sending video at all if you cannot support the base = layer, at least. >=20 > On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" = wrote: >=20 >> This is true for simulcast layers, but not necessarily scalable = layers. For the latter, arbitrary rates can be achieved within a limited = range (like down to half the bitrate) by selectively dropping some = packets of the highest enhancement layer with minimal visual quality = impact. If the stream is highly scalable (many layers, which is rare), = the limited range expands (like down to maybe a third, quarter, or less = of the bitrate). If the stream is coarsely scalable (e.g. two layers, = which is common), dropping below the limited range incurs changing = encoding parameters, at which point arbitrary rates are again possible. >>=20 >> Mo >>=20 >>=20 >> On 10/28/13, 5:58 PM, Bernard Aboba = wrote: >>=20 >> Colin said: >> =20 >> =93Do you mean preparing the same video sequence at multiple rates = and the >> congestion controller picking the appropriate media rate that fits = its >> estimate? ie rate switch between different media rates of the same >> sequence? >> =94 >> =20 >> [BA] I like this approach, because it somewhat approximates the = situation of simulcast/layered coding. Previous work has indicated a = number of considerations that arise in those implementations (such as = the need for rapid rampup, so as to be able to send at least one video = stream as well as issues with TFRFC) that would be likely to be missed = in a model in which an encoder has fully smooth rate control. =20 >> =20 >>=20 >> I agree with Colin. We should be focused on live encoding where the >> encoder rate control is highly granular (often fully smooth) and = coupled >> to the network congestion control, not pre-encoded streaming of a = small >> set of fixed bitrates like DASH/HLS. >>=20 >> A more formal approach to the problem would be to decompose the = factors >> contributing to the final rate placed onto the network. >> 1. Video content / source statistics, using a large set of = representative >> sequences. An estimate of the entropy per frame could simply be the >> encoded frame size using constant quantization, i.e. no encoder rate >> control. >> 2. Video encoder rate control behavior, which modulates the source >> statistics to fit into network constraints over rather large time >> intervals (>0.5s). >> 3. Network transmission pacing / shaper, which smooths out bursts in >> encoder output to fit into network constraints over fine time = intervals >> (<0.5s). >>=20 >> It should be possible to model all three in an abstract way to arrive = at >> some statistical model that can then be used for all tests without = any >> real video content or encoding (to avoid introducing noise in = comparisons >> if there was any variability in any of the factors). >>=20 >> Mo >>=20 >>=20 >>=20 >> On 10/28/13, 1:49 PM, Colin Perkins wrote: >>=20 >> On 27 Oct 2013, at 11:50, Michael Welzl wrote: >>=20 >> On 27. okt. 2013, at 12:33, Varun Singh = wrote: >>=20 >>> Now, next, what if we'd have a set of such sequences, and then stack >>> them over a codec that produces quite arbitrary bitrates, assuming = that >>> the network can always follow it - >>=20 >> Do you mean preparing the same video sequence at multiple rates and = the >> congestion controller picking the appropriate media rate that fits = its >> estimate? ie rate switch between different media rates of the same >> sequence? >>=20 >> I think that could be a very good idea! >>=20 >> I'd be more interested in a standard set of *uncompressed* video test >> sequences, that we can use to test the combination of video codec and >> congestion control. If we're building something for interactive video >> congestion control we should assume live encoding, with the codec >> potentially having the flexibility to react to the network, and our >> testbed ought to reflect that. >>=20 >> --=20 >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >> =20 --Apple-Mail=_31B372BB-3F05-4017-8313-FA700A142FCF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 So - = looking at this thread, it seems that consensus is against me =  :-)

Hence I'd like to clarify - my concern was = that we're making the system too complex by involving a codec that = reacts to the congestion controller **when evaluating congestion control = mechanisms**. I mean, once I've done a test, I'd like to know why I see = the effects that I see, and which mechanism is to blame for = them. This will get harder with this = setup.

Let me give an example to explain my = concern:

Say, we create a test with a reactive = codec over a congestion controller, and in some network scenarios, we = see oscillations: the congestion controller increased its rate, allowing = the codec to switch to a higher encoding rate; this higher rate was too = much, and so quite fast the congestion controller reduces its rate = again, hence the codec reacts and switches to a lower rate, and so = forth.

Now, if that is the test setup for = evaluating a congestion controller, a conclusion from such a test could = be that the congestion controller has to be stabilized. I would, = however, argue that a congestion controller should be as quick as = it possibly can at seeking out available bandwidth, and hence such = fluctuations are natural (*), and it's rather the job of the codec to = dampen its rate switching.

Either way, in this = example test, we face a bad result, and two screws to tune to fix the = problem - one on the side of the congestion control, and one on the side = of the codec.

This is why I would prefer to = evaluate congestion controls (again, not the whole system, to me that's = a different evaluation, and of course a better congestion control should = lead to a better total system) with a static traffic = profile.

Is my concern unfounded? Is it a = non-problem I'm envisioning?   (if so, see below for 2 more = concerns  :-)   = )

Cheers,
Michael

<= div>PS:  Concern #2: we can expect a static traffic = profile feeding into a congestion controller to be relatively quickly = done, but creating a test setup with a reactive codec is going to be = much harder and take more time. Will we ever see it? When? Will it be = easy to use?





Agreed. The base layer has no flexibility just like a flat = non-scalable stream.

You're right that there is flexibility in enhancement layers. But = because of the layering structure, the base is not flexible - since the = enhancement layers depend on it, it is typically protected via FEC or = RTX. This affects the viability of "slow start" schemes as well other aspects - no point sending video at all if you = cannot support the base layer, at least.

On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> wrote:

This is true for simulcast layers, but not necessarily scalable = layers. For the latter, arbitrary rates can be achieved within a limited = range (like down to half the bitrate) by selectively dropping some = packets of the highest enhancement layer with minimal visual quality impact. If the stream is highly scalable (many layers, = which is rare), the limited range expands (like down to maybe a third, = quarter, or less of the bitrate). If the stream is coarsely scalable = (e.g. two layers, which is common), dropping below the limited range incurs changing encoding parameters, at which point = arbitrary rates are again possible.

Mo


On 10/28/13, 5:58 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

Colin said:
 
=93Do you mean preparing the same video = sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits = its
estimate? ie rate switch between different media rates of the same
sequence?
=94
 
[BA] I like this approach, because it somewhat = approximates the situation of simulcast/layered coding.  Previous = work has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, = so as to be able to send at least one video stream as well as issues = with TFRFC) that would be likely to be missed in a model in which an = encoder has fully smooth rate control. =   

 

I agree with Colin. We should be focused = on live encoding where the
encoder rate control is highly granular (often fully smooth) and = coupled
to the network congestion control, not pre-encoded streaming of a = small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the = factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of = representative
sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time = intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive = at
some statistical model that can then be used for all tests without = any
real video content or encoding (to avoid introducing noise in = comparisons
if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> = wrote:

On 27. okt. 2013, at 12:33, Varun Singh = <vsingh.ietf@gmail.com>= wrote:

Now, next, what if we'd have a = set of such sequences, and then stack
them over a codec that produces quite arbitrary bitrates, assuming = that
the network can always follow it -

Do you mean preparing the same video sequence at multiple rates and = the
congestion controller picking the appropriate media rate that fits = its
estimate? ie rate switch between different media rates of the same
sequence?

I think that could be a very good idea!


I'd be more interested in a standard set of *uncompressed* video = test
sequences, that we can use to test the combination of video codec = and
congestion control. If we're building something for interactive = video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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


 

= --Apple-Mail=_31B372BB-3F05-4017-8313-FA700A142FCF-- From csp@csperkins.org Tue Oct 29 02:31:21 2013 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 1DEE311E8169 for ; Tue, 29 Oct 2013 02:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm0BNGzttvrJ for ; Tue, 29 Oct 2013 02:31:19 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id CB05721F9FF0 for ; Tue, 29 Oct 2013 02:31:10 -0700 (PDT) Received: from [81.187.2.149] (port=48025 helo=[192.168.0.14]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Vb5dj-0007PN-DU; Tue, 29 Oct 2013 09:31:09 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_6C900866-88D3-462C-8E23-AB949CEF3101" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> Date: Tue, 29 Oct 2013 09:31:06 +0000 Message-Id: <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rmcat WG Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 09:31:21 -0000 --Apple-Mail=_6C900866-88D3-462C-8E23-AB949CEF3101 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Michael, Your concern is why I think we need to test the codec and the congestion = control together. The dynamics of how, and importantly when, the codec = can change its rate will be critical to the dynamics of the congestion = control. This is especially true if we want to keep the latency low by = avoiding sender-side buffering to smooth the codec output to match the = desired sending rate. Testing congestion control without a codec will = give us something that doesn't respect the QoE concerns, and runs the = risk of producing an algorithm that is safe and responsive, but not = useful for interactive video. Colin On 29 Oct 2013, at 08:30, Michael Welzl wrote: > So - looking at this thread, it seems that consensus is against me = :-) >=20 > Hence I'd like to clarify - my concern was that we're making the = system too complex by involving a codec that reacts to the congestion = controller **when evaluating congestion control mechanisms**. I mean, = once I've done a test, I'd like to know why I see the effects that I = see, and which mechanism is to blame for them. This will get harder with = this setup. >=20 > Let me give an example to explain my concern: >=20 > Say, we create a test with a reactive codec over a congestion = controller, and in some network scenarios, we see oscillations: the = congestion controller increased its rate, allowing the codec to switch = to a higher encoding rate; this higher rate was too much, and so quite = fast the congestion controller reduces its rate again, hence the codec = reacts and switches to a lower rate, and so forth. >=20 > Now, if that is the test setup for evaluating a congestion controller, = a conclusion from such a test could be that the congestion controller = has to be stabilized. I would, however, argue that a congestion = controller should be as quick as it possibly can at seeking out = available bandwidth, and hence such fluctuations are natural (*), and = it's rather the job of the codec to dampen its rate switching. >=20 > Either way, in this example test, we face a bad result, and two screws = to tune to fix the problem - one on the side of the congestion control, = and one on the side of the codec. >=20 > This is why I would prefer to evaluate congestion controls (again, not = the whole system, to me that's a different evaluation, and of course a = better congestion control should lead to a better total system) with a = static traffic profile. >=20 > Is my concern unfounded? Is it a non-problem I'm envisioning? (if = so, see below for 2 more concerns :-) ) >=20 > Cheers, > Michael >=20 > PS: Concern #2: we can expect a static traffic profile feeding into a = congestion controller to be relatively quickly done, but creating a test = setup with a reactive codec is going to be much harder and take more = time. Will we ever see it? When? Will it be easy to use? > PPS: Concern #3: the parameter space for tests might expand quite = significantly when we involve reactive codecs... this will make any = evaluation harder, making the results harder to compare, resulting in = more time necessary to come to a conclusion about which controller does = a better job. >=20 >=20 > (*) TFRC is an argument to the contrary, but I haven't seen a single = evaluation result that shows that its smooth rate is indeed beneficial. = On the contrary, we now seem to have some agreement that TFRC isn't the = best mechanism. >=20 >=20 > On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) wrote: >=20 >> Agreed. The base layer has no flexibility just like a flat = non-scalable stream. >>=20 >>=20 >> On 10/28/13, 7:45 PM, Bernard Aboba = wrote: >>=20 >> You're right that there is flexibility in enhancement layers. But = because of the layering structure, the base is not flexible - since the = enhancement layers depend on it, it is typically protected via FEC or = RTX. This affects the viability of "slow start" schemes as well other = aspects - no point sending video at all if you cannot support the base = layer, at least. >>=20 >> On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" = wrote: >>=20 >>> This is true for simulcast layers, but not necessarily scalable = layers. For the latter, arbitrary rates can be achieved within a limited = range (like down to half the bitrate) by selectively dropping some = packets of the highest enhancement layer with minimal visual quality = impact. If the stream is highly scalable (many layers, which is rare), = the limited range expands (like down to maybe a third, quarter, or less = of the bitrate). If the stream is coarsely scalable (e.g. two layers, = which is common), dropping below the limited range incurs changing = encoding parameters, at which point arbitrary rates are again possible. >>>=20 >>> Mo >>>=20 >>>=20 >>> On 10/28/13, 5:58 PM, Bernard Aboba = wrote: >>>=20 >>> Colin said: >>> =20 >>> =93Do you mean preparing the same video sequence at multiple rates = and the >>> congestion controller picking the appropriate media rate that fits = its >>> estimate? ie rate switch between different media rates of the same >>> sequence? >>> =94 >>> =20 >>> [BA] I like this approach, because it somewhat approximates the = situation of simulcast/layered coding. Previous work has indicated a = number of considerations that arise in those implementations (such as = the need for rapid rampup, so as to be able to send at least one video = stream as well as issues with TFRFC) that would be likely to be missed = in a model in which an encoder has fully smooth rate control. =20 >>> =20 >>>=20 >>> I agree with Colin. We should be focused on live encoding where the >>> encoder rate control is highly granular (often fully smooth) and = coupled >>> to the network congestion control, not pre-encoded streaming of a = small >>> set of fixed bitrates like DASH/HLS. >>>=20 >>> A more formal approach to the problem would be to decompose the = factors >>> contributing to the final rate placed onto the network. >>> 1. Video content / source statistics, using a large set of = representative >>> sequences. An estimate of the entropy per frame could simply be the >>> encoded frame size using constant quantization, i.e. no encoder rate >>> control. >>> 2. Video encoder rate control behavior, which modulates the source >>> statistics to fit into network constraints over rather large time >>> intervals (>0.5s). >>> 3. Network transmission pacing / shaper, which smooths out bursts in >>> encoder output to fit into network constraints over fine time = intervals >>> (<0.5s). >>>=20 >>> It should be possible to model all three in an abstract way to = arrive at >>> some statistical model that can then be used for all tests without = any >>> real video content or encoding (to avoid introducing noise in = comparisons >>> if there was any variability in any of the factors). >>>=20 >>> Mo >>>=20 >>>=20 >>>=20 >>> On 10/28/13, 1:49 PM, Colin Perkins wrote: >>>=20 >>> On 27 Oct 2013, at 11:50, Michael Welzl wrote: >>>=20 >>> On 27. okt. 2013, at 12:33, Varun Singh = wrote: >>>=20 >>>> Now, next, what if we'd have a set of such sequences, and then = stack >>>> them over a codec that produces quite arbitrary bitrates, assuming = that >>>> the network can always follow it - >>>=20 >>> Do you mean preparing the same video sequence at multiple rates and = the >>> congestion controller picking the appropriate media rate that fits = its >>> estimate? ie rate switch between different media rates of the same >>> sequence? >>>=20 >>> I think that could be a very good idea! >>>=20 >>> I'd be more interested in a standard set of *uncompressed* video = test >>> sequences, that we can use to test the combination of video codec = and >>> congestion control. If we're building something for interactive = video >>> congestion control we should assume live encoding, with the codec >>> potentially having the flexibility to react to the network, and our >>> testbed ought to reflect that. >>>=20 >>> --=20 >>> Colin Perkins >>> http://csperkins.org/ >>>=20 --Apple-Mail=_6C900866-88D3-462C-8E23-AB949CEF3101 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 michawe@ifi.uio.no> = wrote:
So - looking at this thread, it seems that = consensus is against me  :-)

Hence I'd like to = clarify - my concern was that we're making the system too complex by = involving a codec that reacts to the congestion controller **when = evaluating congestion control mechanisms**. I mean, once I've done a = test, I'd like to know why I see the effects that I see, and which = mechanism is to blame for them. This will get harder with this = setup.

Let me give an example to explain my = concern:

Say, we create a test with a reactive = codec over a congestion controller, and in some network scenarios, we = see oscillations: the congestion controller increased its rate, allowing = the codec to switch to a higher encoding rate; this higher rate was too = much, and so quite fast the congestion controller reduces its rate = again, hence the codec reacts and switches to a lower rate, and so = forth.

Now, if that is the test setup for = evaluating a congestion controller, a conclusion from such a test could = be that the congestion controller has to be stabilized. I would, = however, argue that a congestion controller should be as quick as = it possibly can at seeking out available bandwidth, and hence such = fluctuations are natural (*), and it's rather the job of the codec to = dampen its rate switching.

Either way, in this = example test, we face a bad result, and two screws to tune to fix the = problem - one on the side of the congestion control, and one on the side = of the codec.

This is why I would prefer to = evaluate congestion controls (again, not the whole system, to me that's = a different evaluation, and of course a better congestion control should = lead to a better total system) with a static traffic = profile.

Is my concern unfounded? Is it a = non-problem I'm envisioning?   (if so, see below for 2 more = concerns  :-)   = )

Cheers,
Michael

<= div>PS:  Concern #2: we can expect a static traffic = profile feeding into a congestion controller to be relatively quickly = done, but creating a test setup with a reactive codec is going to be = much harder and take more time. Will we ever see it? When? Will it be = easy to use?
PPS: Concern #3: the parameter space for tests = might expand quite significantly when we involve reactive codecs... this = will make any evaluation harder, making the results harder to compare, = resulting in more time necessary to come to a conclusion about which = controller does a better = job.


(*) TFRC is an argument to = the contrary, but I haven't seen a single evaluation result that shows = that its smooth rate is indeed beneficial. On the contrary, we now seem = to have some agreement that TFRC isn't the best = mechanism.


On 29. okt. = 2013, at 01:53, Mo Zanaty (mzanaty) wrote:

Agreed. The base layer has no flexibility just like a flat = non-scalable stream.


On 10/28/13, 7:45 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

You're right that there is flexibility in enhancement layers. But = because of the layering structure, the base is not flexible - since the = enhancement layers depend on it, it is typically protected via FEC or = RTX. This affects the viability of "slow start" schemes as well other aspects - no point sending video at all if you = cannot support the base layer, at least.

On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> wrote:

This is true for simulcast layers, but not necessarily scalable = layers. For the latter, arbitrary rates can be achieved within a limited = range (like down to half the bitrate) by selectively dropping some = packets of the highest enhancement layer with minimal visual quality impact. If the stream is highly scalable (many layers, = which is rare), the limited range expands (like down to maybe a third, = quarter, or less of the bitrate). If the stream is coarsely scalable = (e.g. two layers, which is common), dropping below the limited range incurs changing encoding parameters, at which point = arbitrary rates are again possible.

Mo


On 10/28/13, 5:58 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

Colin said:
 
=93Do you mean preparing the same video = sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits = its
estimate? ie rate switch between different media rates of the same
sequence?
=94
 
[BA] I like this approach, because it somewhat = approximates the situation of simulcast/layered coding.  Previous = work has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, = so as to be able to send at least one video stream as well as issues = with TFRFC) that would be likely to be missed in a model in which an = encoder has fully smooth rate control. =   

 

I agree with Colin. We should be focused = on live encoding where the
encoder rate control is highly granular (often fully smooth) and = coupled
to the network congestion control, not pre-encoded streaming of a = small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the = factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of = representative
sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time = intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive = at
some statistical model that can then be used for all tests without = any
real video content or encoding (to avoid introducing noise in = comparisons
if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> = wrote:

On 27. okt. 2013, at 12:33, Varun Singh = <vsingh.ietf@gmail.com>= wrote:

Now, next, what if we'd have a = set of such sequences, and then stack
them over a codec that produces quite arbitrary bitrates, assuming = that
the network can always follow it -

Do you mean preparing the same video sequence at multiple rates and = the
congestion controller picking the appropriate media rate that fits = its
estimate? ie rate switch between different media rates of the same
sequence?

I think that could be a very good idea!


I'd be more interested in a standard set of *uncompressed* video = test
sequences, that we can use to test the combination of video codec = and
congestion control. If we're building something for interactive = video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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


= --Apple-Mail=_6C900866-88D3-462C-8E23-AB949CEF3101-- From lars@netapp.com Tue Oct 29 02:32:38 2013 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 7031611E8151 for ; Tue, 29 Oct 2013 02:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.685 X-Spam-Level: X-Spam-Status: No, score=-4.685 tagged_above=-999 required=5 tests=[AWL=-2.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKT9QfLF62Iz for ; Tue, 29 Oct 2013 02:32:34 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9578911E8169 for ; Tue, 29 Oct 2013 02:32:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,591,1378882800"; d="asc'?scan'208";a="66415090" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 29 Oct 2013 02:32:28 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 02:32:28 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: Meetecho support at IETF-88 Thread-Index: AQHO0/T+3G112PWJfkeRshlOJY657g== Date: Tue, 29 Oct 2013 09:32:27 +0000 Message-ID: References: <526E86E5.6010604@meetecho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_3E7BE71A-8937-4C68-9B40-5886B0B706B2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [rmcat] Fwd: Meetecho support at IETF-88 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 09:32:38 -0000 --Apple-Mail=_3E7BE71A-8937-4C68-9B40-5886B0B706B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, we're being webcast. This means that we'll need FINAL slides from all presenters uploaded 24h = before the meeting, because they need to be preprocessed. Lars Begin forwarded message: > From: Meetecho IETF support > Subject: Meetecho support at IETF-88 > Date: October 28, 2013 23:46:45 GMT+08:00 > To: >=20 > Dear chair(s), >=20 > this email is to confirm Meetecho support for your WG/BOF meeting = session at IETF-88. >=20 > The agenda of supported sessions is available at: > http://ietf88.conf.meetecho.com. >=20 > If you plan to have remote presenters, you're kindly requested to = inform us in proper advance, since this needs special set-up and a = preliminary test with the remote speaker. >=20 > *The deadline for requesting remote presentation support is November = 1.* >=20 > Thanks, > the Meetecho team >=20 > --=20 > Meetecho s.r.l. > www.meetecho.com --Apple-Mail=_3E7BE71A-8937-4C68-9B40-5886B0B706B2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUm+ArdZcnpRveo1xAQItMwP/U//f8BVhil01r769FemynUUF/uh/UtO5 B4TjWq834835bs5bzmD2nqoEIjSxe+S5uH/V9mEPfCAWTMdf2ChGmL0K3UcKgxaE GRs5Qnc0VMuOHOl11uClEYs7Hz/2mCwn9kteilRtkNK9WBUvHozYDFBN8z8VMnh2 APVDGi2/kb8= =4kw8 -----END PGP SIGNATURE----- --Apple-Mail=_3E7BE71A-8937-4C68-9B40-5886B0B706B2-- From michawe@ifi.uio.no Tue Oct 29 03:32:13 2013 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 19B2521F9F20 for ; Tue, 29 Oct 2013 03:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqTfXBnbjNzk for ; Tue, 29 Oct 2013 03:32:07 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 27BD021F9EFE for ; Tue, 29 Oct 2013 03:32:06 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Vb6ak-0005nY-3q; Tue, 29 Oct 2013 11:32:06 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1Vb6ai-0008St-Pn; Tue, 29 Oct 2013 11:32:06 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C7BA2FB5-830F-419A-94EF-7CA7BF024BCB" From: Michael Welzl In-Reply-To: <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> Date: Tue, 29 Oct 2013 11:32:04 +0100 Message-Id: <20A1EBF7-6D36-4E1B-A5C7-6E692B189933@ifi.uio.no> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 8 sum msgs/h 3 total rcpts 9080 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.052, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 17BB65D975EE269A16B48A03B9A91BE3D40E825C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3527 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 10:32:13 -0000 --Apple-Mail=_C7BA2FB5-830F-419A-94EF-7CA7BF024BCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Okay, I'm not convinced, but I will not argue the point any longer. I raised = my concerns but maybe I'm wrong, no problem. Cheers, Michael =20 On 29. okt. 2013, at 10:31, Colin Perkins wrote: > Michael, >=20 > Your concern is why I think we need to test the codec and the = congestion control together. The dynamics of how, and importantly when, = the codec can change its rate will be critical to the dynamics of the = congestion control. This is especially true if we want to keep the = latency low by avoiding sender-side buffering to smooth the codec output = to match the desired sending rate. Testing congestion control without a = codec will give us something that doesn't respect the QoE concerns, and = runs the risk of producing an algorithm that is safe and responsive, but = not useful for interactive video. >=20 > Colin >=20 >=20 > On 29 Oct 2013, at 08:30, Michael Welzl wrote: >> So - looking at this thread, it seems that consensus is against me = :-) >>=20 >> Hence I'd like to clarify - my concern was that we're making the = system too complex by involving a codec that reacts to the congestion = controller **when evaluating congestion control mechanisms**. I mean, = once I've done a test, I'd like to know why I see the effects that I = see, and which mechanism is to blame for them. This will get harder with = this setup. >>=20 >> Let me give an example to explain my concern: >>=20 >> Say, we create a test with a reactive codec over a congestion = controller, and in some network scenarios, we see oscillations: the = congestion controller increased its rate, allowing the codec to switch = to a higher encoding rate; this higher rate was too much, and so quite = fast the congestion controller reduces its rate again, hence the codec = reacts and switches to a lower rate, and so forth. >>=20 >> Now, if that is the test setup for evaluating a congestion = controller, a conclusion from such a test could be that the congestion = controller has to be stabilized. I would, however, argue that a = congestion controller should be as quick as it possibly can at seeking = out available bandwidth, and hence such fluctuations are natural (*), = and it's rather the job of the codec to dampen its rate switching. >>=20 >> Either way, in this example test, we face a bad result, and two = screws to tune to fix the problem - one on the side of the congestion = control, and one on the side of the codec. >>=20 >> This is why I would prefer to evaluate congestion controls (again, = not the whole system, to me that's a different evaluation, and of course = a better congestion control should lead to a better total system) with a = static traffic profile. >>=20 >> Is my concern unfounded? Is it a non-problem I'm envisioning? (if = so, see below for 2 more concerns :-) ) >>=20 >> Cheers, >> Michael >>=20 >> PS: Concern #2: we can expect a static traffic profile feeding into = a congestion controller to be relatively quickly done, but creating a = test setup with a reactive codec is going to be much harder and take = more time. Will we ever see it? When? Will it be easy to use? >> PPS: Concern #3: the parameter space for tests might expand quite = significantly when we involve reactive codecs... this will make any = evaluation harder, making the results harder to compare, resulting in = more time necessary to come to a conclusion about which controller does = a better job. >>=20 >>=20 >> (*) TFRC is an argument to the contrary, but I haven't seen a single = evaluation result that shows that its smooth rate is indeed beneficial. = On the contrary, we now seem to have some agreement that TFRC isn't the = best mechanism. >>=20 >>=20 >> On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) wrote: >>=20 >>> Agreed. The base layer has no flexibility just like a flat = non-scalable stream. >>>=20 >>>=20 >>> On 10/28/13, 7:45 PM, Bernard Aboba = wrote: >>>=20 >>> You're right that there is flexibility in enhancement layers. But = because of the layering structure, the base is not flexible - since the = enhancement layers depend on it, it is typically protected via FEC or = RTX. This affects the viability of "slow start" schemes as well other = aspects - no point sending video at all if you cannot support the base = layer, at least. >>>=20 >>> On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" = wrote: >>>=20 >>>> This is true for simulcast layers, but not necessarily scalable = layers. For the latter, arbitrary rates can be achieved within a limited = range (like down to half the bitrate) by selectively dropping some = packets of the highest enhancement layer with minimal visual quality = impact. If the stream is highly scalable (many layers, which is rare), = the limited range expands (like down to maybe a third, quarter, or less = of the bitrate). If the stream is coarsely scalable (e.g. two layers, = which is common), dropping below the limited range incurs changing = encoding parameters, at which point arbitrary rates are again possible. >>>>=20 >>>> Mo >>>>=20 >>>>=20 >>>> On 10/28/13, 5:58 PM, Bernard Aboba = wrote: >>>>=20 >>>> Colin said: >>>> =20 >>>> =93Do you mean preparing the same video sequence at multiple rates = and the >>>> congestion controller picking the appropriate media rate that fits = its >>>> estimate? ie rate switch between different media rates of the same >>>> sequence? >>>> =94 >>>> =20 >>>> [BA] I like this approach, because it somewhat approximates the = situation of simulcast/layered coding. Previous work has indicated a = number of considerations that arise in those implementations (such as = the need for rapid rampup, so as to be able to send at least one video = stream as well as issues with TFRFC) that would be likely to be missed = in a model in which an encoder has fully smooth rate control. =20 >>>> =20 >>>>=20 >>>> I agree with Colin. We should be focused on live encoding where the >>>> encoder rate control is highly granular (often fully smooth) and = coupled >>>> to the network congestion control, not pre-encoded streaming of a = small >>>> set of fixed bitrates like DASH/HLS. >>>>=20 >>>> A more formal approach to the problem would be to decompose the = factors >>>> contributing to the final rate placed onto the network. >>>> 1. Video content / source statistics, using a large set of = representative >>>> sequences. An estimate of the entropy per frame could simply be the >>>> encoded frame size using constant quantization, i.e. no encoder = rate >>>> control. >>>> 2. Video encoder rate control behavior, which modulates the source >>>> statistics to fit into network constraints over rather large time >>>> intervals (>0.5s). >>>> 3. Network transmission pacing / shaper, which smooths out bursts = in >>>> encoder output to fit into network constraints over fine time = intervals >>>> (<0.5s). >>>>=20 >>>> It should be possible to model all three in an abstract way to = arrive at >>>> some statistical model that can then be used for all tests without = any >>>> real video content or encoding (to avoid introducing noise in = comparisons >>>> if there was any variability in any of the factors). >>>>=20 >>>> Mo >>>>=20 >>>>=20 >>>>=20 >>>> On 10/28/13, 1:49 PM, Colin Perkins wrote: >>>>=20 >>>> On 27 Oct 2013, at 11:50, Michael Welzl wrote: >>>>=20 >>>> On 27. okt. 2013, at 12:33, Varun Singh = wrote: >>>>=20 >>>>> Now, next, what if we'd have a set of such sequences, and then = stack >>>>> them over a codec that produces quite arbitrary bitrates, assuming = that >>>>> the network can always follow it - >>>>=20 >>>> Do you mean preparing the same video sequence at multiple rates and = the >>>> congestion controller picking the appropriate media rate that fits = its >>>> estimate? ie rate switch between different media rates of the same >>>> sequence? >>>>=20 >>>> I think that could be a very good idea! >>>>=20 >>>> I'd be more interested in a standard set of *uncompressed* video = test >>>> sequences, that we can use to test the combination of video codec = and >>>> congestion control. If we're building something for interactive = video >>>> congestion control we should assume live encoding, with the codec >>>> potentially having the flexibility to react to the network, and our >>>> testbed ought to reflect that. >>>>=20 >>>> --=20 >>>> Colin Perkins >>>> http://csperkins.org/ >>>>=20 >=20 --Apple-Mail=_C7BA2FB5-830F-419A-94EF-7CA7BF024BCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
michawe@ifi.uio.no> = wrote:
So - looking at this thread, it seems that = consensus is against me  :-)

Hence I'd like to = clarify - my concern was that we're making the system too complex by = involving a codec that reacts to the congestion controller **when = evaluating congestion control mechanisms**. I mean, once I've done a = test, I'd like to know why I see the effects that I see, and which = mechanism is to blame for them. This will get harder with this = setup.

Let me give an example to explain my = concern:

Say, we create a test with a reactive = codec over a congestion controller, and in some network scenarios, we = see oscillations: the congestion controller increased its rate, allowing = the codec to switch to a higher encoding rate; this higher rate was too = much, and so quite fast the congestion controller reduces its rate = again, hence the codec reacts and switches to a lower rate, and so = forth.

Now, if that is the test setup for = evaluating a congestion controller, a conclusion from such a test could = be that the congestion controller has to be stabilized. I would, = however, argue that a congestion controller should be as quick as = it possibly can at seeking out available bandwidth, and hence such = fluctuations are natural (*), and it's rather the job of the codec to = dampen its rate switching.

Either way, in this = example test, we face a bad result, and two screws to tune to fix the = problem - one on the side of the congestion control, and one on the side = of the codec.

This is why I would prefer to = evaluate congestion controls (again, not the whole system, to me that's = a different evaluation, and of course a better congestion control should = lead to a better total system) with a static traffic = profile.

Is my concern unfounded? Is it a = non-problem I'm envisioning?   (if so, see below for 2 more = concerns  :-)   = )

Cheers,
Michael

<= div>PS:  Concern #2: we can expect a static traffic = profile feeding into a congestion controller to be relatively quickly = done, but creating a test setup with a reactive codec is going to be = much harder and take more time. Will we ever see it? When? Will it be = easy to use?
PPS: Concern #3: the parameter space for tests = might expand quite significantly when we involve reactive codecs... this = will make any evaluation harder, making the results harder to compare, = resulting in more time necessary to come to a conclusion about which = controller does a better = job.


(*) TFRC is an argument to = the contrary, but I haven't seen a single evaluation result that shows = that its smooth rate is indeed beneficial. On the contrary, we now seem = to have some agreement that TFRC isn't the best = mechanism.


On 29. okt. = 2013, at 01:53, Mo Zanaty (mzanaty) wrote:

Agreed. The base layer has no flexibility just like a flat = non-scalable stream.


On 10/28/13, 7:45 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

You're right that there is flexibility in enhancement layers. But = because of the layering structure, the base is not flexible - since the = enhancement layers depend on it, it is typically protected via FEC or = RTX. This affects the viability of "slow start" schemes as well other aspects - no point sending video at all if you = cannot support the base layer, at least.

On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> wrote:

This is true for simulcast layers, but not necessarily scalable = layers. For the latter, arbitrary rates can be achieved within a limited = range (like down to half the bitrate) by selectively dropping some = packets of the highest enhancement layer with minimal visual quality impact. If the stream is highly scalable (many layers, = which is rare), the limited range expands (like down to maybe a third, = quarter, or less of the bitrate). If the stream is coarsely scalable = (e.g. two layers, which is common), dropping below the limited range incurs changing encoding parameters, at which point = arbitrary rates are again possible.

Mo


On 10/28/13, 5:58 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

Colin said:
 
=93Do you mean preparing the same video = sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits = its
estimate? ie rate switch between different media rates of the same
sequence?
=94
 
[BA] I like this approach, because it somewhat = approximates the situation of simulcast/layered coding.  Previous = work has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, = so as to be able to send at least one video stream as well as issues = with TFRFC) that would be likely to be missed in a model in which an = encoder has fully smooth rate control. =   

 

I agree with Colin. We should be focused = on live encoding where the
encoder rate control is highly granular (often fully smooth) and = coupled
to the network congestion control, not pre-encoded streaming of a = small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the = factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of = representative
sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time = intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive = at
some statistical model that can then be used for all tests without = any
real video content or encoding (to avoid introducing noise in = comparisons
if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> = wrote:

On 27. okt. 2013, at 12:33, Varun Singh = <vsingh.ietf@gmail.com>= wrote:

Now, next, what if we'd have a = set of such sequences, and then stack
them over a codec that produces quite arbitrary bitrates, assuming = that
the network can always follow it -

Do you mean preparing the same video sequence at multiple rates and = the
congestion controller picking the appropriate media rate that fits = its
estimate? ie rate switch between different media rates of the same
sequence?

I think that could be a very good idea!


I'd be more interested in a standard set of *uncompressed* video = test
sequences, that we can use to test the combination of video codec = and
congestion control. If we're building something for interactive = video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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



= --Apple-Mail=_C7BA2FB5-830F-419A-94EF-7CA7BF024BCB-- From vsingh.ietf@gmail.com Tue Oct 29 04:32:20 2013 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 65B7311E8174 for ; Tue, 29 Oct 2013 04:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71KlLslV5ySe for ; Tue, 29 Oct 2013 04:32:19 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4775621E8123 for ; Tue, 29 Oct 2013 04:32:02 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id ar20so13667515iec.14 for ; Tue, 29 Oct 2013 04:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9kq34V6yg+kEr38zgtHC2NNT7o5W5uzHC4bnTW/mPKA=; b=Lzxlhw8lN07nYSjxlwSyyzRckLfC24NkzIAeBPiIJD785hd6o58y/jZYigZPZ3JPJ+ EHX9p5OmyPJCQ8cHo+3DazJlUTzObk3WpziBzVM/tKAc0ZtGUMZESzfAvFYWbnWbiLLU u2KC8Xb0lQ4jFDV1hxkU5qOXTX7ix4kaJ7RhqXPHYEEXX/pZjl/TSgPFWNiPJ6bAYmxe RXGVoD1rKtMhDGYvJ7NGR/iJmHmNX4Pgz0R2rGL+btN9DypHCkzdL93bBedaNu/cKTo+ Lsl/zXfZIXBtMTMufRUZmOl57xrziXFxcjYKKJmoXwzjZ69bK3HOLFwLhWxPlREWEOvE 4fxQ== X-Received: by 10.50.115.35 with SMTP id jl3mr12194902igb.37.1383046321458; Tue, 29 Oct 2013 04:32:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Tue, 29 Oct 2013 04:31:41 -0700 (PDT) In-Reply-To: References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> From: Varun Singh Date: Tue, 29 Oct 2013 13:31:41 +0200 Message-ID: To: "Xiaoqing Zhu (xiaoqzhu)" Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG , "Mo Zanaty \(mzanaty\)" , Michael Welzl , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 11:32:20 -0000 Hi, > Also, if we go for the approach of using uncompressed test video sequence > for testing the combination of video codec and congestion control, we should > also recommend a reference codec and default configurations. So that focus > of the evaluations remains on the congestion control module. What do folks > think of x264 (http://www.videolan.org/developers/x264.html)? In [1], we used gstreamer to set and get the encoding bit rate. We chose to use gstreamer instead of using x264 directly was the idea to easily swap it out with libvpx. We haven't tested this yet but I suppose it should be possible. In our experiments, we just set the application constraints (e.g., video resolution, frame rate, etc) and let the codec parameters set as default. I suppose the same would be true if we just swapped out x264 for vpx? [1] http://arxiv.org/pdf/1310.1582v1.pdf See section 6.1, we describe the interaction between the APIs between > > Best, > Xiaoqing > > > > On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) wrote: > > I agree with Colin. We should be focused on live encoding where the > encoder rate control is highly granular (often fully smooth) and coupled > to the network congestion control, not pre-encoded streaming of a small > set of fixed bitrates like DASH/HLS. > > A more formal approach to the problem would be to decompose the factors > contributing to the final rate placed onto the network. > 1. Video content / source statistics, using a large set of representative > sequences. An estimate of the entropy per frame could simply be the > encoded frame size using constant quantization, i.e. no encoder rate > control. > 2. Video encoder rate control behavior, which modulates the source > statistics to fit into network constraints over rather large time > intervals (>0.5s). > 3. Network transmission pacing / shaper, which smooths out bursts in > encoder output to fit into network constraints over fine time intervals > (<0.5s). > > It should be possible to model all three in an abstract way to arrive at > some statistical model that can then be used for all tests without any > real video content or encoding (to avoid introducing noise in comparisons > if there was any variability in any of the factors). > > Mo > > > > On 10/28/13, 1:49 PM, Colin Perkins wrote: > > On 27 Oct 2013, at 11:50, Michael Welzl wrote: > > On 27. okt. 2013, at 12:33, Varun Singh wrote: > > Now, next, what if we'd have a set of such sequences, and then stack > them over a codec that produces quite arbitrary bitrates, assuming that > the network can always follow it - > > > Do you mean preparing the same video sequence at multiple rates and the > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence? > > > I think that could be a very good idea! > > > I'd be more interested in a standard set of *uncompressed* video test > sequences, that we can use to test the combination of video codec and > congestion control. If we're building something for interactive video > congestion control we should assume live encoding, with the codec > potentially having the flexibility to react to the network, and our > testbed ought to reflect that. > > -- > Colin Perkins > http://csperkins.org/ > > > > > -- http://www.netlab.tkk.fi/~varun/ From vsingh.ietf@gmail.com Tue Oct 29 04:36:48 2013 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 8811411E816B for ; Tue, 29 Oct 2013 04:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIOIEgl9dX3V for ; Tue, 29 Oct 2013 04:36:45 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 284CC11E8149 for ; Tue, 29 Oct 2013 04:36:45 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id qd12so13334476ieb.19 for ; Tue, 29 Oct 2013 04:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=agnPbm/Gb9sg0amelquCDJ/jDC7nCgeXPL7wFh3uS4E=; b=FR+1rcrGCG0hzPLZdqYrftIfuvT+ZplJCrKFthMGpTEnfbbGN5oKOCnRE+X1ZDFPKa JYjrEWzUXxf2jPxnKUjDCJiadiIbqOf11oZJ8DAK80SOwpeNT42vuc6yk5bmU+FU3xPA cbR1MEchTE5M3CxpmI6tsda6wl9/eOWegRrZbfvjU+IVkfCnMSAEQc/u7u49T3zrLB7o RZYAElWR12W/vWnaL1gJMpk41OQZMLynTtF636iZswneONnQDr3ZvosobWqlnn+DNwoR PuNsJZ6iTvRowBNqclRuuSEMBxREjBduteTXn6l63kqu9/Yl+6oiPV8X4rBRA50RoCB+ F7iA== X-Received: by 10.50.110.100 with SMTP id hz4mr11983422igb.51.1383046604642; Tue, 29 Oct 2013 04:36:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Tue, 29 Oct 2013 04:36:24 -0700 (PDT) In-Reply-To: References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> From: Varun Singh Date: Tue, 29 Oct 2013 13:36:24 +0200 Message-ID: To: "Xiaoqing Zhu (xiaoqzhu)" Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG , "Mo Zanaty \(mzanaty\)" , Michael Welzl , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 11:36:49 -0000 Hi Xiaoqing, A couple of comments inline. On Mon, Oct 28, 2013 at 10:15 PM, Xiaoqing Zhu (xiaoqzhu) wrote: > Agree with Colin and Mo. > > For a statistical video traffic model, I would propose to break down the 2nd > point (encoder rate control) in Mo's list further, to three sub-components: > > a) delayed response to a rate change request (e.g., > 0.5s) > b) deviations from the requested rate (maybe as randomly fluctuating around > the target?) The original email lists questions for modeling video traffic, if you have concrete suggestions on values, could you put them together in an email? > c) the different frame types or coding modes inside the encoder will yield > some encoded > frames much larger than others. This will lead to burstiness on time scale Any idea on how to model this? i.e., how large (in size) should these packets be to the others? > of frame intervals > (typically 33ms), and later smoothed out by the pacing/shaper. Agree, with the pacing/shaper. > > Also, if we go for the approach of using uncompressed test video sequence > for testing the combination of video codec and congestion control, we should > also recommend a reference codec and default configurations. So that focus > of the evaluations remains on the congestion control module. What do folks > think of x264 (http://www.videolan.org/developers/x264.html)? > > Best, > Xiaoqing > > > > On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) wrote: > > I agree with Colin. We should be focused on live encoding where the > encoder rate control is highly granular (often fully smooth) and coupled > to the network congestion control, not pre-encoded streaming of a small > set of fixed bitrates like DASH/HLS. > > A more formal approach to the problem would be to decompose the factors > contributing to the final rate placed onto the network. > 1. Video content / source statistics, using a large set of representative > sequences. An estimate of the entropy per frame could simply be the > encoded frame size using constant quantization, i.e. no encoder rate > control. > 2. Video encoder rate control behavior, which modulates the source > statistics to fit into network constraints over rather large time > intervals (>0.5s). > 3. Network transmission pacing / shaper, which smooths out bursts in > encoder output to fit into network constraints over fine time intervals > (<0.5s). > > It should be possible to model all three in an abstract way to arrive at > some statistical model that can then be used for all tests without any > real video content or encoding (to avoid introducing noise in comparisons > if there was any variability in any of the factors). > > Mo > > > > On 10/28/13, 1:49 PM, Colin Perkins wrote: > > On 27 Oct 2013, at 11:50, Michael Welzl wrote: > > On 27. okt. 2013, at 12:33, Varun Singh wrote: > > Now, next, what if we'd have a set of such sequences, and then stack > them over a codec that produces quite arbitrary bitrates, assuming that > the network can always follow it - > > > Do you mean preparing the same video sequence at multiple rates and the > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence? > > > I think that could be a very good idea! > > > I'd be more interested in a standard set of *uncompressed* video test > sequences, that we can use to test the combination of video codec and > congestion control. If we're building something for interactive video > congestion control we should assume live encoding, with the codec > potentially having the flexibility to react to the network, and our > testbed ought to reflect that. > > -- > Colin Perkins > http://csperkins.org/ > > > > > -- http://www.netlab.tkk.fi/~varun/ From vsingh.ietf@gmail.com Tue Oct 29 04:39:49 2013 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 8F87B11E8222 for ; Tue, 29 Oct 2013 04:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC94LAZBJNEC for ; Tue, 29 Oct 2013 04:39:48 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EB68621F9E43 for ; Tue, 29 Oct 2013 04:39:47 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tp5so13359573ieb.2 for ; Tue, 29 Oct 2013 04:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CijoVWTqMw6/7i3SG0GD5zeqiyg5f4CGufh/s24cjXA=; b=qNdOLbLiquAiP+FrJa3D6OSOImV5i64flRR0UR+rimNbP6lmD462C/6uE39c9HTi6d u5PJJjYR9qekYXjPG9jjzNAa4ELigu0aAsnREO9WsyCapucfAXYxGAk8IKu0es8dlzd1 G65gP7NrcjYrHZx8/rswpQF2srOC9cs3Jd3IoiDPTrIBM9DQw1shXUJPe2Y1d56ngB6/ 0dozUPZ/J+miBKZ0gmdzRsbzqzSpaAoho/MFsxa+yb8WoSzNouMgOTjN5eVsK5N+/vPx JyhmoYs7WwuHbhesRpJ2ixgwVXhqQDK1ai4wbPZE4S/5TqMIj+xhnqk0T2XczakxCTp3 6eYg== X-Received: by 10.50.110.100 with SMTP id hz4mr11991871igb.51.1383046785252; Tue, 29 Oct 2013 04:39:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Tue, 29 Oct 2013 04:39:25 -0700 (PDT) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> From: Varun Singh Date: Tue, 29 Oct 2013 13:39:25 +0200 Message-ID: To: "Mo Zanaty (mzanaty)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Van Der Auwera, Geert" , Michael Welzl , Bernard Aboba , rmcat WG , Colin Perkins , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 11:39:49 -0000 Clarification for SVC: does this mean that the base layer's target encoding bit rate is fixed and cannot be modified? On Tue, Oct 29, 2013 at 2:53 AM, Mo Zanaty (mzanaty) wr= ote: > Agreed. The base layer has no flexibility just like a flat non-scalable > stream. > > > On 10/28/13, 7:45 PM, Bernard Aboba wrote: > > You're right that there is flexibility in enhancement layers. But because= of > the layering structure, the base is not flexible - since the enhancement > layers depend on it, it is typically protected via FEC or RTX. This affec= ts > the viability of "slow start" schemes as well other aspects - no point > sending video at all if you cannot support the base layer, at least. > > On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" > wrote: > > This is true for simulcast layers, but not necessarily scalable layers. F= or > the latter, arbitrary rates can be achieved within a limited range (like > down to half the bitrate) by selectively dropping some packets of the > highest enhancement layer with minimal visual quality impact. If the stre= am > is highly scalable (many layers, which is rare), the limited range expand= s > (like down to maybe a third, quarter, or less of the bitrate). If the str= eam > is coarsely scalable (e.g. two layers, which is common), dropping below t= he > limited range incurs changing encoding parameters, at which point arbitra= ry > rates are again possible. > > Mo > > > On 10/28/13, 5:58 PM, Bernard Aboba wrote: > > Colin said: > > > > =93Do you mean preparing the same video sequence at multiple rates and th= e > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence? > > =94 > > > > [BA] I like this approach, because it somewhat approximates the situation= of > simulcast/layered coding. Previous work has indicated a number of > considerations that arise in those implementations (such as the need for > rapid rampup, so as to be able to send at least one video stream as well = as > issues with TFRFC) that would be likely to be missed in a model in which = an > encoder has fully smooth rate control. > > > > I agree with Colin. We should be focused on live encoding where the > encoder rate control is highly granular (often fully smooth) and coupled > to the network congestion control, not pre-encoded streaming of a small > set of fixed bitrates like DASH/HLS. > > A more formal approach to the problem would be to decompose the factors > contributing to the final rate placed onto the network. > 1. Video content / source statistics, using a large set of representative > sequences. An estimate of the entropy per frame could simply be the > encoded frame size using constant quantization, i.e. no encoder rate > control. > 2. Video encoder rate control behavior, which modulates the source > statistics to fit into network constraints over rather large time > intervals (>0.5s). > 3. Network transmission pacing / shaper, which smooths out bursts in > encoder output to fit into network constraints over fine time intervals > (<0.5s). > > It should be possible to model all three in an abstract way to arrive at > some statistical model that can then be used for all tests without any > real video content or encoding (to avoid introducing noise in comparisons > if there was any variability in any of the factors). > > Mo > > > > On 10/28/13, 1:49 PM, Colin Perkins wrote: > > On 27 Oct 2013, at 11:50, Michael Welzl wrote: > > On 27. okt. 2013, at 12:33, Varun Singh wrote: > > Now, next, what if we'd have a set of such sequences, and then stack > them over a codec that produces quite arbitrary bitrates, assuming that > the network can always follow it - > > > Do you mean preparing the same video sequence at multiple rates and the > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence? > > > I think that could be a very good idea! > > > I'd be more interested in a standard set of *uncompressed* video test > sequences, that we can use to test the combination of video codec and > congestion control. If we're building something for interactive video > congestion control we should assume live encoding, with the codec > potentially having the flexibility to react to the network, and our > testbed ought to reflect that. > > -- > Colin Perkins > http://csperkins.org/ > > > --=20 http://www.netlab.tkk.fi/~varun/ From vsingh.ietf@gmail.com Tue Oct 29 04:55:24 2013 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 9B53E11E8203 for ; Tue, 29 Oct 2013 04:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnl1H10ck-kq for ; Tue, 29 Oct 2013 04:55:20 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 84CB311E816B for ; Tue, 29 Oct 2013 04:55:20 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so13281127iej.8 for ; Tue, 29 Oct 2013 04:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i0imQzYJ/Pnyp4aYnEHAb+UT3fHv+MsVd4N8zN6HXjw=; b=gAQvue4Ytwf8e3gbwQ9hB0nXPqgdDlu3mYT9AazX6qjMW2r6jBivEoVltU96Tm1mnM 4QY9kJ5ajJQNZeiMP27A9ay3SEL8qV+XtLDNfkKHDrhuw090t1ajDnzzsY/a7kld59g+ PzMCm8kqJn03UB9Zb45sgB2M2YFcdzxV6N5GqYjOLQNEn8wqEAKHR+zUZcoAc4j0+eWm 3ArN+987k7QQEPO5DAyho4lnceJSMlHWdd7NQFd9Hh1NWvdD20rhqOS8RigeNquCeKRK O0mAQOunEF+PUt4t/dJDhTEBP/bpuRkZyeMdnuCtxT23uLkdc/IhNECXuDbKQmd+4RVW DA3w== X-Received: by 10.50.115.35 with SMTP id jl3mr12260003igb.37.1383047718621; Tue, 29 Oct 2013 04:55:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Tue, 29 Oct 2013 04:54:58 -0700 (PDT) In-Reply-To: <4FC1F85139E6FE4D9A55BD6798B29A4816AD5D34@NASANEXD02B.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> <4FC1F85139E6FE4D9A55BD6798B29A4816AD5D34@NASANEXD02B.na.qualcomm.com> From: Varun Singh Date: Tue, 29 Oct 2013 13:54:58 +0200 Message-ID: To: "Van Der Auwera, Geert" Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG , Colin Perkins , "Mo Zanaty \(mzanaty\)" , Michael Welzl , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 11:55:24 -0000 HI Geert, On Mon, Oct 28, 2013 at 10:43 PM, Van Der Auwera, Geert wrote: > Also agree. For initial evaluations of CC proposals and to find consensus > quickly, a statistical video traffic model should be sufficient. However, > proponents should be allowed and perhaps encouraged from producing > additional results with a complete live video encoding testbed of their The cc-eval document encourages proponents to use a video stream, though this is encouraged as a second step (Sec 4.3), but it should not dissuade proponents from pursuing this path. > choice (video quality?). Agreeing on a particular codec at this point may be In Berlin (IETF87), it was decided to leave video quality as an open issue and add it to the appendix, i.e., to reopen it when we have more information, or proponents conducting experiments with live encoded streams. > a bit hard. Regarding the uncompressed test video sequences (VT type), > Qualcomm could provide a set of long sequences (> 1min). > +1 Are these are similar to the ones available at media.xiph.org/video/derf/ Usually I loop the test video sequences to make them longer. > > > Best regards, > > > > Geert > > > > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of > Xiaoqing Zhu (xiaoqzhu) > Sent: Monday, October 28, 2013 1:15 PM > To: Mo Zanaty (mzanaty) > Cc: rmcat WG; Colin Perkins; Michael Welzl; Varun Singh > Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver > (03 Nov, 1300-1500) > > > > Agree with Colin and Mo. > > > > For a statistical video traffic model, I would propose to break down the 2nd > point (encoder rate control) in Mo's list further, to three sub-components: > > > > a) delayed response to a rate change request (e.g., > 0.5s) > > b) deviations from the requested rate (maybe as randomly fluctuating around > the target?) > > c) the different frame types or coding modes inside the encoder will yield > some encoded > > frames much larger than others. This will lead to burstiness on time scale > of frame intervals > > (typically 33ms), and later smoothed out by the pacing/shaper. > > > > Also, if we go for the approach of using uncompressed test video sequence > for testing the combination of video codec and congestion control, we should > also recommend a reference codec and default configurations. So that focus > of the evaluations remains on the congestion control module. What do folks > think of x264 (http://www.videolan.org/developers/x264.html)? > > > > Best, > > Xiaoqing > > > > > > > > On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) wrote: > > > > I agree with Colin. We should be focused on live encoding where the > encoder rate control is highly granular (often fully smooth) and coupled > to the network congestion control, not pre-encoded streaming of a small > set of fixed bitrates like DASH/HLS. > > A more formal approach to the problem would be to decompose the factors > contributing to the final rate placed onto the network. > 1. Video content / source statistics, using a large set of representative > sequences. An estimate of the entropy per frame could simply be the > encoded frame size using constant quantization, i.e. no encoder rate > control. > 2. Video encoder rate control behavior, which modulates the source > statistics to fit into network constraints over rather large time > intervals (>0.5s). > 3. Network transmission pacing / shaper, which smooths out bursts in > encoder output to fit into network constraints over fine time intervals > (<0.5s). > > It should be possible to model all three in an abstract way to arrive at > some statistical model that can then be used for all tests without any > real video content or encoding (to avoid introducing noise in comparisons > if there was any variability in any of the factors). > > Mo > > > > On 10/28/13, 1:49 PM, Colin Perkins wrote: > > On 27 Oct 2013, at 11:50, Michael Welzl wrote: > > On 27. okt. 2013, at 12:33, Varun Singh wrote: > > Now, next, what if we'd have a set of such sequences, and then stack > them over a codec that produces quite arbitrary bitrates, assuming that > the network can always follow it - > > > Do you mean preparing the same video sequence at multiple rates and the > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence? > > > I think that could be a very good idea! > > > I'd be more interested in a standard set of *uncompressed* video test > sequences, that we can use to test the combination of video codec and > congestion control. If we're building something for interactive video > congestion control we should assume live encoding, with the codec > potentially having the flexibility to react to the network, and our > testbed ought to reflect that. > > -- > Colin Perkins > http://csperkins.org/ > > > > -- http://www.netlab.tkk.fi/~varun/ From coverdale@sympatico.ca Tue Oct 29 05:34:12 2013 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 1019A11E822D for ; Tue, 29 Oct 2013 05:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVR9Gq0tYV0l for ; Tue, 29 Oct 2013 05:34:06 -0700 (PDT) Received: from blu0-omc3-s17.blu0.hotmail.com (blu0-omc3-s17.blu0.hotmail.com [65.55.116.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE9811E8173 for ; Tue, 29 Oct 2013 05:34:06 -0700 (PDT) Received: from BLU0-SMTP10 ([65.55.116.73]) by blu0-omc3-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Oct 2013 05:34:06 -0700 X-TMN: [wuwBnLXXU5Sn0ZRN4AKVEQ2CksaaaR5fqoaRBvSVth8=] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([156.106.245.254]) by BLU0-SMTP10.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Oct 2013 05:34:02 -0700 From: Paul Coverdale To: "'Michael Welzl'" References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> <20A1EBF7-6D36-4E1B-A5C7-6E692B189933@ifi.uio.no> In-Reply-To: <20A1EBF7-6D36-4E1B-A5C7-6E692B189933@ifi.uio.no> Date: Tue, 29 Oct 2013 13:33:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CED4AB.878835B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7Ukimvx6Bek4+/TW28ZBn96OnYiAAB4PQw Content-Language: en-us X-OriginalArrivalTime: 29 Oct 2013 12:34:02.0606 (UTC) FILETIME=[263490E0:01CED4A3] Cc: 'rmcat WG' Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 12:34:12 -0000 ------=_NextPart_000_000F_01CED4AB.878835B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I should have jumped in earlier but I agree with Michael's concern. By using a codec which behaves adaptively it will be difficult to figure out what the congestion controller is really doing. At least we should include a static profile as a baseline reference. ...Paul From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Michael Welzl Sent: Tuesday, October 29, 2013 11:32 AM To: Colin Perkins Cc: rmcat WG Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Okay, I'm not convinced, but I will not argue the point any longer. I raised my concerns but maybe I'm wrong, no problem. Cheers, Michael On 29. okt. 2013, at 10:31, Colin Perkins wrote: Michael, Your concern is why I think we need to test the codec and the congestion control together. The dynamics of how, and importantly when, the codec can change its rate will be critical to the dynamics of the congestion control. This is especially true if we want to keep the latency low by avoiding sender-side buffering to smooth the codec output to match the desired sending rate. Testing congestion control without a codec will give us something that doesn't respect the QoE concerns, and runs the risk of producing an algorithm that is safe and responsive, but not useful for interactive video. Colin On 29 Oct 2013, at 08:30, Michael Welzl wrote: So - looking at this thread, it seems that consensus is against me :-) Hence I'd like to clarify - my concern was that we're making the system too complex by involving a codec that reacts to the congestion controller **when evaluating congestion control mechanisms**. I mean, once I've done a test, I'd like to know why I see the effects that I see, and which mechanism is to blame for them. This will get harder with this setup. Let me give an example to explain my concern: Say, we create a test with a reactive codec over a congestion controller, and in some network scenarios, we see oscillations: the congestion controller increased its rate, allowing the codec to switch to a higher encoding rate; this higher rate was too much, and so quite fast the congestion controller reduces its rate again, hence the codec reacts and switches to a lower rate, and so forth. Now, if that is the test setup for evaluating a congestion controller, a conclusion from such a test could be that the congestion controller has to be stabilized. I would, however, argue that a congestion controller should be as quick as it possibly can at seeking out available bandwidth, and hence such fluctuations are natural (*), and it's rather the job of the codec to dampen its rate switching. Either way, in this example test, we face a bad result, and two screws to tune to fix the problem - one on the side of the congestion control, and one on the side of the codec. This is why I would prefer to evaluate congestion controls (again, not the whole system, to me that's a different evaluation, and of course a better congestion control should lead to a better total system) with a static traffic profile. Is my concern unfounded? Is it a non-problem I'm envisioning? (if so, see below for 2 more concerns :-) ) Cheers, Michael PS: Concern #2: we can expect a static traffic profile feeding into a congestion controller to be relatively quickly done, but creating a test setup with a reactive codec is going to be much harder and take more time. Will we ever see it? When? Will it be easy to use? PPS: Concern #3: the parameter space for tests might expand quite significantly when we involve reactive codecs... this will make any evaluation harder, making the results harder to compare, resulting in more time necessary to come to a conclusion about which controller does a better job. (*) TFRC is an argument to the contrary, but I haven't seen a single evaluation result that shows that its smooth rate is indeed beneficial. On the contrary, we now seem to have some agreement that TFRC isn't the best mechanism. On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) wrote: Agreed. The base layer has no flexibility just like a flat non-scalable stream. On 10/28/13, 7:45 PM, Bernard Aboba wrote: You're right that there is flexibility in enhancement layers. But because of the layering structure, the base is not flexible - since the enhancement layers depend on it, it is typically protected via FEC or RTX. This affects the viability of "slow start" schemes as well other aspects - no point sending video at all if you cannot support the base layer, at least. On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" wrote: This is true for simulcast layers, but not necessarily scalable layers. For the latter, arbitrary rates can be achieved within a limited range (like down to half the bitrate) by selectively dropping some packets of the highest enhancement layer with minimal visual quality impact. If the stream is highly scalable (many layers, which is rare), the limited range expands (like down to maybe a third, quarter, or less of the bitrate). If the stream is coarsely scalable (e.g. two layers, which is common), dropping below the limited range incurs changing encoding parameters, at which point arbitrary rates are again possible. Mo On 10/28/13, 5:58 PM, Bernard Aboba wrote: Colin said: "Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? " [BA] I like this approach, because it somewhat approximates the situation of simulcast/layered coding. Previous work has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, so as to be able to send at least one video stream as well as issues with TFRFC) that would be likely to be missed in a model in which an encoder has fully smooth rate control. I agree with Colin. We should be focused on live encoding where the encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small set of fixed bitrates like DASH/HLS. A more formal approach to the problem would be to decompose the factors contributing to the final rate placed onto the network. 1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the encoded frame size using constant quantization, i.e. no encoder rate control. 2. Video encoder rate control behavior, which modulates the source statistics to fit into network constraints over rather large time intervals (>0.5s). 3. Network transmission pacing / shaper, which smooths out bursts in encoder output to fit into network constraints over fine time intervals (<0.5s). It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors). Mo On 10/28/13, 1:49 PM, Colin Perkins wrote: On 27 Oct 2013, at 11:50, Michael Welzl wrote: On 27. okt. 2013, at 12:33, Varun Singh wrote: Now, next, what if we'd have a set of such sequences, and then stack them over a codec that produces quite arbitrary bitrates, assuming that the network can always follow it - Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that. -- Colin Perkins http://csperkins.org/ ------=_NextPart_000_000F_01CED4AB.878835B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I should have jumped in earlier but I agree with Michael’s = concern. By using a codec which behaves adaptively it will be difficult = to figure out what the congestion controller is really doing. At least = we should include a static profile as a baseline = reference.

 

...Paul

 

From:= = rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of = Michael Welzl
Sent: Tuesday, October 29, 2013 11:32 = AM
To: Colin Perkins
Cc: rmcat WG
Subject: = Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 = Nov, 1300-1500)

 

Okay,

 

I'm not convinced, but I will not argue the point any = longer. I raised my concerns but maybe I'm wrong, no = problem.

 

Cheers,

Michael

 

 

On = 29. okt. 2013, at 10:31, Colin Perkins wrote:



Michael,

 

Your concern is why I think we need to test the codec = and the congestion control together. The dynamics of how, and = importantly when, the codec can change its rate will be critical to the = dynamics of the congestion control. This is especially true if we want = to keep the latency low by avoiding sender-side buffering to smooth the = codec output to match the desired sending rate. Testing congestion = control without a codec will give us something that doesn't respect the = QoE concerns, and runs the risk of producing an algorithm that is safe = and responsive, but not useful for interactive = video.

 

Colin

 

 

On = 29 Oct 2013, at 08:30, Michael Welzl <michawe@ifi.uio.no> = wrote:

So - looking at this thread, it seems that consensus = is against me  :-)

 

Hence I'd like to clarify - my concern was that we're = making the system too complex by involving a codec that reacts to the = congestion controller **when evaluating congestion control mechanisms**. = I mean, once I've done a test, I'd like to know why I see the effects = that I see, and which mechanism is to blame for them. This will get = harder with this setup.

 

Let me give an example to explain my = concern:

 

Say, we create a test with a reactive codec over a = congestion controller, and in some network scenarios, we see = oscillations: the congestion controller increased its rate, allowing the = codec to switch to a higher encoding rate; this higher rate was too = much, and so quite fast the congestion controller reduces its rate = again, hence the codec reacts and switches to a lower rate, and so = forth.

 

Now, if that is the test setup for evaluating a = congestion controller, a conclusion from such a test could be that the = congestion controller has to be stabilized. I would, however, argue that = a congestion controller should be as quick as it possibly can at = seeking out available bandwidth, and hence such fluctuations are natural = (*), and it's rather the job of the codec to dampen its rate = switching.

 

Either way, in this example test, we face a bad = result, and two screws to tune to fix the problem - one on the side of = the congestion control, and one on the side of the = codec.

 

This is why I would prefer to evaluate congestion = controls (again, not the whole system, to me that's a different = evaluation, and of course a better congestion control should lead to a = better total system) with a static traffic = profile.

 

Is my concern unfounded? Is it a non-problem I'm = envisioning?   (if so, see below for 2 more concerns  :-) =   )

 

Cheers,

Michael

 

PS:  Concern #2: we can expect a static = traffic profile feeding into a congestion controller to be relatively = quickly done, but creating a test setup with a reactive codec is going = to be much harder and take more time. Will we ever see it? When? Will it = be easy to use?

PPS: = Concern #3: the parameter space for tests might expand quite = significantly when we involve reactive codecs... this will make any = evaluation harder, making the results harder to compare, resulting in = more time necessary to come to a conclusion about which controller does = a better job.

 

 

(*) TFRC is an argument to the contrary, but I haven't = seen a single evaluation result that shows that its smooth rate is = indeed beneficial. On the contrary, we now seem to have some agreement = that TFRC isn't the best mechanism.

 

 

On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) = wrote:



Agreed. The = base layer has no flexibility just like a flat non-scalable = stream.

 

 

On 10/28/13, = 7:45 PM, Bernard Aboba <bernard_aboba@hotmail.com&g= t; wrote:

 

You're right = that there is flexibility in enhancement layers. But because of the = layering structure, the base is not flexible - since the enhancement = layers depend on it, it is typically protected via FEC or RTX. This = affects the viability of "slow start" schemes as well other = aspects - no point sending video at all if you cannot support the base = layer, at least.


On Oct = 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> = wrote:

This is true = for simulcast layers, but not necessarily scalable layers. For the = latter, arbitrary rates can be achieved within a limited range (like = down to half the bitrate) by selectively dropping some packets of the = highest enhancement layer with minimal visual quality impact. If the = stream is highly scalable (many layers, which is rare), the limited = range expands (like down to maybe a third, quarter, or less of the = bitrate). If the stream is coarsely scalable (e.g. two layers, which is = common), dropping below the limited range incurs changing encoding = parameters, at which point arbitrary rates are again = possible.

 

Mo<= /span>

 

 

On 10/28/13, = 5:58 PM, Bernard Aboba <bernard_aboba@hotmail.com&g= t; wrote:

 

Colin said:

 

“Do you mean preparing the same video sequence at = multiple rates and the
congestion controller picking the appropriate = media rate that fits its
estimate? ie rate switch between different = media rates of the same
sequence?

”

 

[BA] I like this approach, because it somewhat approximates the = situation of simulcast/layered coding.  Previous work has indicated = a number of considerations that arise in those implementations (such as = the need for rapid rampup, so as to be able to send at least one video = stream as well as issues with TFRFC) that would be likely to be missed = in a model in which an encoder has fully smooth rate control. =   

 

I agree with Colin. We should be focused = on live encoding where the
encoder rate control is highly granular = (often fully smooth) and coupled
to the network congestion control, = not pre-encoded streaming of a small
set of fixed bitrates like = DASH/HLS.

A more formal approach to the problem would be to = decompose the factors
contributing to the final rate placed onto the = network.
1. Video content / source statistics, using a large set of = representative
sequences. An estimate of the entropy per frame could = simply be the
encoded frame size using constant quantization, i.e. no = encoder rate
control.
2. Video encoder rate control behavior, = which modulates the source
statistics to fit into network constraints = over rather large time
intervals (>0.5s).
3. Network = transmission pacing / shaper, which smooths out bursts in
encoder = output to fit into network constraints over fine time = intervals
(<0.5s).

It should be possible to model all three = in an abstract way to arrive at
some statistical model that can then = be used for all tests without any
real video content or encoding (to = avoid introducing noise in comparisons
if there was any variability = in any of the factors).

Mo



On 10/28/13, 1:49 PM, = Colin Perkins <csp@csperkins.org> = wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> = wrote:

On 27. okt. 2013, at 12:33, Varun Singh = <vsingh.ietf@gmail.com> = wrote:

Now, next, what if we'd have a set of such sequences, = and then stack
them over a codec that produces quite arbitrary = bitrates, assuming that
the network can always follow it = -


Do you = mean preparing the same video sequence at multiple rates and = the
congestion controller picking the appropriate media rate that = fits its
estimate? ie rate switch between different media rates of = the same
sequence?


I think that could be a very good = idea!


I'd be more interested in a standard = set of *uncompressed* video test
sequences, that we can use to test = the combination of video codec and
congestion control. If we're = building something for interactive video
congestion control we should = assume live encoding, with the codec
potentially having the = flexibility to react to the network, and our
testbed ought to reflect = that.

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

 

 

------=_NextPart_000_000F_01CED4AB.878835B0-- From mzanaty@cisco.com Tue Oct 29 05:45:16 2013 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 8C13C11E8235 for ; Tue, 29 Oct 2013 05:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeTBnxDBQpFJ for ; Tue, 29 Oct 2013 05:45:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CFE0711E8230 for ; Tue, 29 Oct 2013 05:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5333; q=dns/txt; s=iport; t=1383050711; x=1384260311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MnrS5oOQQk3wAHpqaPQoso7hMN3hrxOQJoTg78yW1ws=; b=QaBZV5UEIK69LhVWGoGV9/Z3RUC9M+2zU79oN6ZJvdb275KlGhaq0aiK Oh6ivJrJqCSVeUOaSb8Jknw0gji0hbPUu2teFTNUyvQee7jKwXk8TwhzV CSZ+kGh4RMaxULiCRopYv4v/bhxJrNwtHh74tNwAiGO/RtSluoObhkGe+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAG2sb1KtJXG9/2dsb2JhbABZFoJxOK0nkl+BJhZ0giUBAQEEeRACAQgOCi4hESUCBA4Fh3UDD69UDYlrjFqBLoEMMweDH4ENA5YfAYFqgS+LIgOFNIFogT6BaA X-IronPort-AV: E=Sophos;i="4.93,593,1378857600"; d="scan'208";a="277775059" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 29 Oct 2013 12:45:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9TCj8Qb005453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 12:45:08 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 07:45:08 -0500 From: "Mo Zanaty (mzanaty)" To: Varun Singh Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1JuEgwVs6QKB+UiBda2MQkwFlZoLoC4q Date: Tue, 29 Oct 2013 12:45:07 +0000 Message-ID: <936E3EDD-DC3A-4509-AEB3-374A5EB978DE@cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Van Der Auwera, Geert" , Michael Welzl , Bernard Aboba , rmcat WG , Colin Perkins , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 12:45:16 -0000 Live encoding parameters can always be modified even for base layers. The o= riginal point was that even pre-encoded scalable streams can transmit arbit= rarily smooth rates within a limited range (down to the base layer rate) wi= thout modifying encoding parameters by simply dropping (pre-)encoded packet= s from enhancement layers. Mo On Oct 29, 2013, at 7:39 AM, "Varun Singh" wrote: Clarification for SVC: does this mean that the base layer's target encoding bit rate is fixed and cannot be modified? On Tue, Oct 29, 2013 at 2:53 AM, Mo Zanaty (mzanaty) wr= ote: > Agreed. The base layer has no flexibility just like a flat non-scalable > stream. >=20 >=20 > On 10/28/13, 7:45 PM, Bernard Aboba wrote: >=20 > You're right that there is flexibility in enhancement layers. But because= of > the layering structure, the base is not flexible - since the enhancement > layers depend on it, it is typically protected via FEC or RTX. This affec= ts > the viability of "slow start" schemes as well other aspects - no point > sending video at all if you cannot support the base layer, at least. >=20 > On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" > wrote: >=20 > This is true for simulcast layers, but not necessarily scalable layers. F= or > the latter, arbitrary rates can be achieved within a limited range (like > down to half the bitrate) by selectively dropping some packets of the > highest enhancement layer with minimal visual quality impact. If the stre= am > is highly scalable (many layers, which is rare), the limited range expand= s > (like down to maybe a third, quarter, or less of the bitrate). If the str= eam > is coarsely scalable (e.g. two layers, which is common), dropping below t= he > limited range incurs changing encoding parameters, at which point arbitra= ry > rates are again possible. >=20 > Mo >=20 >=20 > On 10/28/13, 5:58 PM, Bernard Aboba wrote: >=20 > Colin said: >=20 >=20 >=20 > =93Do you mean preparing the same video sequence at multiple rates and th= e > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence? >=20 > =94 >=20 >=20 >=20 > [BA] I like this approach, because it somewhat approximates the situation= of > simulcast/layered coding. Previous work has indicated a number of > considerations that arise in those implementations (such as the need for > rapid rampup, so as to be able to send at least one video stream as well = as > issues with TFRFC) that would be likely to be missed in a model in which = an > encoder has fully smooth rate control. >=20 >=20 >=20 > I agree with Colin. We should be focused on live encoding where the > encoder rate control is highly granular (often fully smooth) and coupled > to the network congestion control, not pre-encoded streaming of a small > set of fixed bitrates like DASH/HLS. >=20 > A more formal approach to the problem would be to decompose the factors > contributing to the final rate placed onto the network. > 1. Video content / source statistics, using a large set of representative > sequences. An estimate of the entropy per frame could simply be the > encoded frame size using constant quantization, i.e. no encoder rate > control. > 2. Video encoder rate control behavior, which modulates the source > statistics to fit into network constraints over rather large time > intervals (>0.5s). > 3. Network transmission pacing / shaper, which smooths out bursts in > encoder output to fit into network constraints over fine time intervals > (<0.5s). >=20 > It should be possible to model all three in an abstract way to arrive at > some statistical model that can then be used for all tests without any > real video content or encoding (to avoid introducing noise in comparisons > if there was any variability in any of the factors). >=20 > Mo >=20 >=20 >=20 > On 10/28/13, 1:49 PM, Colin Perkins wrote: >=20 > On 27 Oct 2013, at 11:50, Michael Welzl wrote: >=20 > On 27. okt. 2013, at 12:33, Varun Singh wrote: >=20 > Now, next, what if we'd have a set of such sequences, and then stack > them over a codec that produces quite arbitrary bitrates, assuming that > the network can always follow it - >=20 >=20 > Do you mean preparing the same video sequence at multiple rates and the > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence? >=20 >=20 > I think that could be a very good idea! >=20 >=20 > I'd be more interested in a standard set of *uncompressed* video test > sequences, that we can use to test the combination of video codec and > congestion control. If we're building something for interactive video > congestion control we should assume live encoding, with the codec > potentially having the flexibility to react to the network, and our > testbed ought to reflect that. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 --=20 http://www.netlab.tkk.fi/~varun/ From mramalho@cisco.com Tue Oct 29 06:33:10 2013 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 8F7F711E823F for ; Tue, 29 Oct 2013 06:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZWb4KqM+kzG for ; Tue, 29 Oct 2013 06:33:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 694F211E8165 for ; Tue, 29 Oct 2013 06:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35920; q=dns/txt; s=iport; t=1383053579; x=1384263179; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Inmt1SDHXedrzW3MwSG6l8fBz8TVa9CR9+djoptqnqk=; b=VNbeMkqHstzusQ/bbiXQKFGVa5hfQhgm0v7HoF60zL+Lh9EeyI4AoCWE QE1m4K3lf8nzQXqC8o4y6qsESLTRTdGoA1hkg+uKIfydjkY3izGYhSxVy PlwU0Sa066EDN2CaC2wIIPvv5Q64snuSl/V5JbtxtAOK5oyv4aptsEqUO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMHACa4b1KtJV2b/2dsb2JhbABZgkNEOFSsUjKJZohHgSgWdIIlAQEBBBoTTBACAQgOAwQBAQsWAQYHIREUCQgCBAENBQiHbQMPr2oNiWuMWoEugQ4xBgEJgxaBDQOUKoF1AYMZiyKFN4FogT6BaEI X-IronPort-AV: E=Sophos;i="4.93,593,1378857600"; d="scan'208,217";a="278004475" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 29 Oct 2013 13:32:44 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9TDWhek030015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 13:32:44 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.29]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 08:32:43 -0500 From: "Michael Ramalho (mramalho)" To: Michael Welzl , Colin Perkins Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1IFCY5cnAJclckmQXN2HG4KJUpoLvf4AgAARCQD//9NiIA== Date: Tue, 29 Oct 2013 13:32:42 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> <20A1EBF7-6D36-4E1B-A5C7-6E692B189933@ifi.uio.no> In-Reply-To: <20A1EBF7-6D36-4E1B-A5C7-6E692B189933@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.4.151] Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B910322FAFD3Cxmbrcdx12ciscoc_" MIME-Version: 1.0 Cc: rmcat WG Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 13:33:10 -0000 --_000_D21571530BF9644D9A443D6BD95B910322FAFD3Cxmbrcdx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW - I also agree with Michael (Welzl, as I usually agree with myself). I think we are going down a dangerous road and one in which, if we went dow= n previously, the Internet as we know it would not exist. When did we - in the effort to prove sufficiency, convergence and/or stabil= ity of a lower layer - demand that the constraints and DESIRED OPERATION of= the upper layer (such as it can only change rate every so often) MUST be m= et? Michael Welzl is right, if we need the codec to "shut up" (stop producing d= ata for a while) or to quickly slowdown in order to have a stable transport= layer - then we need it to shut up or slow down. This goes to the "upper l= ayer API" issue that Mirja brought up a few weeks ago. The only "desired operation" of the upper layer we desire for success is lo= w delay (and "reasonable share of bandwidth") - and even that is qualified= for "when low delay is possible". That is why I argued that for the base stability tests that we must do what= TCP assumed for stability, the ability to send an infinite amount of data. We need to live with the (predominantly TCP and best-effort/tail-drop) worl= d as we know it and live within those constraints. Once we know what is possible, then codec designers will differentiate them= selves on how best to render what we (i.e., RMCAT or similar) can provide t= hem. Good codec designs are NOT STATIC, but rather are improved as the cons= traints presented to them are known. For example, if I frame bursts are "to= o big", then you find codec manufacturers building gradual I-frame refresh = capabilities. Designing the rmcat transport assuming that codec capabilitie= s are known and are forever static is like TCP having been designed with th= e assumption that hosts would forever have sub 200 MHz processors in them. [Aside: Although at data center speeds TCP did have its challenges, it was = pretty darn good from hundreds of bits per second to a few megabits per sec= ond with few changes to its underlying mechanics. But I digress.] There is only so much the rmcat layer can do regarding QoE. Codec manufactu= res may desire, for example, not to change to a higher resolution until the= y are "very sure" that they will not have to change downward anytime soon -= because changing resolutions too often does not yield a better QoE. Let th= em design algorithms on when and how to shift based on whatever information= the "rmcat layer" provides them. Off Soapbox, Michael Ramalho From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of M= ichael Welzl Sent: Tuesday, October 29, 2013 6:32 AM To: Colin Perkins Cc: rmcat WG Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouve= r (03 Nov, 1300-1500) Okay, I'm not convinced, but I will not argue the point any longer. I raised my c= oncerns but maybe I'm wrong, no problem. Cheers, Michael On 29. okt. 2013, at 10:31, Colin Perkins wrote: Michael, Your concern is why I think we need to test the codec and the congestion co= ntrol together. The dynamics of how, and importantly when, the codec can ch= ange its rate will be critical to the dynamics of the congestion control. T= his is especially true if we want to keep the latency low by avoiding sende= r-side buffering to smooth the codec output to match the desired sending ra= te. Testing congestion control without a codec will give us something that = doesn't respect the QoE concerns, and runs the risk of producing an algorit= hm that is safe and responsive, but not useful for interactive video. Colin On 29 Oct 2013, at 08:30, Michael Welzl > wrote: So - looking at this thread, it seems that consensus is against me :-) Hence I'd like to clarify - my concern was that we're making the system too= complex by involving a codec that reacts to the congestion controller **wh= en evaluating congestion control mechanisms**. I mean, once I've done a tes= t, I'd like to know why I see the effects that I see, and which mechanism i= s to blame for them. This will get harder with this setup. Let me give an example to explain my concern: Say, we create a test with a reactive codec over a congestion controller, a= nd in some network scenarios, we see oscillations: the congestion controlle= r increased its rate, allowing the codec to switch to a higher encoding rat= e; this higher rate was too much, and so quite fast the congestion controll= er reduces its rate again, hence the codec reacts and switches to a lower r= ate, and so forth. Now, if that is the test setup for evaluating a congestion controller, a co= nclusion from such a test could be that the congestion controller has to be= stabilized. I would, however, argue that a congestion controller should be= as quick as it possibly can at seeking out available bandwidth, and hence = such fluctuations are natural (*), and it's rather the job of the codec to = dampen its rate switching. Either way, in this example test, we face a bad result, and two screws to t= une to fix the problem - one on the side of the congestion control, and one= on the side of the codec. This is why I would prefer to evaluate congestion controls (again, not the = whole system, to me that's a different evaluation, and of course a better c= ongestion control should lead to a better total system) with a static traff= ic profile. Is my concern unfounded? Is it a non-problem I'm envisioning? (if so, see= below for 2 more concerns :-) ) Cheers, Michael PS: Concern #2: we can expect a static traffic profile feeding into a cong= estion controller to be relatively quickly done, but creating a test setup = with a reactive codec is going to be much harder and take more time. Will w= e ever see it? When? Will it be easy to use? PPS: Concern #3: the parameter space for tests might expand quite significa= ntly when we involve reactive codecs... this will make any evaluation harde= r, making the results harder to compare, resulting in more time necessary t= o come to a conclusion about which controller does a better job. (*) TFRC is an argument to the contrary, but I haven't seen a single evalua= tion result that shows that its smooth rate is indeed beneficial. On the co= ntrary, we now seem to have some agreement that TFRC isn't the best mechani= sm. On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) wrote: Agreed. The base layer has no flexibility just like a flat non-scalable str= eam. On 10/28/13, 7:45 PM, Bernard Aboba > wrote: You're right that there is flexibility in enhancement layers. But because o= f the layering structure, the base is not flexible - since the enhancement = layers depend on it, it is typically protected via FEC or RTX. This affects= the viability of "slow start" schemes as well other aspects - no point sen= ding video at all if you cannot support the base layer, at least. On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" > wrote: This is true for simulcast layers, but not necessarily scalable layers. For= the latter, arbitrary rates can be achieved within a limited range (like d= own to half the bitrate) by selectively dropping some packets of the highes= t enhancement layer with minimal visual quality impact. If the stream is hi= ghly scalable (many layers, which is rare), the limited range expands (like= down to maybe a third, quarter, or less of the bitrate). If the stream is = coarsely scalable (e.g. two layers, which is common), dropping below the li= mited range incurs changing encoding parameters, at which point arbitrary r= ates are again possible. Mo On 10/28/13, 5:58 PM, Bernard Aboba > wrote: Colin said: "Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? " [BA] I like this approach, because it somewhat approximates the situation o= f simulcast/layered coding. Previous work has indicated a number of consid= erations that arise in those implementations (such as the need for rapid ra= mpup, so as to be able to send at least one video stream as well as issues = with TFRFC) that would be likely to be missed in a model in which an encode= r has fully smooth rate control. I agree with Colin. We should be focused on live encoding where the encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small set of fixed bitrates like DASH/HLS. A more formal approach to the problem would be to decompose the factors contributing to the final rate placed onto the network. 1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the encoded frame size using constant quantization, i.e. no encoder rate control. 2. Video encoder rate control behavior, which modulates the source statistics to fit into network constraints over rather large time intervals (>0.5s). 3. Network transmission pacing / shaper, which smooths out bursts in encoder output to fit into network constraints over fine time intervals (<0.5s). It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors). Mo On 10/28/13, 1:49 PM, Colin Perkins > wrote: On 27 Oct 2013, at 11:50, Michael Welzl > wrote: On 27. okt. 2013, at 12:33, Varun Singh > wrote: Now, next, what if we'd have a set of such sequences, and then stack them over a codec that produces quite arbitrary bitrates, assuming that the network can always follow it - Do you mean preparing the same video sequence at multiple rates and the congestion controller picking the appropriate media rate that fits its estimate? ie rate switch between different media rates of the same sequence? I think that could be a very good idea! I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec potentially having the flexibility to react to the network, and our testbed ought to reflect that. -- Colin Perkins http://csperkins.org/ --_000_D21571530BF9644D9A443D6BD95B910322FAFD3Cxmbrcdx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FWIW – I also agree= with Michael (Welzl, as I usually agree with myself).

 <= /p>

I think we are going down= a dangerous road and one in which, if we went down previously, the Interne= t as we know it would not exist.

 <= /p>

When did we – in th= e effort to prove sufficiency, convergence and/or stability of a lower laye= r – demand that the constraints and DESIRED OPERATION of the upper layer (such as it can only change rate every so often) MUST be met? <= /o:p>

 <= /p>

Michael Welzl is right, i= f we need the codec to “shut up” (stop producing data for a whi= le) or to quickly slowdown in order to have a stable transport layer – then we need it to shut up or slow down. This goes to the “u= pper layer API” issue that Mirja brought up a few weeks ago.

 <= /p>

The only “desired o= peration” of the upper layer we desire for success is low delay (and = “reasonable share of bandwidth”)  – and even that is= qualified for “when low delay is possible”.

 <= /p>

That is why I argued that= for the base stability tests that we must do what TCP assumed for stabilit= y, the ability to send an infinite amount of data.

 <= /p>

We need to live with the = (predominantly TCP and best-effort/tail-drop) world as we know it and live = within those constraints.

 <= /p>

Once we know what is poss= ible, then codec designers will differentiate themselves on how best to ren= der what we (i.e., RMCAT or similar) can provide them. Good codec designs are NOT STATIC, but rather are improved as the constraints p= resented to them are known. For example, if I frame bursts are “too b= ig”, then you find codec manufacturers building gradual I-frame refre= sh capabilities. Designing the rmcat transport assuming that codec capabilities are known and are forever static is like = TCP having been designed with the assumption that hosts would forever have = sub 200 MHz processors in them.

 <= /p>

[Aside: Although at data = center speeds TCP did have its challenges, it was pretty darn good from hun= dreds of bits per second to a few megabits per second with few changes to its underlying mechanics. But I digress.]=

 <= /p>

There is only so much the= rmcat layer can do regarding QoE. Codec manufactures may desire, for examp= le, not to change to a higher resolution until they are “very sure” that they will not have to change downward anytime= soon – because changing resolutions too often does not yield a bette= r QoE. Let them design algorithms on when and how to shift based on whateve= r information the “rmcat layer” provides them.

 <= /p>

Off Soapbox,

 <= /p>

Michael Ramalho

 <= /p>

From: rmcat-bo= unces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Michael Welzl
Sent: Tuesday, October 29, 2013 6:32 AM
To: Colin Perkins
Cc: rmcat WG
Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in V= ancouver (03 Nov, 1300-1500)

 

Okay,

 

I'm not convinced, but I will not argue the point an= y longer. I raised my concerns but maybe I'm wrong, no problem.<= /p>

 

Cheers,

Michael

 

 

On 29. okt. 2013, at 10:31, Colin Perkins wrote:



Michael,

 

Your concern is why I think we need to test the code= c and the congestion control together. The dynamics of how, and importantly= when, the codec can change its rate will be critical to the dynamics of th= e congestion control. This is especially true if we want to keep the latency low by avoiding sender-side buffering = to smooth the codec output to match the desired sending rate. Testing conge= stion control without a codec will give us something that doesn't respect t= he QoE concerns, and runs the risk of producing an algorithm that is safe and responsive, but not useful for = interactive video.

 

Colin

 

 

On 29 Oct 2013, at 08:30, Michael Welzl <michawe@ifi.uio.no> wrote:=

So - looking at this thread, it seems that consensus= is against me  :-)

 

Hence I'd like to clarify - my concern was that we'r= e making the system too complex by involving a codec that reacts to the con= gestion controller **when evaluating congestion control mechanisms**. I mea= n, once I've done a test, I'd like to know why I see the effects that I see, and which mechanism is to blame = for them. This will get harder with this setup.

 

Let me give an example to explain my concern:

 

Say, we create a test with a reactive codec over a c= ongestion controller, and in some network scenarios, we see oscillations: t= he congestion controller increased its rate, allowing the codec to switch t= o a higher encoding rate; this higher rate was too much, and so quite fast the congestion controller reduces its= rate again, hence the codec reacts and switches to a lower rate, and so fo= rth.

 

Now, if that is the test setup for evaluating a cong= estion controller, a conclusion from such a test could be that the congesti= on controller has to be stabilized. I would, however, argue that a congesti= on controller should be as quick as it possibly can at seeking out available bandwidth, and hence such fluctua= tions are natural (*), and it's rather the job of the codec to dampen its r= ate switching.

 

Either way, in this example test, we face a bad resu= lt, and two screws to tune to fix the problem - one on the side of the cong= estion control, and one on the side of the codec.

 

This is why I would prefer to evaluate congestion co= ntrols (again, not the whole system, to me that's a different evaluation, a= nd of course a better congestion control should lead to a better total syst= em) with a static traffic profile.

 

Is my concern unfounded? Is it a non-problem I'm env= isioning?   (if so, see below for 2 more concerns  :-)   )

 

Cheers,

Michael

 

PS:  Concern #2: we can expect a stat= ic traffic profile feeding into a congestion controller to be relatively qu= ickly done, but creating a test setup with a reactive codec is going to be = much harder and take more time. Will we ever see it? When? Will it be easy to use?

PPS: Concern #3: the parameter space for tests might= expand quite significantly when we involve reactive codecs... this will ma= ke any evaluation harder, making the results harder to compare, resulting i= n more time necessary to come to a conclusion about which controller does a better job.

 

 

(*) TFRC is an argument to the contrary, but I haven= 't seen a single evaluation result that shows that its smooth rate is indee= d beneficial. On the contrary, we now seem to have some agreement that TFRC= isn't the best mechanism.

 

 

On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) wrot= e:



Agreed. The base layer has no flexibility = just like a flat non-scalable stream.

 

 

On 10/28/13, 7:45 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

 

You're right that there is flexibility in = enhancement layers. But because of the layering structure, the base is not = flexible - since the enhancement layers depend on it, it is typically protected via FEC or RTX. This affects the viability of "= ;slow start" schemes as well other aspects - no point sending video at= all if you cannot support the base layer, at least.


On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> wrote:

This is true for simulcast layers, but not= necessarily scalable layers. For the latter, arbitrary rates can be achiev= ed within a limited range (like down to half the bitrate) by selectively dropping some packets of the highest enhancement layer with= minimal visual quality impact. If the stream is highly scalable (many laye= rs, which is rare), the limited range expands (like down to maybe a third, = quarter, or less of the bitrate). If the stream is coarsely scalable (e.g. two layers, which is common), dro= pping below the limited range incurs changing encoding parameters, at which= point arbitrary rates are again possible.

 

Mo

 

 

On 10/28/13, 5:58 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

 

Colin said:

 <= /p>

“Do you mean= preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?

”=

 <= /p>

[BA] I like this approach= , because it somewhat approximates the situation of simulcast/layered codin= g.  Previous work has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, so= as to be able to send at least one video stream as well as issues with TFR= FC) that would be likely to be missed in a model in which an encoder has fu= lly smooth rate control.   

 

I agree with Colin. W= e should be focused on live encoding where the
encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any
real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> wrote:

On 27. okt. 2013, at = 12:33, Varun Singh <vsingh.ietf= @gmail.com> wrote:

Now, next, what if we'd have a set of such sequences= , and then stack
them over a codec that produces quite arbitrary bitrates, assuming that
the network can always follow it -


Do you mean preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?


I think that could be a very good idea!


I'd be more interested in a standard set of *uncompressed* video test
sequences, that we can use to test the combination of video codec and
congestion control. If we're building something for interactive video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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

 

 

--_000_D21571530BF9644D9A443D6BD95B910322FAFD3Cxmbrcdx12ciscoc_-- From michawe@ifi.uio.no Tue Oct 29 06:42:11 2013 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 B2DE411E823D for ; Tue, 29 Oct 2013 06:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qYhYdIH+xuM for ; Tue, 29 Oct 2013 06:42:07 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id C260921F9EF6 for ; Tue, 29 Oct 2013 06:42:06 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Vb9YW-0001XT-Qj; Tue, 29 Oct 2013 14:42:00 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Vb9YW-0006H7-7p; Tue, 29 Oct 2013 14:42:00 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl In-Reply-To: <936E3EDD-DC3A-4509-AEB3-374A5EB978DE@cisco.com> Date: Tue, 29 Oct 2013 14:41:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com>, <936E3EDD-DC3A-4509-AEB3-374A5EB978DE@cisco.com> To: Mo Zanaty (mzanaty) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 4 sum rcpts/h 17 sum msgs/h 5 total rcpts 9102 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.052, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1C8868B8E5C014945523EC7532A3CAB9B44F24B7 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 3536 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: "Van Der Auwera, Geert" , Bernard Aboba , rmcat WG , Varun Singh , Colin Perkins , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 13:42:11 -0000 True, especially when considering FEC! You're right, that was the = original point! This makes me think - agree with it or not, but: to satisfy what *I* = wanted to have (different static traffic profiles as inputs to the = congestion controller), is it perhaps enough to just consider a min and = max rate????? Now THAT could make things easy at least in a first step?! Cheers, Michael On 29. okt. 2013, at 13:45, Mo Zanaty (mzanaty) wrote: > Live encoding parameters can always be modified even for base layers. = The original point was that even pre-encoded scalable streams can = transmit arbitrarily smooth rates within a limited range (down to the = base layer rate) without modifying encoding parameters by simply = dropping (pre-)encoded packets from enhancement layers. >=20 > Mo >=20 >=20 > On Oct 29, 2013, at 7:39 AM, "Varun Singh" = wrote: >=20 > Clarification for SVC: does this mean that the base layer's target > encoding bit rate is fixed and cannot be modified? >=20 > On Tue, Oct 29, 2013 at 2:53 AM, Mo Zanaty (mzanaty) = wrote: >> Agreed. The base layer has no flexibility just like a flat = non-scalable >> stream. >>=20 >>=20 >> On 10/28/13, 7:45 PM, Bernard Aboba = wrote: >>=20 >> You're right that there is flexibility in enhancement layers. But = because of >> the layering structure, the base is not flexible - since the = enhancement >> layers depend on it, it is typically protected via FEC or RTX. This = affects >> the viability of "slow start" schemes as well other aspects - no = point >> sending video at all if you cannot support the base layer, at least. >>=20 >> On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" = >> wrote: >>=20 >> This is true for simulcast layers, but not necessarily scalable = layers. For >> the latter, arbitrary rates can be achieved within a limited range = (like >> down to half the bitrate) by selectively dropping some packets of the >> highest enhancement layer with minimal visual quality impact. If the = stream >> is highly scalable (many layers, which is rare), the limited range = expands >> (like down to maybe a third, quarter, or less of the bitrate). If the = stream >> is coarsely scalable (e.g. two layers, which is common), dropping = below the >> limited range incurs changing encoding parameters, at which point = arbitrary >> rates are again possible. >>=20 >> Mo >>=20 >>=20 >> On 10/28/13, 5:58 PM, Bernard Aboba = wrote: >>=20 >> Colin said: >>=20 >>=20 >>=20 >> =93Do you mean preparing the same video sequence at multiple rates = and the >> congestion controller picking the appropriate media rate that fits = its >> estimate? ie rate switch between different media rates of the same >> sequence? >>=20 >> =94 >>=20 >>=20 >>=20 >> [BA] I like this approach, because it somewhat approximates the = situation of >> simulcast/layered coding. Previous work has indicated a number of >> considerations that arise in those implementations (such as the need = for >> rapid rampup, so as to be able to send at least one video stream as = well as >> issues with TFRFC) that would be likely to be missed in a model in = which an >> encoder has fully smooth rate control. >>=20 >>=20 >>=20 >> I agree with Colin. We should be focused on live encoding where the >> encoder rate control is highly granular (often fully smooth) and = coupled >> to the network congestion control, not pre-encoded streaming of a = small >> set of fixed bitrates like DASH/HLS. >>=20 >> A more formal approach to the problem would be to decompose the = factors >> contributing to the final rate placed onto the network. >> 1. Video content / source statistics, using a large set of = representative >> sequences. An estimate of the entropy per frame could simply be the >> encoded frame size using constant quantization, i.e. no encoder rate >> control. >> 2. Video encoder rate control behavior, which modulates the source >> statistics to fit into network constraints over rather large time >> intervals (>0.5s). >> 3. Network transmission pacing / shaper, which smooths out bursts in >> encoder output to fit into network constraints over fine time = intervals >> (<0.5s). >>=20 >> It should be possible to model all three in an abstract way to arrive = at >> some statistical model that can then be used for all tests without = any >> real video content or encoding (to avoid introducing noise in = comparisons >> if there was any variability in any of the factors). >>=20 >> Mo >>=20 >>=20 >>=20 >> On 10/28/13, 1:49 PM, Colin Perkins wrote: >>=20 >> On 27 Oct 2013, at 11:50, Michael Welzl wrote: >>=20 >> On 27. okt. 2013, at 12:33, Varun Singh = wrote: >>=20 >> Now, next, what if we'd have a set of such sequences, and then stack >> them over a codec that produces quite arbitrary bitrates, assuming = that >> the network can always follow it - >>=20 >>=20 >> Do you mean preparing the same video sequence at multiple rates and = the >> congestion controller picking the appropriate media rate that fits = its >> estimate? ie rate switch between different media rates of the same >> sequence? >>=20 >>=20 >> I think that could be a very good idea! >>=20 >>=20 >> I'd be more interested in a standard set of *uncompressed* video test >> sequences, that we can use to test the combination of video codec and >> congestion control. If we're building something for interactive video >> congestion control we should assume live encoding, with the codec >> potentially having the flexibility to react to the network, and our >> testbed ought to reflect that. >>=20 >> -- >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ From john@jlc.net Tue Oct 29 07:28:05 2013 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 DEBDC11E8143 for ; Tue, 29 Oct 2013 07:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.365 X-Spam-Level: X-Spam-Status: No, score=-106.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpJv8d8hv00H for ; Tue, 29 Oct 2013 07:28:00 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C650B21E8135 for ; Tue, 29 Oct 2013 07:27:32 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 591A7C94BF; Tue, 29 Oct 2013 10:27:30 -0400 (EDT) Date: Tue, 29 Oct 2013 10:27:30 -0400 From: John Leslie To: "Michael Ramalho (mramalho)" Message-ID: <20131029142730.GS65952@verdi> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> <20A1EBF7-6D36-4E1B-A5C7-6E692B189933@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: rmcat WG Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 14:28:06 -0000 Michael Ramalho (mramalho) wrote: >... > When did we - in the effort to prove sufficiency, convergence and/or > stability of a lower layer - demand that the constraints and DESIRED > OPERATION of the upper layer (such as it can only change rate every > so often) MUST be met? I had to read that three times to catch your meaning. :^( (You do mean that it's a bad idea to demand that a transport "send" without regard to network conditions, right?) > The only "desired operation" of the upper layer we desire for success > is low delay (and "reasonable share of bandwidth") - and even that is > qualified for "when low delay is possible". There is certainly a desire for low delay -- I would argue that it trumps "reasonable share of bandwidth" when it gets above 100 msec. > That is why I argued that for the base stability tests that we must > do what TCP assumed for stability, the ability to send an infinite > amount of data. That strikes me as a bad model: we want to send at a _rate_ which is fairly consistent. The TCP model of constantly probing for more available bandwidth _needs_to_ be avoided. > We need to live with the (predominantly TCP and best-effort/tail-drop) > world as we know it and live within those constraints. We need to _function_in_ that world for a while, yes; but the nature of our traffic is entirely too different to "live within" the constraints of TCP. > Once we know what is possible, then codec designers will differentiate > themselves on how best to render what we (i.e., RMCAT or similar) can > provide them. "What is possible" changes too fast for that. Codec designers must devote most of their attention to balancing bandwidth and delay -- it's always possible to reduce bandwidth by increasing delay through the codec. > Good codec designs are NOT STATIC, but rather are improved as the > constraints presented to them are known. For example, if I-frame > bursts are "too big", then you find codec manufacturers building > gradual I-frame refresh capabilities. That's worth doing anyway. (Further, I doubt that "bursts too big" has ever been an unambiguous constraint.) > Designing the rmcat transport assuming that codec capabilities are > known and are forever static is like TCP having been designed with > the assumption that hosts would forever have sub 200 MHz processors > in them. Nonetheless, there are limits to what a standardized transport can adapt to. We need to build into the first version spec what sort of "slow down" signals we can return to the codecs. > There is only so much the rmcat layer can do regarding QoE. Codec > manufacturers may desire, for example, not to change to a higher > resolution until they are "very sure" that they will not have to > change downward anytime soon - because changing resolutions too often > does not yield a better QoE. Yes. > Let them design algorithms on when and how to shift based on whatever > information the "rmcat layer" provides them. But we have to design that feedback path into our first spec. -- John Leslie From holmer@google.com Tue Oct 29 07:32:44 2013 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 3C2FA21E8139 for ; Tue, 29 Oct 2013 07:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ithrQHzrys2T for ; Tue, 29 Oct 2013 07:32:42 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E249B11E8279 for ; Tue, 29 Oct 2013 07:32:25 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 8so4940750qea.4 for ; Tue, 29 Oct 2013 07:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rosmpVwhjmZsg3v29UC9lKb5TvbuBEKt7fbqTdgS70c=; b=Wisp8ejte61enYTzgzhQYKvWqRgDGzebvc4wcUOtt3isnwrPniWE6d8iuxXDDKcKrc TYyUzCA32lGNeV2F5aOqmJRH8mlZucvGhq7DRSCAar43edKED7qewmC78fkBXxbk+1Ad xXV7tbXMaRQQo0ggFrzw+uNomJ3eBKZaKJkLoU0VMsbXXpBBsowgYyRPrQDFDsj9Qtss HIneUpmELda6zdO3r1Vc3IWsEzHsEwmUyVnWrIQkwLAybPWUsqneYxSHOsmlw6Y7s22X 5iucVR60tENNdR4IIlAZzfbpGI2dtoGkGL04oMKBVXwJRO42aVWa0L8oWfj3pkNoOGmv MbVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rosmpVwhjmZsg3v29UC9lKb5TvbuBEKt7fbqTdgS70c=; b=OJiAALb9IUkaLcOr2HeftFbH37COhQ+NTgjTDL5cSYawaJJIbRHDWlpniv20DIJdgR v39o4n2+CamrB4jafwLPiqw4iibAPhBZd+Y8jV0k2LdSrxctkWKt5U3ME6t4rFD9E+I5 azkJnpD61EYeq3AIfOeGw8uxIAmHRuuX/rmBClkp3ckmRz/kd3re8iHGrU2a9t+5skeC gLr22m2ikukTvd8E2u4SYunFwMi1jVzV/SPKceHtdMQup44Vn0Rl86rvbUFWBqdGuMkk q8HHRJqdkF1DWpz9tjXismZc7jKToXyZAx+VPQ7gbZ+0EuCxlbgnmeug7eF2Ue3QPLDR 7XAQ== X-Gm-Message-State: ALoCoQlfwVmvVIhqxqCluAP7onAfR2WcM4fraEUAqWuzzIWmXQFTheW3WB2WPupixy796UfI0NeK2jie0B+XlD5IKq/W+89K71FirZ/gga4p+PrCUGys8nrF8/ZbY5j7xoIjnpqkDvDY2fGM8b2Ohsz1C3Y5kUPPcCuamcnI+Tfxmbo7RxlASVBkaCn4paD9FRv+A0BpAUQE MIME-Version: 1.0 X-Received: by 10.224.98.200 with SMTP id r8mr1221005qan.26.1383057145266; Tue, 29 Oct 2013 07:32:25 -0700 (PDT) Sender: holmer@google.com Received: by 10.229.139.133 with HTTP; Tue, 29 Oct 2013 07:32:25 -0700 (PDT) In-Reply-To: References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> <20A1EBF7-6D36-4E1B-A5C7-6E692B189933@ifi.uio.no> Date: Tue, 29 Oct 2013 15:32:25 +0100 X-Google-Sender-Auth: fSZDyBUqp4QLfVqvKAchmfBTykQ Message-ID: From: Stefan Holmer To: "Michael Ramalho (mramalho)" Content-Type: multipart/alternative; boundary=089e01536b7cd9203304e9e21520 Cc: rmcat WG , Colin Perkins , Michael Welzl Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 14:32:44 -0000 --089e01536b7cd9203304e9e21520 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I also agree that we should try to evaluate the different components (CC, pacing, rate control) separately. But I also think that doing full system evaluation has some value for the reasons mentioned by Colin. In the end we want to have a congestion controller which behaves in a way which is good for real-time media quality. I'm not sure how useful it is to evaluate for all types of streams/rate control we can come up with though (svc, simulcast, one fully flexible stream). Maybe we have to if we are also designing how to probe between simulcast/svc layers? When it comes to pacing, which was mentioned earlier in this thread, I want to highlight the issue of pacing at the rate suggested by the congestion controller. If the CC is limited by media bitrate we would introduce big delays for users who have "infinite" bandwidth if we would pace the packets at the CC rate. I don't think it's unreasonable to allow pacing at a higher bitrate than the CC suggests and rely on the codec to, on average, stay within its target. We have to make sure we measure both packets lost and delay incurred when evaluating this component. Related to this, are we considering the encoder and its rate control as a component that we can trust, or should the CC queue/drop packets if the encoder produces too much over some window? On Tue, Oct 29, 2013 at 2:32 PM, Michael Ramalho (mramalho) < mramalho@cisco.com> wrote: > FWIW =96 I also agree with Michael (Welzl, as I usually agree with mysel= f). > **** > > ** ** > > I think we are going down a dangerous road and one in which, if we went > down previously, the Internet as we know it would not exist.**** > > ** ** > > When did we =96 in the effort to prove sufficiency, convergence and/or > stability of a lower layer =96 demand that the constraints and DESIRED > OPERATION of the upper layer (such as it can only change rate every so > often) MUST be met? **** > > ** ** > > Michael Welzl is right, if we need the codec to =93shut up=94 (stop produ= cing > data for a while) or to quickly slowdown in order to have a stable > transport layer =96 then we need it to shut up or slow down. This goes to= the > =93upper layer API=94 issue that Mirja brought up a few weeks ago.**** > > ** ** > > The only =93desired operation=94 of the upper layer we desire for success= is > low delay (and =93reasonable share of bandwidth=94) =96 and even that is > qualified for =93when low delay is possible=94. **** > > ** ** > > That is why I argued that for the base stability tests that we must do > what TCP assumed for stability, the ability to send an infinite amount of > data.**** > > ** ** > > We need to live with the (predominantly TCP and best-effort/tail-drop) > world as we know it and live within those constraints.**** > > ** ** > > Once we know what is possible, then codec designers will differentiate > themselves on how best to render what we (i.e., RMCAT or similar) can > provide them. Good codec designs are NOT STATIC, but rather are improved = as > the constraints presented to them are known. For example, if I frame burs= ts > are =93too big=94, then you find codec manufacturers building gradual I-f= rame > refresh capabilities. Designing the rmcat transport assuming that codec > capabilities are known and are forever static is like TCP having been > designed with the assumption that hosts would forever have sub 200 MHz > processors in them.**** > > ** ** > > [Aside: Although at data center speeds TCP did have its challenges, it wa= s > pretty darn good from hundreds of bits per second to a few megabits per > second with few changes to its underlying mechanics. But I digress.]**** > > ** ** > > There is only so much the rmcat layer can do regarding QoE. Codec > manufactures may desire, for example, not to change to a higher resolutio= n > until they are =93very sure=94 that they will not have to change downward > anytime soon =96 because changing resolutions too often does not yield a > better QoE. Let them design algorithms on when and how to shift based on > whatever information the =93rmcat layer=94 provides them.**** > > ** ** > > Off Soapbox,**** > > ** ** > > Michael Ramalho**** > > ** ** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Michael Welzl > *Sent:* Tuesday, October 29, 2013 6:32 AM > > *To:* Colin Perkins > *Cc:* rmcat WG > *Subject:* Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in > Vancouver (03 Nov, 1300-1500)**** > > ** ** > > Okay,**** > > ** ** > > I'm not convinced, but I will not argue the point any longer. I raised my > concerns but maybe I'm wrong, no problem.**** > > ** ** > > Cheers,**** > > Michael**** > > ** ** > > **** > > On 29. okt. 2013, at 10:31, Colin Perkins wrote:**** > > > > **** > > Michael,**** > > ** ** > > Your concern is why I think we need to test the codec and the congestion > control together. The dynamics of how, and importantly when, the codec ca= n > change its rate will be critical to the dynamics of the congestion contro= l. > This is especially true if we want to keep the latency low by avoiding > sender-side buffering to smooth the codec output to match the desired > sending rate. Testing congestion control without a codec will give us > something that doesn't respect the QoE concerns, and runs the risk of > producing an algorithm that is safe and responsive, but not useful for > interactive video.**** > > ** ** > > Colin**** > > ** ** > > ** ** > > On 29 Oct 2013, at 08:30, Michael Welzl wrote:**** > > So - looking at this thread, it seems that consensus is against me :-)*= * > ** > > ** ** > > Hence I'd like to clarify - my concern was that we're making the system > too complex by involving a codec that reacts to the congestion controller > **when evaluating congestion control mechanisms**. I mean, once I've done= a > test, I'd like to know why I see the effects that I see, and which > mechanism is to blame for them. This will get harder with this setup.**** > > ** ** > > Let me give an example to explain my concern:**** > > ** ** > > Say, we create a test with a reactive codec over a congestion controller, > and in some network scenarios, we see oscillations: the congestion > controller increased its rate, allowing the codec to switch to a higher > encoding rate; this higher rate was too much, and so quite fast the > congestion controller reduces its rate again, hence the codec reacts and > switches to a lower rate, and so forth.**** > > ** ** > > Now, if that is the test setup for evaluating a congestion controller, a > conclusion from such a test could be that the congestion controller has t= o > be stabilized. I would, however, argue that a congestion controller shoul= d > be as quick as it possibly can at seeking out available bandwidth, and > hence such fluctuations are natural (*), and it's rather the job of the > codec to dampen its rate switching.**** > > ** ** > > Either way, in this example test, we face a bad result, and two screws to > tune to fix the problem - one on the side of the congestion control, and > one on the side of the codec.**** > > ** ** > > This is why I would prefer to evaluate congestion controls (again, not th= e > whole system, to me that's a different evaluation, and of course a better > congestion control should lead to a better total system) with a static > traffic profile.**** > > ** ** > > Is my concern unfounded? Is it a non-problem I'm envisioning? (if so, > see below for 2 more concerns :-) )**** > > ** ** > > Cheers,**** > > Michael**** > > ** ** > > PS: Concern #2: we can expect a static traffic profile feeding into a > congestion controller to be relatively quickly done, but creating a test > setup with a reactive codec is going to be much harder and take more time= . > Will we ever see it? When? Will it be easy to use?**** > > PPS: Concern #3: the parameter space for tests might expand quite > significantly when we involve reactive codecs... this will make any > evaluation harder, making the results harder to compare, resulting in mor= e > time necessary to come to a conclusion about which controller does a bett= er > job.**** > > ** ** > > ** ** > > (*) TFRC is an argument to the contrary, but I haven't seen a single > evaluation result that shows that its smooth rate is indeed beneficial. O= n > the contrary, we now seem to have some agreement that TFRC isn't the best > mechanism.**** > > ** ** > > ** ** > > On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) wrote:**** > > > > **** > > Agreed. The base layer has no flexibility just like a flat non-scalable > stream.**** > > ** ** > > ** ** > > On 10/28/13, 7:45 PM, Bernard Aboba wrote:***= * > > ** ** > > You're right that there is flexibility in enhancement layers. But because > of the layering structure, the base is not flexible - since the enhanceme= nt > layers depend on it, it is typically protected via FEC or RTX. This affec= ts > the viability of "slow start" schemes as well other aspects - no point > sending video at all if you cannot support the base layer, at least.**** > > > On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" > wrote:**** > > This is true for simulcast layers, but not necessarily scalable layers. > For the latter, arbitrary rates can be achieved within a limited range > (like down to half the bitrate) by selectively dropping some packets of t= he > highest enhancement layer with minimal visual quality impact. If the stre= am > is highly scalable (many layers, which is rare), the limited range expand= s > (like down to maybe a third, quarter, or less of the bitrate). If the > stream is coarsely scalable (e.g. two layers, which is common), dropping > below the limited range incurs changing encoding parameters, at which poi= nt > arbitrary rates are again possible.**** > > ** ** > > Mo**** > > ** ** > > ** ** > > On 10/28/13, 5:58 PM, Bernard Aboba wrote:***= * > > ** ** > > Colin said: **** > > **** > > =93Do you mean preparing the same video sequence at multiple rates and th= e > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence?**** > > =94**** > > **** > > [BA] I like this approach, because it somewhat approximates the situation > of simulcast/layered coding. Previous work has indicated a number of > considerations that arise in those implementations (such as the need for > rapid rampup, so as to be able to send at least one video stream as well = as > issues with TFRFC) that would be likely to be missed in a model in which = an > encoder has fully smooth rate control. **** > > **** > > I agree with Colin. We should be focused on live encoding where the > encoder rate control is highly granular (often fully smooth) and coupled > to the network congestion control, not pre-encoded streaming of a small > set of fixed bitrates like DASH/HLS. > > A more formal approach to the problem would be to decompose the factors > contributing to the final rate placed onto the network. > 1. Video content / source statistics, using a large set of representative > sequences. An estimate of the entropy per frame could simply be the > encoded frame size using constant quantization, i.e. no encoder rate > control. > 2. Video encoder rate control behavior, which modulates the source > statistics to fit into network constraints over rather large time > intervals (>0.5s). > 3. Network transmission pacing / shaper, which smooths out bursts in > encoder output to fit into network constraints over fine time intervals > (<0.5s). > > It should be possible to model all three in an abstract way to arrive at > some statistical model that can then be used for all tests without any > real video content or encoding (to avoid introducing noise in comparisons > if there was any variability in any of the factors). > > Mo > > > > On 10/28/13, 1:49 PM, Colin Perkins wrote: > > On 27 Oct 2013, at 11:50, Michael Welzl wrote:**** > > On 27. okt. 2013, at 12:33, Varun Singh wrote:***= * > > Now, next, what if we'd have a set of such sequences, and then stack > them over a codec that produces quite arbitrary bitrates, assuming that > the network can always follow it -**** > > > Do you mean preparing the same video sequence at multiple rates and the > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence?**** > > > I think that could be a very good idea!**** > > > I'd be more interested in a standard set of *uncompressed* video test > sequences, that we can use to test the combination of video codec and > congestion control. If we're building something for interactive video > congestion control we should assume live encoding, with the codec > potentially having the flexibility to react to the network, and our > testbed ought to reflect that. > > -- > Colin Perkins > http://csperkins.org/**** > > ** ** > > ** ** > --089e01536b7cd9203304e9e21520 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I also agree that we should try to evaluate the different = components (CC, pacing, rate control) separately. But I also think that doi= ng full system evaluation has some value for the reasons mentioned by Colin= . In the end we want to have a congestion controller which behaves in a way= which is good for real-time media quality. I'm not sure how useful it = is to evaluate for all types of streams/rate control we can come up with th= ough (svc, simulcast, one fully flexible stream). Maybe we have to if we ar= e also designing how to probe between simulcast/svc layers?

When it comes to pacing, which was mentioned earlier in= this thread, I want to highlight the issue of pacing at the rate suggested= by the congestion controller. If the CC is limited by media bitrate we wou= ld introduce big delays for users who have "infinite" bandwidth i= f we would pace the packets at the CC rate. I don't think it's unre= asonable to allow pacing at a higher bitrate than the CC suggests and rely = on the codec to, on average, stay within its target. We have to make sure w= e measure both packets lost and delay incurred when evaluating this compone= nt.

Related to this, are we considering the encoder and its= rate control as a component that we can trust, or should the CC queue/drop= packets if the encoder produces too much over some window?



<= br>
On Tue, Oct 29, 2013 at 2:32 PM, Michael Rama= lho (mramalho) <mramalho@cisco.com> wrote:

FWIW =96 I also agree wit= h Michael (Welzl, as I usually agree with myself).

=A0<= /p>

I think we are going down= a dangerous road and one in which, if we went down previously, the Interne= t as we know it would not exist.

=A0<= /p>

When did we =96 in the ef= fort to prove sufficiency, convergence and/or stability of a lower layer = =96 demand that the constraints and DESIRED OPERATION of the upper layer (such as it can only change rate every so often) MUST be met?

=A0<= /p>

Michael Welzl is right, i= f we need the codec to =93shut up=94 (stop producing data for a while) or t= o quickly slowdown in order to have a stable transport layer =96 then we need it to shut up or slow down. This goes to the =93upper lay= er API=94 issue that Mirja brought up a few weeks ago.=

=A0<= /p>

The only =93desired opera= tion=94 of the upper layer we desire for success is low delay (and =93reaso= nable share of bandwidth=94) =A0=96 and even that is qualified for =93when low delay is possible=94.

=A0<= /p>

That is why I argued that= for the base stability tests that we must do what TCP assumed for stabilit= y, the ability to send an infinite amount of data.

=A0<= /p>

We need to live with the = (predominantly TCP and best-effort/tail-drop) world as we know it and live = within those constraints.

=A0<= /p>

Once we know what is poss= ible, then codec designers will differentiate themselves on how best to ren= der what we (i.e., RMCAT or similar) can provide them. Good codec designs are NOT STATIC, but rather are improved as the constraints p= resented to them are known. For example, if I frame bursts are =93too big= =94, then you find codec manufacturers building gradual I-frame refresh cap= abilities. Designing the rmcat transport assuming that codec capabilities are known and are forever static is like = TCP having been designed with the assumption that hosts would forever have = sub 200 MHz processors in them.

=A0<= /p>

[Aside: Although at data = center speeds TCP did have its challenges, it was pretty darn good from hun= dreds of bits per second to a few megabits per second with few changes to its underlying mechanics. But I digress.]

=A0<= /p>

There is only so much the= rmcat layer can do regarding QoE. Codec manufactures may desire, for examp= le, not to change to a higher resolution until they are =93very sure=94 that they will not have to change downward anytime soon = =96 because changing resolutions too often does not yield a better QoE. Let= them design algorithms on when and how to shift based on whatever informat= ion the =93rmcat layer=94 provides them.

=A0<= /p>

Off Soapbox,

=A0<= /p>

Michael Ramalho=

=A0<= /p>

From: rmcat-bounces@ietf.org= [mailto:rm= cat-bounces@ietf.org] On Behalf Of Michael Welzl
Sent: Tuesday, October 29, 2013 6:32 AM

=
To: Colin Perkins
Cc: rmcat WG
Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic mode= l in Vancouver (03 Nov, 1300-1500)

=A0

Okay,

=A0

I'm not convinced, but I will not argue the poin= t any longer. I raised my concerns but maybe I'm wrong, no problem.<= /u>

=A0

Cheers,

Michael

=A0

=A0

On 29. okt. 2013, at 10:31, Colin Perkins wrote:<= /u>



Michael,

=A0

Your concern is why I think we need to test the code= c and the congestion control together. The dynamics of how, and importantly= when, the codec can change its rate will be critical to the dynamics of th= e congestion control. This is especially true if we want to keep the latency low by avoiding sender-side buffering = to smooth the codec output to match the desired sending rate. Testing conge= stion control without a codec will give us something that doesn't respe= ct the QoE concerns, and runs the risk of producing an algorithm that is safe and responsive, but not useful for = interactive video.

=A0

Colin

=A0

=A0

On 29 Oct 2013, at 08:30, Michael Welzl <michawe@ifi.uio.no>= wrote:

So - looking at this thread, it seems that consensus= is against me =A0:-)

=A0

Hence I'd like to clarify - my concern was that = we're making the system too complex by involving a codec that reacts to= the congestion controller **when evaluating congestion control mechanisms*= *. I mean, once I've done a test, I'd like to know why I see the effects that I see, and which mechanism is to blame = for them.=A0This will get harder with this setup.

=A0

Let me give an example to explain my concern:=

=A0

Say, we create a test with a reactive codec over a c= ongestion controller, and in some network scenarios, we see oscillations: t= he congestion controller increased its rate, allowing the codec to switch t= o a higher encoding rate; this higher rate was too much, and so quite fast the congestion controller reduces its= rate again, hence the codec reacts and switches to a lower rate, and so fo= rth.

=A0

Now, if that is the test setup for evaluating a cong= estion controller, a conclusion from such a test could be that the congesti= on controller has to be stabilized. I would, however, argue that a congesti= on=A0controller should be as quick as it possibly can at seeking out available bandwidth, and hence such fluctua= tions are natural (*), and it's rather the job of the codec to dampen i= ts rate switching.

=A0

Either way, in this example test, we face a bad resu= lt, and two screws to tune to fix the problem - one on the side of the cong= estion control, and one on the side of the codec.

=A0

This is why I would prefer to evaluate congestion co= ntrols (again, not the whole system, to me that's a different evaluatio= n, and of course a better congestion control should lead to a better total = system) with a static traffic profile.

=A0

Is my concern unfounded? Is it a non-problem I'm= envisioning? =A0 (if so, see below for 2 more concerns =A0:-) =A0 )=

=A0

Cheers,

Michael

=A0

PS: =A0Concern #2:=A0we can expect=A0a static traffi= c profile feeding into a congestion controller to be relatively quickly don= e, but creating a test setup with a reactive codec is going to be much hard= er and take more time. Will we ever see it? When? Will it be easy to use?

PPS: Concern #3: the parameter space for tests might= expand quite significantly when we involve reactive codecs... this will ma= ke any evaluation harder, making the results harder to compare, resulting i= n more time necessary to come to a conclusion about which controller does a better job.

=A0

=A0

(*) TFRC is an argument to the contrary, but I haven= 't seen a single evaluation result that shows that its smooth rate is i= ndeed beneficial. On the contrary, we now seem to have some agreement that = TFRC isn't the best mechanism.

=A0

=A0

On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) wrot= e:



Agreed. The base layer has no flexibility = just like a flat non-scalable stream.

=A0

=A0

On 10/28/13, 7:45 PM, Bernard Aboba <bernard_aboba@= hotmail.com> wrote:

=A0

You're right that there is flexibility= in enhancement layers. But because of the layering structure, the base is = not flexible - since the enhancement layers depend on it, it is typically protected via FEC or RTX. This affects the viability of "= ;slow start" schemes as well other aspects - no point sending video at= all if you cannot support the base layer, at least.


On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> wrot= e:

This is true for simulcast layers, but not= necessarily scalable layers. For the latter, arbitrary rates can be achiev= ed within a limited range (like down to half the bitrate) by selectively dropping some packets of the highest enhancement layer with= minimal visual quality impact. If the stream is highly scalable (many laye= rs, which is rare), the limited range expands (like down to maybe a third, = quarter, or less of the bitrate). If the stream is coarsely scalable (e.g. two layers, which is common), dro= pping below the limited range incurs changing encoding parameters, at which= point arbitrary rates are again possible.

=A0

Mo

=A0

=A0

On 10/28/13, 5:58 PM, Bernard Aboba <bernard_aboba@= hotmail.com> wrote:

=A0

Colin said:

=A0<= /p>

=93Do you mean pre= paring the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?

=94<= /p>

=A0<= /p>

[BA] I like this approach= , because it somewhat approximates the situation of simulcast/layered codin= g.=A0 Previous work has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, so= as to be able to send at least one video stream as well as issues with TFR= FC) that would be likely to be missed in a model in which an encoder has fu= lly smooth rate control. =A0=A0

=A0

I agree with Colin. W= e should be focused on live encoding where the
encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any
real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> wrote:

On 27. okt. 2013, at = 12:33, Varun Singh <vsingh.ietf@gmail.com> wrote:

Now, next, what if we'd have a set of such seque= nces, and then stack
them over a codec that produces quite arbitrary bitrates, assuming that
the network can always follow it -


Do you mean preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?


I think that could be a very good idea!


I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and
congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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

=A0

=A0


--089e01536b7cd9203304e9e21520-- From ted.ietf@gmail.com Tue Oct 29 08:39:00 2013 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 BEF0711E8307 for ; Tue, 29 Oct 2013 08:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvvyFmWpI81U for ; Tue, 29 Oct 2013 08:38:57 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 44F2821E8157 for ; Tue, 29 Oct 2013 08:38:50 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so30090iec.34 for ; Tue, 29 Oct 2013 08:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y2Dmy8m0lmbyS7WlQ8JCmzYRFQIhxXfTXdWIShiF8L0=; b=xE0iANahIWHxzkzgH+NZw2hF8gyOuXDLCVnLgUmcQLsuviP0ic65vmoc82Gl0jbRI3 hSpbFURml+n5EjsnbNSiDvOBl20eZv4WpvlQfP/wQeMzT7EDQ7Ki0AL83jEphNCNXWBW qM+uU7IxhWvagg4G9/iGI4/7SoBSyesMFSuB6LIvWy9gJZhgyYfxIrj2Cl8GBolLiQNn J8kKILvWI7TYE6/wh9G+gM+yH/Wcuie0cAIKhQ9ijoZvgz5MwwKFwU+7FRZT0Y9n0znM hlfmdZEi7CvdplRtFWvYrUQDIVoVylS9zyXAbsBekw1dtJzNOzye7xkgjh77EQNhXz2m awig== MIME-Version: 1.0 X-Received: by 10.43.77.212 with SMTP id zj20mr101760icb.5.1383061129089; Tue, 29 Oct 2013 08:38:49 -0700 (PDT) Received: by 10.43.115.72 with HTTP; Tue, 29 Oct 2013 08:38:48 -0700 (PDT) In-Reply-To: <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> Date: Tue, 29 Oct 2013 08:38:48 -0700 Message-ID: From: Ted Hardie To: Colin Perkins Content-Type: multipart/alternative; boundary=047d7b45041e4d5a6104e9e303af Cc: rmcat WG , Michael Welzl Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 15:39:00 -0000 --047d7b45041e4d5a6104e9e303af Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Oct 29, 2013 at 2:31 AM, Colin Perkins wrote: > Michael, > > Your concern is why I think we need to test the codec and the congestion > control together. The dynamics of how, and importantly when, the codec ca= n > change its rate will be critical to the dynamics of the congestion contro= l. > This is especially true if we want to keep the latency low by avoiding > sender-side buffering to smooth the codec output to match the desired > sending rate. Testing congestion control without a codec will give us > something that doesn't respect the QoE concerns, and runs the risk of > producing an algorithm that is safe and responsive, but not useful for > interactive video. > > Hi Colin, Not to challenge your point on testing methodology, but to uplevel a bit for the benefit of those not as involved in WebRTC as you are: Please remember that there is no single codec that will provide a comprehensive test. The WebRTC framework is set up for codec agility, and we certainly expect different codecs to be negotiated in different circumstances; the decision next week is for a codec sufficient to avoid negotiation failure, not one that replaces that negotiation. So, please assume the congestion control mechanisms need to serve VP8 and H.264 and VP9 and H.265 and whatever else someone chooses. This system will not make a single choice. regards, Ted Hardie > Colin > > > On 29 Oct 2013, at 08:30, Michael Welzl wrote: > > So - looking at this thread, it seems that consensus is against me :-) > > Hence I'd like to clarify - my concern was that we're making the system > too complex by involving a codec that reacts to the congestion controller > **when evaluating congestion control mechanisms**. I mean, once I've done= a > test, I'd like to know why I see the effects that I see, and which > mechanism is to blame for them. This will get harder with this setup. > > Let me give an example to explain my concern: > > Say, we create a test with a reactive codec over a congestion controller, > and in some network scenarios, we see oscillations: the congestion > controller increased its rate, allowing the codec to switch to a higher > encoding rate; this higher rate was too much, and so quite fast the > congestion controller reduces its rate again, hence the codec reacts and > switches to a lower rate, and so forth. > > Now, if that is the test setup for evaluating a congestion controller, a > conclusion from such a test could be that the congestion controller has t= o > be stabilized. I would, however, argue that a congestion controller shoul= d > be as quick as it possibly can at seeking out available bandwidth, and > hence such fluctuations are natural (*), and it's rather the job of the > codec to dampen its rate switching. > > Either way, in this example test, we face a bad result, and two screws to > tune to fix the problem - one on the side of the congestion control, and > one on the side of the codec. > > This is why I would prefer to evaluate congestion controls (again, not th= e > whole system, to me that's a different evaluation, and of course a better > congestion control should lead to a better total system) with a static > traffic profile. > > Is my concern unfounded? Is it a non-problem I'm envisioning? (if so, > see below for 2 more concerns :-) ) > > Cheers, > Michael > > PS: Concern #2: we can expect a static traffic profile feeding into a > congestion controller to be relatively quickly done, but creating a test > setup with a reactive codec is going to be much harder and take more time= . > Will we ever see it? When? Will it be easy to use? > PPS: Concern #3: the parameter space for tests might expand quite > significantly when we involve reactive codecs... this will make any > evaluation harder, making the results harder to compare, resulting in mor= e > time necessary to come to a conclusion about which controller does a bett= er > job. > > > (*) TFRC is an argument to the contrary, but I haven't seen a single > evaluation result that shows that its smooth rate is indeed beneficial. O= n > the contrary, we now seem to have some agreement that TFRC isn't the best > mechanism. > > > On 29. okt. 2013, at 01:53, Mo Zanaty (mzanaty) wrote: > > Agreed. The base layer has no flexibility just like a flat non-scalable > stream. > > > On 10/28/13, 7:45 PM, Bernard Aboba wrote: > > You're right that there is flexibility in enhancement layers. But > because of the layering structure, the base is not flexible - since the > enhancement layers depend on it, it is typically protected via FEC or RTX= . > This affects the viability of "slow start" schemes as well other aspects = - > no point sending video at all if you cannot support the base layer, at > least. > > On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" > wrote: > > This is true for simulcast layers, but not necessarily scalable layers. > For the latter, arbitrary rates can be achieved within a limited range > (like down to half the bitrate) by selectively dropping some packets of t= he > highest enhancement layer with minimal visual quality impact. If the stre= am > is highly scalable (many layers, which is rare), the limited range expand= s > (like down to maybe a third, quarter, or less of the bitrate). If the > stream is coarsely scalable (e.g. two layers, which is common), dropping > below the limited range incurs changing encoding parameters, at which poi= nt > arbitrary rates are again possible. > > Mo > > > On 10/28/13, 5:58 PM, Bernard Aboba wrote: > > Colin said: **** > ** ** > =93Do you mean preparing the same video sequence at multiple rates and th= e > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence?**** > =94**** > ** ** > [BA] I like this approach, because it somewhat approximates the situation > of simulcast/layered coding. Previous work has indicated a number of > considerations that arise in those implementations (such as the need for > rapid rampup, so as to be able to send at least one video stream as well = as > issues with TFRFC) that would be likely to be missed in a model in which = an > encoder has fully smooth rate control. **** > > ** ** > > I agree with Colin. We should be focused on live encoding where the > encoder rate control is highly granular (often fully smooth) and coupled > to the network congestion control, not pre-encoded streaming of a small > set of fixed bitrates like DASH/HLS. > > A more formal approach to the problem would be to decompose the factors > contributing to the final rate placed onto the network. > 1. Video content / source statistics, using a large set of representative > sequences. An estimate of the entropy per frame could simply be the > encoded frame size using constant quantization, i.e. no encoder rate > control. > 2. Video encoder rate control behavior, which modulates the source > statistics to fit into network constraints over rather large time > intervals (>0.5s). > 3. Network transmission pacing / shaper, which smooths out bursts in > encoder output to fit into network constraints over fine time intervals > (<0.5s). > > It should be possible to model all three in an abstract way to arrive at > some statistical model that can then be used for all tests without any > real video content or encoding (to avoid introducing noise in comparisons > if there was any variability in any of the factors). > > Mo > > > > On 10/28/13, 1:49 PM, Colin Perkins wrote: > > On 27 Oct 2013, at 11:50, Michael Welzl wrote:**** > > On 27. okt. 2013, at 12:33, Varun Singh wrote:***= * > > Now, next, what if we'd have a set of such sequences, and then stack > them over a codec that produces quite arbitrary bitrates, assuming that > the network can always follow it -**** > > > Do you mean preparing the same video sequence at multiple rates and the > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence?**** > > I think that could be a very good idea!**** > > > I'd be more interested in a standard set of *uncompressed* video test > sequences, that we can use to test the combination of video codec and > congestion control. If we're building something for interactive video > congestion control we should assume live encoding, with the codec > potentially having the flexibility to react to the network, and our > testbed ought to reflect that. > > -- > Colin Perkins > http://csperkins.org/ > > > --047d7b45041e4d5a6104e9e303af Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 29, 2013 at 2:3= 1 AM, Colin Perkins <csp@csperkins.org> wrote:
Michael,=

Your concern is why I think we need to test the codec a= nd the congestion control together. The dynamics of how, and importantly wh= en, the codec can change its rate will be critical to the dynamics of the c= ongestion control. This is especially true if we want to keep the latency l= ow by avoiding sender-side buffering to smooth the codec output to match th= e desired sending rate. Testing congestion control without a codec will giv= e us something that doesn't respect the QoE concerns, and runs the risk= of producing an algorithm that is safe and responsive, but not useful for = interactive video.


Hi Colin,

Not to challenge your point o= n testing methodology, but to uplevel a bit for the benefit of
those no= t as involved in WebRTC as you are:=A0 Please remember that there is no single codec that will provide a comprehensive test.=A0 The WebRTC framewor= k is set up
for codec agility, and we certainly expect differ= ent codecs to be negotiated in different
circumstances; the decision nex= t week is for a codec sufficient to avoid negotiation
failure, not one that replaces that negotiation.

So, please assume t= he congestion control mechanisms need to serve VP8 and H.264
and VP9 and= H.265 and whatever else someone chooses.=A0 This system will not make
a single choice.

regards,

Ted Hardie


= =A0
Colin

<= div>
On 29 Oct 2013, at 08:30, Michael Welzl <michawe@ifi.uio.no> wrote= :
So - looking = at this thread, it seems that consensus is against me =A0:-)

=
Hence I'd like to clarify - my concern was that we're making t= he system too complex by involving a codec that reacts to the congestion co= ntroller **when evaluating congestion control mechanisms**. I mean, once I&= #39;ve done a test, I'd like to know why I see the effects that I see, = and which mechanism is to blame for them.=A0This will get harder with this = setup.

Let me give an example to explain my concern:

Say, we create a test with a reactive codec over a congesti= on controller, and in some network scenarios, we see oscillations: the cong= estion controller increased its rate, allowing the codec to switch to a hig= her encoding rate; this higher rate was too much, and so quite fast the con= gestion controller reduces its rate again, hence the codec reacts and switc= hes to a lower rate, and so forth.

Now, if that is the test setup for evaluating a congest= ion controller, a conclusion from such a test could be that the congestion = controller has to be stabilized. I would, however, argue that a congestion= =A0controller should be as quick as it possibly can at seeking out availabl= e bandwidth, and hence such fluctuations are natural (*), and it's rath= er the job of the codec to dampen its rate switching.

Either way, in this example test, we face a bad result,= and two screws to tune to fix the problem - one on the side of the congest= ion control, and one on the side of the codec.

This is why I would prefer to evaluate congestion controls (again, not the = whole system, to me that's a different evaluation, and of course a bett= er congestion control should lead to a better total system) with a static t= raffic profile.

Is my concern unfounded? Is it a non-problem I'm en= visioning? =A0 (if so, see below for 2 more concerns =A0:-) =A0 )

Cheers,
Michael

PS: =A0C= oncern #2:=A0we can expect=A0a static traffic profile feeding into a conges= tion controller to be relatively quickly done, but creating a test setup wi= th a reactive codec is going to be much harder and take more time. Will we = ever see it? When? Will it be easy to use?
PPS: Concern #3: the parameter space for tests might expand quite sign= ificantly when we involve reactive codecs... this will make any evaluation = harder, making the results harder to compare, resulting in more time necess= ary to come to a conclusion about which controller does a better job.


(*) TFRC is an argument to the contrary,= but I haven't seen a single evaluation result that shows that its smoo= th rate is indeed beneficial. On the contrary, we now seem to have some agr= eement that TFRC isn't the best mechanism.


On 29. okt. 2013, at 01:53, Mo= Zanaty (mzanaty) wrote:

Agreed. The base layer has no flexibility just like a flat non-scalabl= e stream.


On 10/28/13, 7:45 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

You're right that there is flexibility in enhancement layers. But = because of the layering structure, the base is not flexible - since the enh= ancement layers depend on it, it is typically protected via FEC or RTX. Thi= s affects the viability of "slow start" schemes as well other aspects - no point sending video at all if you canno= t support the base layer, at least.

On Oct 28, 2013, at 3:10 PM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> wrot= e:

This is true for simulcast layers, but not necessarily scalable layers= . For the latter, arbitrary rates can be achieved within a limited range (l= ike down to half the bitrate) by selectively dropping some packets of the h= ighest enhancement layer with minimal visual quality impact. If the stream is highly scalable (many layers, whic= h is rare), the limited range expands (like down to maybe a third, quarter,= or less of the bitrate). If the stream is coarsely scalable (e.g. two laye= rs, which is common), dropping below the limited range incurs changing encoding parameters, at which point arbi= trary rates are again possible.

Mo


On 10/28/13, 5:58 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

Colin said:
=A0
=93Do you mean prepa= ring the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?
=94=
=A0<= /div>
[BA] I like this approach, because it some= what approximates the situation of simulcast/layered coding.=A0 Previous wo= rk has indicated a number of considerations that arise in those implementations (such as the need for rapid rampup, so= as to be able to send at least one video stream as well as issues with TFR= FC) that would be likely to be missed in a model in which an encoder has fu= lly smooth rate control. =A0=A0

=A0

I agree with Col= in. We should be focused on live encoding where the
encoder rate control is highly granular (often fully smooth) and coupled to the network congestion control, not pre-encoded streaming of a small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of representative sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive at some statistical model that can then be used for all tests without any
real video content or encoding (to avoid introducing noise in comparisons if there was any variability in any of the factors).

Mo



On 10/28/13, 1:49 PM, Colin Perkins <csp@csperkins.org> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <michawe@ifi.uio.no> wrote:

On 27. okt. 2013, at= 12:33, Varun Singh <vsingh.ietf@gmail.com> wrote:

Now, next, what if we'd have a set of such seque= nces, and then stack
them over a codec that produces quite arbitrary bitrates, assuming that
the network can always follow it -

Do you mean preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?

I think that could be a very good idea!


I'd be more interested in a standard set of *uncompressed* video test sequences, that we can use to test the combination of video codec and
congestion control. If we're building something for interactive video congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

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



--047d7b45041e4d5a6104e9e303af-- From csp@csperkins.org Tue Oct 29 09:03:05 2013 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 6419521F9DD6 for ; Tue, 29 Oct 2013 09:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZryhpm60vPD for ; Tue, 29 Oct 2013 09:03:04 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A3311E8131 for ; Tue, 29 Oct 2013 09:03:02 -0700 (PDT) Received: from [146.191.210.64] (port=52400 helo=mangole.uws.loc) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VbBkx-0003Tz-Gl; Tue, 29 Oct 2013 16:03:00 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_3C8C23F5-6017-49E7-BA11-6B758AF37F0B" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: Date: Tue, 29 Oct 2013 16:02:56 +0000 Message-Id: <923B9C2A-9055-4E33-94C6-C82A502AD57A@csperkins.org> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124D97@xmb-rcd-x14.cisco.com> <8372589D-DFAE-4560-BE06-E0D21DAFF47C@ifi.uio.no> <73EAAE7B-3DF8-49EB-9359-4643F9CA655B@csperkins.org> To: Ted Hardie X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rmcat WG Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 16:03:05 -0000 --Apple-Mail=_3C8C23F5-6017-49E7-BA11-6B758AF37F0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ted, On 29 Oct 2013, at 15:38, Ted Hardie wrote: > On Tue, Oct 29, 2013 at 2:31 AM, Colin Perkins = wrote: > Your concern is why I think we need to test the codec and the = congestion control together. The dynamics of how, and importantly when, = the codec can change its rate will be critical to the dynamics of the = congestion control. This is especially true if we want to keep the = latency low by avoiding sender-side buffering to smooth the codec output = to match the desired sending rate. Testing congestion control without a = codec will give us something that doesn't respect the QoE concerns, and = runs the risk of producing an algorithm that is safe and responsive, but = not useful for interactive video. >=20 >=20 > Not to challenge your point on testing methodology, but to uplevel a = bit for the benefit of those not as involved in WebRTC as you are: = Please remember that there is no single codec that will provide a = comprehensive test. The WebRTC framework is set up for codec agility, = and we certainly expect different codecs to be negotiated in different > circumstances; the decision next week is for a codec sufficient to = avoid negotiation failure, not one that replaces that negotiation. >=20 > So, please assume the congestion control mechanisms need to serve VP8 = and H.264 and VP9 and H.265 and whatever else someone chooses. This = system will not make a single choice. Absolutely agree. That said, I tend to suspect that a congestion control algorithm that = can react to the dynamics of one modern codec will likely do a = reasonable job of adapting to another codec (possibly excepting layered = vs. non-layered codecs), and that most of the benefit comes from testing = with some codec, and paying attention to the impact of the rate = variation on QoE, rather than just testing the impact on the network. --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_3C8C23F5-6017-49E7-BA11-6B758AF37F0B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252 Hi Ted,

On Tue, Oct 29, 2013 at 2:31 AM, Colin Perkins <csp@csperkins.org> wrote:
Your concern is why I think we need to test the codec and the congestion control together. The dynamics of how, and importantly when, the codec can change its rate will be critical to the dynamics of the congestion control. This is especially true if we want to keep the latency low by avoiding sender-side buffering to smooth the codec output to match the desired sending rate. Testing congestion control without a codec will give us something that doesn't respect the QoE concerns, and runs the risk of producing an algorithm that is safe and responsive, but not useful for interactive video.


Not to challenge your point on testing methodology, but to uplevel a bit for the benefit of those not as involved in WebRTC as you are:  Please remember that there is no single codec that will provide a comprehensive test.  The WebRTC framework is set up for codec agility, and we certainly expect different codecs to be negotiated in different
circumstances; the decision next week is for a codec sufficient to avoid negotiation failure, not one that replaces that negotiation.

So, please assume the congestion control mechanisms need to serve VP8 and H.264 and VP9 and H.265 and whatever else someone chooses.  This system will not make a single choice.

Absolutely agree.

That said, I tend to suspect that a congestion control algorithm that can react to the dynamics of one modern codec will likely do a reasonable job of adapting to another codec (possibly excepting layered vs. non-layered codecs), and that most of the benefit comes from testing with some codec, and paying attention to the impact of the rate variation on QoE, rather than just testing the impact on the network.

-- 
Colin Perkins



--Apple-Mail=_3C8C23F5-6017-49E7-BA11-6B758AF37F0B-- From xiaoqzhu@cisco.com Tue Oct 29 09:50:06 2013 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 E042D21F9B7E for ; Tue, 29 Oct 2013 09:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk0ftv2kd5E3 for ; Tue, 29 Oct 2013 09:50:01 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D6BEE11E8166 for ; Tue, 29 Oct 2013 09:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4066; q=dns/txt; s=iport; t=1383065312; x=1384274912; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WtDZzuoO0YFK+SHsuPT5gy12KJb7eMzdFqwQm2tID9s=; b=gizYB7BWm6buGxRxxH9sHYk/qOUfbX7lS0A9ZgyT87O6gSD7DXmZxWYG EJAhOEfW9039b4RIQ0FFpYwgE6GghQgsFQ8SiRsEJ+FEsMdTvhXeVJiK4 zOZ2iw6hhY16+Fgp6SmsqLGO/s5KCagdDyEMO23o9Wwa9TxkuP/NX1I5j M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAGTmb1KtJXG//2dsb2JhbABZFoJQIThUvzWBKhZ0giUBAQECAQF5BQsCAQgOCgokIRElAgQOBQgBh2wDCQYBDLAlDYlrjFqCOgIxAgWDH4ENA5YfgxqLIgOFNIFogT6CKg X-IronPort-AV: E=Sophos;i="4.93,594,1378857600"; d="scan'208";a="275073648" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 29 Oct 2013 16:48:09 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9TGm8rs030871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 16:48:08 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 11:48:08 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Varun Singh Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1A0MgwVs6QKB+UiBda2MQkwFlZoK4IGAgAEAFoCAAFhpgA== Date: Tue, 29 Oct 2013 16:48:07 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.12.143] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rmcat WG , "Mo Zanaty \(mzanaty\)" , Michael Welzl , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 16:50:06 -0000 Thanks for the pointer, Varun. This is helpful in putting together a compl= ete systems (CC + live encoding) for more realistic evaluations. Will give tha= t a=20 try on my end =85 Best, Xiaoqing On Oct 29, 2013, at 6:31 AM, Varun Singh wrote: > Hi, >=20 >> Also, if we go for the approach of using uncompressed test video sequenc= e >> for testing the combination of video codec and congestion control, we sh= ould >> also recommend a reference codec and default configurations. So that foc= us >> of the evaluations remains on the congestion control module. What do fo= lks >> think of x264 (http://www.videolan.org/developers/x264.html)? >=20 > In [1], we used gstreamer to set and get the encoding bit rate. We chose = to > use gstreamer instead of using x264 directly was the idea to easily swap > it out with libvpx. We haven't tested this yet but I suppose it should > be possible. >=20 > In our experiments, we just set the application constraints (e.g., > video resolution, > frame rate, etc) and let the codec parameters set as default. I suppose t= he same > would be true if we just swapped out x264 for vpx? >=20 > [1] http://arxiv.org/pdf/1310.1582v1.pdf See section 6.1, we describe > the interaction > between the APIs between >=20 >>=20 >> Best, >> Xiaoqing >>=20 >>=20 >>=20 >> On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) wro= te: >>=20 >> I agree with Colin. We should be focused on live encoding where the >> encoder rate control is highly granular (often fully smooth) and coupled >> to the network congestion control, not pre-encoded streaming of a small >> set of fixed bitrates like DASH/HLS. >>=20 >> A more formal approach to the problem would be to decompose the factors >> contributing to the final rate placed onto the network. >> 1. Video content / source statistics, using a large set of representativ= e >> sequences. An estimate of the entropy per frame could simply be the >> encoded frame size using constant quantization, i.e. no encoder rate >> control. >> 2. Video encoder rate control behavior, which modulates the source >> statistics to fit into network constraints over rather large time >> intervals (>0.5s). >> 3. Network transmission pacing / shaper, which smooths out bursts in >> encoder output to fit into network constraints over fine time intervals >> (<0.5s). >>=20 >> It should be possible to model all three in an abstract way to arrive at >> some statistical model that can then be used for all tests without any >> real video content or encoding (to avoid introducing noise in comparison= s >> if there was any variability in any of the factors). >>=20 >> Mo >>=20 >>=20 >>=20 >> On 10/28/13, 1:49 PM, Colin Perkins wrote: >>=20 >> On 27 Oct 2013, at 11:50, Michael Welzl wrote: >>=20 >> On 27. okt. 2013, at 12:33, Varun Singh wrote: >>=20 >> Now, next, what if we'd have a set of such sequences, and then stack >> them over a codec that produces quite arbitrary bitrates, assuming that >> the network can always follow it - >>=20 >>=20 >> Do you mean preparing the same video sequence at multiple rates and the >> congestion controller picking the appropriate media rate that fits its >> estimate? ie rate switch between different media rates of the same >> sequence? >>=20 >>=20 >> I think that could be a very good idea! >>=20 >>=20 >> I'd be more interested in a standard set of *uncompressed* video test >> sequences, that we can use to test the combination of video codec and >> congestion control. If we're building something for interactive video >> congestion control we should assume live encoding, with the codec >> potentially having the flexibility to react to the network, and our >> testbed ought to reflect that. >>=20 >> -- >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ From xiaoqzhu@cisco.com Tue Oct 29 09:55:32 2013 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 7D1CE21F9D9C for ; Tue, 29 Oct 2013 09:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTI+QP8fjiMK for ; Tue, 29 Oct 2013 09:55:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9301A21F9DFA for ; Tue, 29 Oct 2013 09:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4676; q=dns/txt; s=iport; t=1383065552; x=1384275152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AVHOnp7K2z1qUObhD5DoUm+JO3cz1QrBBtoziFiF9Xc=; b=SFsn6yXeGtTZg5afV3eYIhHD4ZCQz837ig/vi9tLXVr10ahPFRK8lpe7 UL/xp9YJXkEQTOhOHJA0h7ZiuG/t9yIoX02ff7/gHrezebL5G622GUD09 iYQ/oNiMjeKuvo815zcaIoH6hM0SEj8vb+4ndcxpoIw4k70ZBY0jPqwIC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFANvmb1KtJXHA/2dsb2JhbABZFoJQIThUvzWBKhZ0giUBAQEDAW4LBQsCAQgOCgokIRElAgQOBQgBh2wDCQYBDLAkDYlrjFqBJIEWAjECBYMfgQ0DiQeNGIMaiyIDhTSBaIE+gXE5 X-IronPort-AV: E=Sophos;i="4.93,594,1378857600"; d="scan'208";a="278089341" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 29 Oct 2013 16:52:29 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9TGqS0Q016420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 16:52:28 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 11:52:28 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Varun Singh Thread-Topic: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) Thread-Index: AQHO1A0MgwVs6QKB+UiBda2MQkwFlZoK4IGAgAEBaACAAFhNgA== Date: Tue, 29 Oct 2013 16:52:27 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.12.143] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <826475A99DC8A84AB897B28A2FA2444F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rmcat WG , "Mo Zanaty \(mzanaty\)" , Michael Welzl , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 16:55:32 -0000 Hi Varun,=20 Regarding your comments, we will share a concrete example of how we modeled the video traffic in our NADA simulations at Vancouver. Once I put togethe= r the=20 slides/write-up (working on it right now), can also share it on the mailing= list first to solicit comments.=20 =20 Thanks, Xiaoqing On Oct 29, 2013, at 6:36 AM, Varun Singh wrote: > Hi Xiaoqing, >=20 > A couple of comments inline. >=20 > On Mon, Oct 28, 2013 at 10:15 PM, Xiaoqing Zhu (xiaoqzhu) > wrote: >> Agree with Colin and Mo. >>=20 >> For a statistical video traffic model, I would propose to break down the= 2nd >> point (encoder rate control) in Mo's list further, to three sub-componen= ts: >>=20 >> a) delayed response to a rate change request (e.g., > 0.5s) >> b) deviations from the requested rate (maybe as randomly fluctuating aro= und >> the target?) >=20 > The original email lists questions for modeling video traffic, if you hav= e > concrete suggestions on values, could you put them together in an email? >=20 >> c) the different frame types or coding modes inside the encoder will yie= ld >> some encoded >> frames much larger than others. This will lead to burstiness on time sca= le >=20 > Any idea on how to model this? i.e., how large (in size) should these > packets be to the others? >=20 >> of frame intervals >> (typically 33ms), and later smoothed out by the pacing/shaper. >=20 > Agree, with the pacing/shaper. >=20 >>=20 >> Also, if we go for the approach of using uncompressed test video sequenc= e >> for testing the combination of video codec and congestion control, we sh= ould >> also recommend a reference codec and default configurations. So that foc= us >> of the evaluations remains on the congestion control module. What do fo= lks >> think of x264 (http://www.videolan.org/developers/x264.html)? >>=20 >> Best, >> Xiaoqing >>=20 >>=20 >>=20 >> On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) wro= te: >>=20 >> I agree with Colin. We should be focused on live encoding where the >> encoder rate control is highly granular (often fully smooth) and coupled >> to the network congestion control, not pre-encoded streaming of a small >> set of fixed bitrates like DASH/HLS. >>=20 >> A more formal approach to the problem would be to decompose the factors >> contributing to the final rate placed onto the network. >> 1. Video content / source statistics, using a large set of representativ= e >> sequences. An estimate of the entropy per frame could simply be the >> encoded frame size using constant quantization, i.e. no encoder rate >> control. >> 2. Video encoder rate control behavior, which modulates the source >> statistics to fit into network constraints over rather large time >> intervals (>0.5s). >> 3. Network transmission pacing / shaper, which smooths out bursts in >> encoder output to fit into network constraints over fine time intervals >> (<0.5s). >>=20 >> It should be possible to model all three in an abstract way to arrive at >> some statistical model that can then be used for all tests without any >> real video content or encoding (to avoid introducing noise in comparison= s >> if there was any variability in any of the factors). >>=20 >> Mo >>=20 >>=20 >>=20 >> On 10/28/13, 1:49 PM, Colin Perkins wrote: >>=20 >> On 27 Oct 2013, at 11:50, Michael Welzl wrote: >>=20 >> On 27. okt. 2013, at 12:33, Varun Singh wrote: >>=20 >> Now, next, what if we'd have a set of such sequences, and then stack >> them over a codec that produces quite arbitrary bitrates, assuming that >> the network can always follow it - >>=20 >>=20 >> Do you mean preparing the same video sequence at multiple rates and the >> congestion controller picking the appropriate media rate that fits its >> estimate? ie rate switch between different media rates of the same >> sequence? >>=20 >>=20 >> I think that could be a very good idea! >>=20 >>=20 >> I'd be more interested in a standard set of *uncompressed* video test >> sequences, that we can use to test the combination of video codec and >> congestion control. If we're building something for interactive video >> congestion control we should assume live encoding, with the codec >> potentially having the flexibility to react to the network, and our >> testbed ought to reflect that. >>=20 >> -- >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ From dave.taht@gmail.com Tue Oct 29 11:29:44 2013 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 5D11521F8E97 for ; Tue, 29 Oct 2013 11:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csPQQWG9tpXl for ; Tue, 29 Oct 2013 11:29:43 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C09F521F9E3A for ; Tue, 29 Oct 2013 11:29:42 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id n12so256613wgh.35 for ; Tue, 29 Oct 2013 11:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=h8WlhIX8qGmGs8F4BHTyW8UqaBraHuukdgeGRbYCpiE=; b=qm32QQglrZm1Fx8pLJqI1pEm3pIMkdTZb/HgEzvliEZtKio/clwnLCAGNLW784mUck bb8tGpE0xQ+LtOAuUebKPQd1JSiOZtGMbnw+464sKbH8lgryXABvB71oyx8CIQ0jW8iP yAn7JkzW3x09Mc+Ckc4k3xOxyrQU6YWeLPEH/TwYSiJDtcauG8XBR2/exHVPpKn2ozA8 APz1HOaWP3oTrjbVZK1iHE3EUcmLpkxpVqKn8Kg0uXL+OUHzUn2JUiEPPj91vVHDBxWD eYxsB6T0DQ17dSHjL4MbIYhNZZYjzbVOijVhVww0Got8wWToMaIqBTRIywqYgzAqdHdH Pk2g== MIME-Version: 1.0 X-Received: by 10.180.98.105 with SMTP id eh9mr14114912wib.56.1383071378207; Tue, 29 Oct 2013 11:29:38 -0700 (PDT) Received: by 10.217.67.202 with HTTP; Tue, 29 Oct 2013 11:29:38 -0700 (PDT) In-Reply-To: References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> Date: Tue, 29 Oct 2013 11:29:38 -0700 Message-ID: From: Dave Taht To: "Xiaoqing Zhu (xiaoqzhu)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Colin Perkins , "Mo Zanaty \(mzanaty\)" , Michael Welzl , Varun Singh Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 18:29:44 -0000 On Tue, Oct 29, 2013 at 9:52 AM, Xiaoqing Zhu (xiaoqzhu) wrote: > Hi Varun, > > Regarding your comments, we will share a concrete example of how we model= ed > the video traffic in our NADA simulations at Vancouver. Once I put toget= her the > slides/write-up (working on it right now), can also share it on the maili= ng list first > to solicit comments. > > Thanks, > Xiaoqing > > > On Oct 29, 2013, at 6:36 AM, Varun Singh wrote: > >> Hi Xiaoqing, >> >> A couple of comments inline. >> >> On Mon, Oct 28, 2013 at 10:15 PM, Xiaoqing Zhu (xiaoqzhu) >> wrote: >>> Agree with Colin and Mo. >>> >>> For a statistical video traffic model, I would propose to break down th= e 2nd >>> point (encoder rate control) in Mo's list further, to three sub-compone= nts: >>> >>> a) delayed response to a rate change request (e.g., > 0.5s) >>> b) deviations from the requested rate (maybe as randomly fluctuating ar= ound >>> the target?) >> >> The original email lists questions for modeling video traffic, if you ha= ve >> concrete suggestions on values, could you put them together in an email? >> >>> c) the different frame types or coding modes inside the encoder will yi= eld >>> some encoded >>> frames much larger than others. This will lead to burstiness on time sc= ale >> >> Any idea on how to model this? i.e., how large (in size) should these >> packets be to the others? >> >>> of frame intervals >>> (typically 33ms), and later smoothed out by the pacing/shaper. >> >> Agree, with the pacing/shaper. >> >>> >>> Also, if we go for the approach of using uncompressed test video sequen= ce >>> for testing the combination of video codec and congestion control, we s= hould >>> also recommend a reference codec and default configurations. So that fo= cus >>> of the evaluations remains on the congestion control module. What do f= olks >>> think of x264 (http://www.videolan.org/developers/x264.html)? >>> >>> Best, >>> Xiaoqing >>> >>> >>> >>> On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) wr= ote: >>> >>> I agree with Colin. We should be focused on live encoding where the >>> encoder rate control is highly granular (often fully smooth) and couple= d >>> to the network congestion control, not pre-encoded streaming of a small >>> set of fixed bitrates like DASH/HLS. >>> >>> A more formal approach to the problem would be to decompose the factors >>> contributing to the final rate placed onto the network. >>> 1. Video content / source statistics, using a large set of representati= ve >>> sequences. An estimate of the entropy per frame could simply be the >>> encoded frame size using constant quantization, i.e. no encoder rate >>> control. >>> 2. Video encoder rate control behavior, which modulates the source >>> statistics to fit into network constraints over rather large time >>> intervals (>0.5s). >>> 3. Network transmission pacing / shaper, which smooths out bursts in >>> encoder output to fit into network constraints over fine time intervals >>> (<0.5s). >>> >>> It should be possible to model all three in an abstract way to arrive a= t >>> some statistical model that can then be used for all tests without any >>> real video content or encoding (to avoid introducing noise in compariso= ns >>> if there was any variability in any of the factors). >>> >>> Mo >>> >>> >>> >>> On 10/28/13, 1:49 PM, Colin Perkins wrote: >>> >>> On 27 Oct 2013, at 11:50, Michael Welzl wrote: >>> >>> On 27. okt. 2013, at 12:33, Varun Singh wrote: >>> >>> Now, next, what if we'd have a set of such sequences, and then stack >>> them over a codec that produces quite arbitrary bitrates, assuming that >>> the network can always follow it - >>> >>> >>> Do you mean preparing the same video sequence at multiple rates and the >>> congestion controller picking the appropriate media rate that fits its >>> estimate? ie rate switch between different media rates of the same >>> sequence? >>> >>> >>> I think that could be a very good idea! >>> >>> >>> I'd be more interested in a standard set of *uncompressed* video test >>> sequences, that we can use to test the combination of video codec and >>> congestion control. If we're building something for interactive video >>> congestion control we should assume live encoding, with the codec >>> potentially having the flexibility to react to the network, and our >>> testbed ought to reflect that. >>> >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>> >>> >>> >>> >>> >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ > I would be very happy if also along the way, while exploring e2e cc techniques for webrtc, that folk also tried the various aqm and packet scheduling techniques being developed and deployed, other than drop tail, notably wred, fq_codel, sqf & pie. That's a two way street as I'd also very much like the aqm developers paying attention here also... (I did some early work with webrtc + fq_codel earlier this year but it was too buggy to get anything publishable.) --=20 Dave T=E4ht From dave.taht@gmail.com Tue Oct 29 11:33:16 2013 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 22C6021F9F45; Tue, 29 Oct 2013 11:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00C-rx1PhhTD; Tue, 29 Oct 2013 11:33:14 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8B411E8185; Tue, 29 Oct 2013 11:33:10 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so263430wgh.27 for ; Tue, 29 Oct 2013 11:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=0OykHK2Y/4qJTYzx0R9umLQO+V0KuDTm82t6VZ2tmOA=; b=hJriR93e8N2wgZ8uzfShEOSiGU5hkH7OrEq3Dpf+CUrHT9Uz3DF/2Zo7agjSj+ULyT OekOi+K9BxVtzyrcprjVRytSg5G/lFixsUsqZw8dRZxhTxfkHL6qZGl2YI0u2nCYEFcw QHJRZGwgHzhpm253rvqghM/NZPHOaQaDKt5Y73aIXq130yVxBwBJb+xSWdjDMJ+azVOu MGL/IEMxRL8bE462z9W/T1kllKokNNUlQ7T/vxqWh89GhMf4stUtrNxpAl/rOWljBKqS +pphj9BSIvRZ4l/N7s5QNYOSSMMxDH6tfYKktWEmmQzlFxvybmSQnONf9X6l6f/F8W14 j1rQ== MIME-Version: 1.0 X-Received: by 10.180.184.14 with SMTP id eq14mr676140wic.56.1383071587668; Tue, 29 Oct 2013 11:33:07 -0700 (PDT) Received: by 10.217.67.202 with HTTP; Tue, 29 Oct 2013 11:33:07 -0700 (PDT) Date: Tue, 29 Oct 2013 11:33:07 -0700 Message-ID: From: Dave Taht To: "rmcat@ietf.org" , rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [rmcat] compressed codec-free webrtc? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 18:33:16 -0000 In having my eyes glaze over at the codec debate I found myself wondering to what extent anyone was pursuing truly low latency video and audio, along the lines of what the lola project has been doing for collaborative concerts. See: http://www.conts.it/artistica/lola-project They ship raw audio and raw video, they actually use cameras where they can get at scanlines and ship that (saving 16ms) So I'm ignorant of what webrtc can do is there a codec selection (yuv? 48 bit audio? for the rawest video and audio possible?) All the extra encoding steps we take today induce extra latency, and available bandwidth continues to increase... and from a cc perspective if you drop some bits from a scanline that's not a problem, but from audio it's a huge deal.... --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From juberti@google.com Tue Oct 29 11:46:09 2013 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 602FB11E81A0 for ; Tue, 29 Oct 2013 11:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYG44rqjBcGX for ; Tue, 29 Oct 2013 11:46:08 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2B911E824D for ; Tue, 29 Oct 2013 11:46:07 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id oz11so221155veb.8 for ; Tue, 29 Oct 2013 11:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H850kbTC9GrNdsW4BMKLuTfzkmwd0BV8JcrpUvFYvso=; b=CIVJmdegnt0geJYBKAb6xiVwsi8b3j5aLid6uakqa+vB3ahcMVeLz9IPXsdlR11lIH wocJMMbffh6T4zRl64ZnGX9GaCAu1HYuX/c6jjJM3XU2M/yr6h8LE83jVlAeJZzERiCx V7qjt/+CYICRP6itBzMX5pu4Cd8cawb/hNUQxzAjlD1Hd/um3PLFw/njeYrPtTCdxeR/ rrHBlOQ/7nCvlQ1gvldH/byQn2v7U37hDIClGKVx+HtDyFqSfw2ekIZpYLz6BVGgwnJg zjcleiLDVQH9NA+SQP93T2rIkPfWdAzFYxFBeqd8jpbjgIBrhVDyzmzcomJa+FnwEYZL xMVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H850kbTC9GrNdsW4BMKLuTfzkmwd0BV8JcrpUvFYvso=; b=kDKpJAh7MPjD9DKU94pA5JCY7jcWqrDmveJpKCgZ+A/lUy5z480oax5tn3LE+z/Yni I0wHq6HMW+YXf92AF/7MJr2C8dthqCkEWIrmagGGYyehq8Ds40M439a/5+/R6G3OWt7b IvP7wcbkn+ZtjOqJA2xPqIpHLjmiGIx47Z2RFrJNVsxAXRqlKk4yGfyxkXE/K6wt9DXY uIlfOZF7zDCcEyhV+RpmxGom5gSVTUoC7FjKyXr7n3h5cuA7ZdHI6cs9U0tCMavENJad bACZg+QfIYhPCmIPIFSmiHFuuaCDIgBk6CShkHGe3eC8FJhReJGtrT9DUxt7moWXLiqy lWKQ== X-Gm-Message-State: ALoCoQmQB7ASgiN9dQ36olMCwiO+4W6iUrcZNNapOcC+F44hzrbH3OL6zmpxGNolki6kSz+JcZlidRxXog4TkCT+oB9es7VQGiQwwWPlKMO35LboDyBnNfBzS3vr+cvcf3wzZa+d/VAILEBinaUuGyAm/TLMi0unxxb9z9KMKwgKj9qF/8Ed8bX+Ri3eEtC8UxY7E3oDz0HR X-Received: by 10.52.37.36 with SMTP id v4mr364818vdj.54.1383072366203; Tue, 29 Oct 2013 11:46:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Tue, 29 Oct 2013 11:45:45 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 29 Oct 2013 11:45:45 -0700 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=20cf307812b218d81604e9e5a109 Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rmcat] compressed codec-free webrtc? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 18:46:09 -0000 --20cf307812b218d81604e9e5a109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Uncompressed 720p30 (I420) is ~330 Mbps, so even though bandwidth continues to increase, we're still not at the point where we no longer need codecs (in the general case). On Tue, Oct 29, 2013 at 11:33 AM, Dave Taht wrote: > In having my eyes glaze over at the codec debate I found myself > wondering to what extent anyone was pursuing truly low latency video > and audio, along the lines of what the lola project has been doing for > collaborative concerts. > > See: > > http://www.conts.it/artistica/lola-project > > They ship raw audio and raw video, they actually use cameras where > they can get at scanlines and ship that (saving 16ms) > > So I'm ignorant of what webrtc can do is there a codec selection (yuv? > 48 bit audio? for the rawest video and audio possible?) All the extra > encoding steps we take today induce extra latency, and available > bandwidth continues to increase... and from a cc perspective if you > drop some bits from a scanline that's not a problem, but from audio > it's a huge deal.... > > > -- > Dave T=C3=A4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > --20cf307812b218d81604e9e5a109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Uncompressed 720p30 (I420) is ~330 Mbps, so even though ba= ndwidth continues to increase, we're still not at the point where we no= longer need codecs (in the general case).
=

On Tue, Oct 29, 2013 at 11:33 AM, Dave Taht = <dave.taht@gmail.com> wrote:
In having my eyes glaze over at the codec debate I found myself
wondering to what extent anyone was pursuing truly low latency video
and audio, along the lines of what the lola project has been doing for
collaborative concerts.

See:

ht= tp://www.conts.it/artistica/lola-project

They ship raw audio and raw video, they actually use cameras where
they can get at scanlines and ship that (saving 16ms)

So I'm ignorant of what webrtc can do is there a codec selection (yuv?<= br> 48 bit audio? for the rawest video and audio possible?) All the extra
encoding steps we take today induce extra latency, and available
bandwidth continues to increase... and from a cc perspective if you
drop some bits from a scanline that's not a problem, but from audio
it's a huge deal....


--
Dave T=C3=A4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html

--20cf307812b218d81604e9e5a109-- From dave.taht@gmail.com Tue Oct 29 13:00:05 2013 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 AE1CA11E8255; Tue, 29 Oct 2013 13:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpXZGb-+Cffd; Tue, 29 Oct 2013 13:00:04 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 464CD11E81F8; Tue, 29 Oct 2013 13:00:04 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so371908wgh.3 for ; Tue, 29 Oct 2013 13:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7q3rca2ftw1iXiJH7oQ2NjgXNtU320tcKYdQ/K6rpYo=; b=JqxRSgZnuN3Pnfovmb+4yhxTXeaUiOBdT7I64wedgWeP5hIRLElCWWk3vlrot9TSgi s726LJ1o+OPtuusaCtYBjb5EKIM5pI9TYg4DCoxfsUPfdgmAHtE27HAVQXs0ozcnlwg7 G8S1pT79YH9P+d2Lg8XPZDnd2JercX9oVcl+daDNSVzOKmHMbTORJZWmEklYoz+50CqP ccnpZJzIRxL90F3piIsJ8AXW7LzXTVnXfhVfNPoArj6aeA7yGjnDnMuUI+sqJFPyI6ta cJgiMzeD2QpbUykYt08vI3Wd1Is6ocwo943eeUFOGKNfh1UgAP/gdoE4FW7PkSr5BAQa ZeHQ== MIME-Version: 1.0 X-Received: by 10.194.5.7 with SMTP id o7mr1166058wjo.17.1383076803322; Tue, 29 Oct 2013 13:00:03 -0700 (PDT) Received: by 10.217.67.202 with HTTP; Tue, 29 Oct 2013 13:00:03 -0700 (PDT) In-Reply-To: <52700D33.30102@nostrum.com> References: <52700D33.30102@nostrum.com> Date: Tue, 29 Oct 2013 13:00:03 -0700 Message-ID: From: Dave Taht To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rmcat@ietf.org" , rtcweb@ietf.org Subject: Re: [rmcat] [rtcweb] compressed codec-free webrtc? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 20:00:05 -0000 On Tue, Oct 29, 2013 at 12:32 PM, Adam Roach wrote: > On 10/29/13 13:33, Dave Taht wrote: > > In having my eyes glaze over at the codec debate I found myself > wondering to what extent anyone was pursuing truly low latency video > and audio, along the lines of what the lola project has been doing for > collaborative concerts. > > See: > > http://www.conts.it/artistica/lola-project > > They ship raw audio and raw video, they actually use cameras where > they can get at scanlines and ship that (saving 16ms) > > So I'm ignorant of what webrtc can do is there a codec selection (yuv? > 48 bit audio? for the rawest video and audio possible?) > > > In theory, what you're looking for is this: > http://tools.ietf.org/html/rfc4175 Thank you! > However, the caveats in that document are pretty huge: > > It is important to note that uncompressed video can have immense > bandwidth requirements (up to 270 Mbps for standard-definition video, > and approximately 1 Gbps for high-definition video). This is > sufficient to cause potential for denial-of-service if transmitted > onto most currently available Internet paths. > > > Given the risk of Destroying The Internet Forever[tm] if any major browse= r > vendor implemented this, I don't expect you'll see much deployment any ti= me > soon. I don't see people doing videoconferences in the same qty as we do, say, torrents (famous last words!). Certainly the panopticon might take over the internet (but in that case delays from encoding should be acceptable to our new robotic panoptic overloads, it's just the pesky humans that have trouble with latency) So, maybe running at rates like this would trouble the "Internet" a bit now, but on internal networks, not so much. 270Mbits is a trivial amount of bandwidth for a modern switched network. Homes and businesses that are wired are probably close to universally switched GigE, so internal conversations could possibly run at max speed and minimal latency. Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig. Removing a serious delay-inducing-encoding step makes things like echo cancellation unneeded, and live lola-like-collaboration possible. > /a --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From mzanaty@cisco.com Tue Oct 29 22:16:06 2013 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 0351611E8212; Tue, 29 Oct 2013 22:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDH42nm9dfb2; Tue, 29 Oct 2013 22:16:01 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0707711E80E4; Tue, 29 Oct 2013 22:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1116; q=dns/txt; s=iport; t=1383110161; x=1384319761; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JxAjzWF5ki+lpQkLGN2zB0cacahkjupvFD0R216fI3g=; b=ESoqNj26EnYTtbFRoXkW5h/IpwsOSMVdVgvNEPNQZ8PMmea5cELz4mqy JR4aBpDqK5tYJz9Mv+iefQ6Qotb9AcD5/Dzl0AhQRmtG9pLeZ7OtxG4y3 X/YzHJS8k6rzQcKbIjWMnQk91pZ8WC7N9PwoR3Er9cpU3N+P4FQLMMIn7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAPmUcFKtJXHA/2dsb2JhbABZgwc4VL9AgSMWdIInAQSBCwEIIgJDESUCBAEOBAgXh1YDDw2wbQ2Ja4xfgj8zBYMfgQ0DiQeNGI49hTeDJoIq X-IronPort-AV: E=Sophos;i="4.93,598,1378857600"; d="scan'208";a="278302729" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 30 Oct 2013 05:16:00 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9U5G0a3013113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 05:16:00 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 00:16:00 -0500 From: "Mo Zanaty (mzanaty)" To: Dave Taht , "rmcat@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rmcat] compressed codec-free webrtc? Thread-Index: AQHO1S8e0dJsxyD5uE+5M3ouy1NJZw== Date: Wed, 30 Oct 2013 05:15:59 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91E1258DB@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.215.127] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rmcat] compressed codec-free webrtc? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 05:16:06 -0000 Give app developers yuv, udp and native-speed js, and they won=B9t need all the webrtc plumbing at all. No chance of negotiation failure as icing. :) Mo On 10/29/13, 2:33 PM, Dave Taht wrote: In having my eyes glaze over at the codec debate I found myself wondering to what extent anyone was pursuing truly low latency video and audio, along the lines of what the lola project has been doing for collaborative concerts. See: http://www.conts.it/artistica/lola-project They ship raw audio and raw video, they actually use cameras where they can get at scanlines and ship that (saving 16ms) So I'm ignorant of what webrtc can do is there a codec selection (yuv? 48 bit audio? for the rawest video and audio possible?) All the extra encoding steps we take today induce extra latency, and available bandwidth continues to increase... and from a cc perspective if you drop some bits from a scanline that's not a problem, but from audio it's a huge deal.... --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html From christer.holmberg@ericsson.com Tue Oct 29 11:48:04 2013 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 E816311E8243; Tue, 29 Oct 2013 11:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.559 X-Spam-Level: X-Spam-Status: No, score=-5.559 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k11har0YKaWv; Tue, 29 Oct 2013 11:48:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2A23421F9D38; Tue, 29 Oct 2013 11:47:32 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-5e-527002c2f694 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2A.AA.03802.2C200725; Tue, 29 Oct 2013 19:47:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 19:47:30 +0100 From: Christer Holmberg To: Dave Taht , "rmcat@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] compressed codec-free webrtc? Thread-Index: AQHO1NVb6o5lvgXpcESWrIk0bOMNk5oMBKaQ Date: Tue, 29 Oct 2013 18:47:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FAEB5@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvje5hpoIgg9c/hS32bDzJYrH65gc2 i7X/2tkdmD12zrrL7rFkyU+mAKYoLpuU1JzMstQifbsErow79yeyFPzjrpjxNbyB8T1nFyMH h4SAiUTLUokuRk4gU0ziwr31bF2MXBxCAocYJVZP/8sI4SxhlPh44gwbSAObgIVE9z9tEFNE IFdi+0UekF5hAWOJiUv/MYLYIkAjX62dwQphG0lMv7CEBcRmEVCVON94E6yGV8BXYsa2JnYQ W0ggQGLanmfMIDanQKBE9/23TCA2I9A930+tAbOZBcQlPhy8zgxxp4DEkj3noWxRiZeP/7FC 2EoSjUuesELU60ncmDqFDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUj e25iZk56udEmRmA8HNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAOEmt8Hie7e9tqQ9VKmKTtl9Ouep2q7u/voNPW27x4YNJt/24F56OTLjcZXz0zjFz XzuzdSYP1z/X2cxX9WpJK2v3n1ub/jK8reSoE/7rvb/hppAC24fOyImff8a9uzGT42BT+tq9 /x+tOB6S9jeLfdeBl/e2SW3/+UQs+lr1g5U1QvUqc1S7OJRYijMSDbWYi4oTAX9sN5xVAgAA X-Mailman-Approved-At: Wed, 30 Oct 2013 02:57:31 -0700 Subject: Re: [rmcat] [rtcweb] compressed codec-free webrtc? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 18:48:05 -0000 Hi Dave, As far as the standards is concerned, you are allowed to implement and use = whatever codec you want. The discussion is about whether there should be a codec that everyone MUST = implement. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] P= uolesta Dave Taht L=E4hetetty: 29. lokakuuta 2013 20:33 Vastaanottaja: rmcat@ietf.org; rtcweb@ietf.org Aihe: [rtcweb] compressed codec-free webrtc? In having my eyes glaze over at the codec debate I found myself wondering t= o what extent anyone was pursuing truly low latency video and audio, along = the lines of what the lola project has been doing for collaborative concert= s. See: http://www.conts.it/artistica/lola-project They ship raw audio and raw video, they actually use cameras where they can= get at scanlines and ship that (saving 16ms) So I'm ignorant of what webrtc can do is there a codec selection (yuv? 48 bit audio? for the rawest video and audio possible?) All the extra encod= ing steps we take today induce extra latency, and available bandwidth conti= nues to increase... and from a cc perspective if you drop some bits from a = scanline that's not a problem, but from audio it's a huge deal.... -- Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From adam@nostrum.com Tue Oct 29 12:32:25 2013 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 1601711E80E2; Tue, 29 Oct 2013 12:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmPuYvKrC-UQ; Tue, 29 Oct 2013 12:32:24 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9E911E827E; Tue, 29 Oct 2013 12:32:18 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9TJW8op050530 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 14:32:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <52700D33.30102@nostrum.com> Date: Tue, 29 Oct 2013 14:32:03 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Dave Taht , "rmcat@ietf.org" , rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050300060905050501070507" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Wed, 30 Oct 2013 02:57:30 -0700 Subject: Re: [rmcat] [rtcweb] compressed codec-free webrtc? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 19:32:25 -0000 This is a multi-part message in MIME format. --------------050300060905050501070507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/29/13 13:33, Dave Taht wrote: > In having my eyes glaze over at the codec debate I found myself > wondering to what extent anyone was pursuing truly low latency video > and audio, along the lines of what the lola project has been doing for > collaborative concerts. > > See: > > http://www.conts.it/artistica/lola-project > > They ship raw audio and raw video, they actually use cameras where > they can get at scanlines and ship that (saving 16ms) > > So I'm ignorant of what webrtc can do is there a codec selection (yuv? > 48 bit audio? for the rawest video and audio possible?) In theory, what you're looking for is this: http://tools.ietf.org/html/rfc4175 However, the caveats in that document are pretty huge: It is important to note that uncompressed video can have immense bandwidth requirements (up to 270 Mbps for standard-definition video, and approximately 1 Gbps for high-definition video). This is sufficient to cause potential for denial-of-service if transmitted onto most currently available Internet paths. Given the risk of Destroying The Internet Forever[tm] if any major browser vendor implemented this, I don't expect you'll see much deployment any time soon. /a --------------050300060905050501070507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 10/29/13 13:33, Dave Taht wrote:
In having my eyes glaze over at the codec debate I found myself
wondering to what extent anyone was pursuing truly low latency video
and audio, along the lines of what the lola project has been doing for
collaborative concerts.

See:

http://www.conts.it/artistica/lola-project

They ship raw audio and raw video, they actually use cameras where
they can get at scanlines and ship that (saving 16ms)

So I'm ignorant of what webrtc can do is there a codec selection (yuv?
48 bit audio? for the rawest video and audio possible?)

In theory, what you're looking for is this: http://tools.ietf.org/html/rfc4175

However, the caveats in that document are pretty huge:

   It is important to note that uncompressed video can have immense
   bandwidth requirements (up to 270 Mbps for standard-definition video,
   and approximately 1 Gbps for high-definition video).  This is
   sufficient to cause potential for denial-of-service if transmitted
   onto most currently available Internet paths.

Given the risk of Destroying The Internet Forever[tm] if any major browser vendor implemented this, I don't expect you'll see much deployment any time soon.

/a
--------------050300060905050501070507-- From lgeyser@gmail.com Tue Oct 29 14:14:40 2013 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 EB84411E81C9; Tue, 29 Oct 2013 14:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydJLtxM8hYlU; Tue, 29 Oct 2013 14:14:40 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 994D611E8297; Tue, 29 Oct 2013 14:14:38 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id u14so539665lbd.1 for ; Tue, 29 Oct 2013 14:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=skLYJiAZtq9ZtmYQ8tuWhjA6ZKsb9ZS+BN8fWxcpwXQ=; b=EV8OU8h/nwythqTisfxP9IgwGyAun8kblIEwO0g2eLCdj0ThQzRojmh6ImsQbaOCm3 Ueuo6J1SIndUqULN4ptMzDrLQyh12LI35a5Lj4jm+dkjv9WE69u562of8iJa1aK/cOx6 RA89dWouYIrcpHCl17rEz7t00OWdRzB9C8u8oKBV+D5S3pBGeWpAuBKtEMKf3OEW06kD F57qgEqoK0zX3uGPSLFbd+pj9iMFvPraTmoSAMJOIOMGQ2N89plab7ZizaiVaeVrvtjc +GI6dQpBVqEHxoFXR0TVDyqUAQFxXDiSCcrGtoOSqBE6o2mTp4jx8OdXYMgho4ZY4UsB /Chw== MIME-Version: 1.0 X-Received: by 10.112.143.166 with SMTP id sf6mr1206966lbb.29.1383081277460; Tue, 29 Oct 2013 14:14:37 -0700 (PDT) Received: by 10.114.168.70 with HTTP; Tue, 29 Oct 2013 14:14:37 -0700 (PDT) In-Reply-To: References: <52700D33.30102@nostrum.com> Date: Tue, 29 Oct 2013 23:14:37 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e012296f43d13da04e9e7b42f X-Mailman-Approved-At: Wed, 30 Oct 2013 02:57:30 -0700 Cc: "rmcat@ietf.org" , Martin Thomson , Adam Roach Subject: Re: [rmcat] [rtcweb] compressed codec-free webrtc? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 21:14:41 -0000 --089e012296f43d13da04e9e7b42f Content-Type: text/plain; charset=ISO-8859-1 Meanwhile where I live how long would it take to show one frame over a 256Kbit/s connection? :) The MTI codec needs to be a lossy codec. On 29 October 2013 22:01, Martin Thomson wrote: > On 29 October 2013 12:32, Adam Roach wrote: > > In theory, what you're looking for is this: > > http://tools.ietf.org/html/rfc4175 > > I'm surprised that this didn't come up in the codec discussions. Of > course, you'd want to use FEC so that you could reduce the need for > loss concealment. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e012296f43d13da04e9e7b42f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Meanwhile where I live how long would it take to show= one frame over a 256Kbit/s connection? :)
The MTI codec needs to = be a lossy codec.


On 29 October 2013 22:01, Martin Thomson <martin.thomson@gmail.com<= /a>> wrote:
On 29 October 2013 12:32, Adam Roach <adam@nostrum.com> wrote:
> In theory, what you're looking for is this:
> http:= //tools.ietf.org/html/rfc4175

I'm surprised that this didn't come up in the codec discussio= ns. =A0Of
course, you'd want to use FEC so that you could reduce the need for
loss concealment.
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e012296f43d13da04e9e7b42f-- From martin.thomson@gmail.com Tue Oct 29 13:01:33 2013 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 BAFD011E8255; Tue, 29 Oct 2013 13:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPoORWt8FsYd; Tue, 29 Oct 2013 13:01:33 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id ED55421E809B; Tue, 29 Oct 2013 13:01:32 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f4so419271wiw.16 for ; Tue, 29 Oct 2013 13:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y44Xqc3N4wTXUPAst2cL9Yc2wpl6ja61XUk9b3UTHA4=; b=oyW6r5IK7O0yBhep2fI1WGdY4FVN7tN15ApySaCV6tDcEcw752PD6ESUVhpZv2s7lK ABWPsc47OraBpFt0bEInmNld/ejWiJl78j0Gd2hIwEc7SGzTcEYTPXTpgnH+Il8OioO4 1TnX39iZ4V3PUvdsNiUjUyDH5FX5zHzoXARrd8de87LybohQSw9+dn3XAiASznEgXLfL ln57Eo8m2iUGStaN2PfhIssbf65C4YA/ApEngfYH1KFc7B9+ZbTjIjFx9uDoiMdWcU9s KHtOOWdsmp16g6BM1UvIwRBtuOeSGQF05fZwgGabpj4evQkhbrXijk5VWyD6YEveiNpE HZTQ== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr14376539wic.64.1383076892184; Tue, 29 Oct 2013 13:01:32 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Tue, 29 Oct 2013 13:01:32 -0700 (PDT) In-Reply-To: <52700D33.30102@nostrum.com> References: <52700D33.30102@nostrum.com> Date: Tue, 29 Oct 2013 13:01:32 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 30 Oct 2013 02:57:49 -0700 Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" , Dave Taht Subject: Re: [rmcat] [rtcweb] compressed codec-free webrtc? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 20:01:33 -0000 On 29 October 2013 12:32, Adam Roach wrote: > In theory, what you're looking for is this: > http://tools.ietf.org/html/rfc4175 I'm surprised that this didn't come up in the codec discussions. Of course, you'd want to use FEC so that you could reduce the need for loss concealment. From vsingh.ietf@gmail.com Wed Oct 30 06:49:56 2013 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 4A8DE11E8167; Wed, 30 Oct 2013 06:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hghbUF61OJsO; Wed, 30 Oct 2013 06:49:54 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 092AD11E8174; Wed, 30 Oct 2013 06:49:53 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so2252811iej.22 for ; Wed, 30 Oct 2013 06:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3wDQGBZXwBfou3hv2wsrPfdt81Bq5W/6wzhuIiqh0HA=; b=WsMNyZokkQJgTRQfcapxVwWUXPOZQcnOugCBsYsNo8Gktunxgx2jEw9CDnkQNF+a7F ND8olXhALot9piOGjJWdQN67zuNqjFceMwBqqU5EvKmwK/Z4dS/5ALSO/TNikh0T2ru4 joQpw5fwescwLx5j2erpLg/lZK/APbk9uIoAHg38sbX/Oy4FRY6CQ//UiqAyQsBiKSYn 8x2s3LonK3aS/l3Ybl8+LdNQEAD3ubynltuZsruj/3QoE/8s2S18msA5YhyWXDi2xRM/ q0djlqhMrRvgkGvtKRjAP9crH+kTI+GnE5iZUP8DHJwSucaNu0eQXMk9QoiQ2lDwsNMD zXPg== X-Received: by 10.50.77.72 with SMTP id q8mr2534284igw.14.1383140993330; Wed, 30 Oct 2013 06:49:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Wed, 30 Oct 2013 06:49:33 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Wed, 30 Oct 2013 15:49:33 +0200 Message-ID: To: "rtcweb@ietf.org" , "avt@ietf.org" , rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Cc: "Eggert, Lars" , Mirja Kuehlewind , Colin Perkins Subject: Re: [rmcat] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 13:49:56 -0000 Hi all, Practical details for the meeting on **RMCAT Traffic models** Date: 03.11. 2013 Time: 12:30 to 14:30. Assigned Room: Regency A Cheers, Varun On Sun, Oct 27, 2013 at 12:57 PM, Varun Singh wrote: > Hi all, > > In RMCAT WG there has been discussion surrounding the use > of a media traffic generator and to facilitate discussion, > RMCAT is hosting a side meeting on Sunday, 03 November > at 1300-1500. I suppose the room details will be announced > shortly. > > Below is a list of questions that will help design or choose > an appropriate traffic generator for Interactive multimedia traffic. > The list is an initial set and mainly to foster discussion both > on the mailing list and at the meeting. > > Mirja and Lars are not available that day, hence on their behalf, > the meeting is hosted by Colin and I . > > Cheers, > Varun > --- > > Traffic generator: to model the intrinsic variability of video: > > - what target bit rates can be achieved? (max?, min?) > - how much variability in media bit rate for a given target bit rate > - how to model motion? capturing high motion leads to bursty video > (higher than target bit rate), but by how much? can this even be done? > > Traffic generator: on responsiveness to a new target bitrate: > > - how quickly can the codec generate a lower bit rate? > - immediately? does this depend on the new or requested bit rate? > - what is immediately? is it next frame or a few frames later, until then > does it generates at the current rate? > - if not immediately, what bitrates (and duration) will it generate before > meeting the target bitrate. > > > - how quickly can the codec generate a higher bit rate? > - immediately in the next frame? does this also depend on the new > or requested bit rate? > - not immediately but in steps of intermediate bitrates, i.e., intermediate > bitrate for a short duration then an increase in step, repeating until > reaching the target bit rate. > > - If the target bit rate is achieved in steps, can they be announced to the > congestion controller, i.e., the congestion controller knows the ramp up > curve to meet the target bit rate. > > - If the media bit rate has not yet reached the requested target bit rate and > the congestion control requests a new target bit rate, how does the codec > respond? > > Application design related: > - should the congestion control be able to change the frame rate (video) or > packetization time (audio) or is this something that the application controls. > - should the congestion control be able to change video resolution? > - should error-repair: NACKs, FEC be considered part of congestion control or > outside it, i.e., it is something that the application does and not > congestion control > - If FEC is controlled by the congestion control, how quickly can the sending > rate be adapted by reducing/adding redundancy (FEC)? is something link this > done? Does this makes sense at all? > - Apart from loss and RTT, what other congestion cues are currently used by > congestion control algorithms? e.g., Decoding rate/goodput, application > decode error rate, ECN, PCN, etc. > - If the codec is data limited, i.e., producing a sending rate smaller than the > one calculated by the congestion control, can the congestion control probe > the bandwidth by sending additional data packets in a certain pattern (e.g., > PathChirp)? would somehting link this help? > - application input on prioritization: audio vs video (vs data) > > > > > > -- > http://www.netlab.tkk.fi/~varun/ -- http://www.netlab.tkk.fi/~varun/ From creslin@digium.com Wed Oct 30 08:09:27 2013 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 B181A11E824F for ; Wed, 30 Oct 2013 08:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6tGPVXpfbYf for ; Wed, 30 Oct 2013 08:09:23 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5014311E8336 for ; Wed, 30 Oct 2013 08:08:52 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gx14so1212502lab.13 for ; Wed, 30 Oct 2013 08:08:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uP8Fgt5+WNrxvosMzwt1/jXVUKONhJkc4qRjFcrAvMw=; b=h8/lxM5EUT2v/FjgFQNHJsC113Oaqkmfyf94puMmtbHPy8ONOncIcES5D2vLMeWxsv 5xht5FHnfjvlL8QVn0d3ZcpcnQ9ksHD067gbgGYmh8CQLwc5rwSOpb8DMT/5Ry3c9NyH QLjI7llmTBUiJkss+eSTXKzVR1lagFaxAH74q66UFry12dCEIyXnxUir4wXSeYsFvE76 67NQeis02nvDJKPN10kBCUQJyYjewpg7Hi48XuZ8hUkEJdToDmpIKKSGjGP4+1cMwOCp W3XWTTzuRS9S54JrnOS5BwwttOoVbgkQeDeRaEcz31id8PbqrGN9qh0oWt2dq7b79wAe OJrg== X-Gm-Message-State: ALoCoQnFtnE6dxtJ3+Dp3p7eq2lqGGi7gt9ZnE7qik+je2f4iVmV8qz0vwMyJ18fsDor7+hd9aHj MIME-Version: 1.0 X-Received: by 10.152.45.42 with SMTP id j10mr3566302lam.15.1383145728510; Wed, 30 Oct 2013 08:08:48 -0700 (PDT) Received: by 10.112.132.102 with HTTP; Wed, 30 Oct 2013 08:08:48 -0700 (PDT) In-Reply-To: References: <52700D33.30102@nostrum.com> Date: Wed, 30 Oct 2013 10:08:48 -0500 Message-ID: From: Matt Fredrickson To: Dave Taht Content-Type: multipart/alternative; boundary=001a11c29f56d21d3904e9f6b589 X-Mailman-Approved-At: Wed, 30 Oct 2013 11:32:06 -0700 Cc: "rmcat@ietf.org" , Adam Roach , "rtcweb@ietf.org" Subject: Re: [rmcat] [rtcweb] compressed codec-free webrtc? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 15:09:27 -0000 --001a11c29f56d21d3904e9f6b589 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 29, 2013 at 3:00 PM, Dave Taht wrote: > On Tue, Oct 29, 2013 at 12:32 PM, Adam Roach wrote: > > On 10/29/13 13:33, Dave Taht wrote: > > > > In having my eyes glaze over at the codec debate I found myself > > wondering to what extent anyone was pursuing truly low latency video > > and audio, along the lines of what the lola project has been doing for > > collaborative concerts. > > > > See: > > > > http://www.conts.it/artistica/lola-project > > > > They ship raw audio and raw video, they actually use cameras where > > they can get at scanlines and ship that (saving 16ms) > > > > So I'm ignorant of what webrtc can do is there a codec selection (yuv? > > 48 bit audio? for the rawest video and audio possible?) > > > > > > In theory, what you're looking for is this: > > http://tools.ietf.org/html/rfc4175 > > Thank you! > > > However, the caveats in that document are pretty huge: > > > > It is important to note that uncompressed video can have immense > > bandwidth requirements (up to 270 Mbps for standard-definition video, > > and approximately 1 Gbps for high-definition video). This is > > sufficient to cause potential for denial-of-service if transmitted > > onto most currently available Internet paths. > > > > > > Given the risk of Destroying The Internet Forever[tm] if any major > browser > > vendor implemented this, I don't expect you'll see much deployment any > time > > soon. > > I don't see people doing videoconferences in the same qty as we do, > say, torrents (famous last words!). Certainly the panopticon might > take over the internet (but in that case delays from encoding should > be acceptable to our new robotic panoptic overloads, it's just the > pesky humans that have trouble with latency) > > So, maybe running at rates like this would trouble the "Internet" a > bit now, but on internal networks, not so much. > > 270Mbits is a trivial amount of bandwidth for a modern switched > network. Homes and businesses that are wired are probably close to > universally switched GigE, so internal conversations could possibly > run at max speed and minimal latency. > > Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well > above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig. > > Removing a serious delay-inducing-encoding step makes things like echo > cancellation unneeded, and live lola-like-collaboration possible. > Echo cancellation will probably still be needed. Audio as exposed to userspace in the operating system is usually not low enough latency to remove the need to do echo cancellation. Packetization also induces delays in the audio/video stack the necessitate echo cancellation. Matthew Fredrickson --001a11c29f56d21d3904e9f6b589 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 29, 2013 at 3:00 PM, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Oct 29, 2013 at 12= :32 PM, Adam Roach <adam@nostrum.com= > wrote:
> On 10/29/13 13:33, Dave Taht wrote:
>
> In having my eyes glaze over at the codec debate I found myself
> wondering to what extent anyone was pursuing truly low latency video > and audio, along the lines of what the lola project has been doing for=
> collaborative concerts.
>
> See:
>
> http://www.conts.it/artistica/lola-project
>
> They ship raw audio and raw video, they actually use cameras where
> they can get at scanlines and ship that (saving 16ms)
>
> So I'm ignorant of what webrtc can do is there a codec selection (= yuv?
> 48 bit audio? for the rawest video and audio possible?)
>
>
> In theory, what you're looking for is this:
> http:= //tools.ietf.org/html/rfc4175

Thank you!

> However, the caveats in that document are pretty huge:
>
> =A0 =A0It is important to note that uncompressed video can have immens= e
> =A0 =A0bandwidth requirements (up to 270 Mbps for standard-definition = video,
> =A0 =A0and approximately 1 Gbps for high-definition video). =A0This is=
> =A0 =A0sufficient to cause potential for denial-of-service if transmit= ted
> =A0 =A0onto most currently available Internet paths.
>
>
> Given the risk of Destroying The Internet Forever[tm] if any major bro= wser
> vendor implemented this, I don't expect you'll see much deploy= ment any time
> soon.

I don't see people doing videoconferences in the same qty as we d= o,
say, torrents (famous last words!). Certainly the panopticon might
take over the internet (but in that case delays from encoding should
be acceptable to our new robotic panoptic overloads, it's just the
pesky humans that have trouble with latency)

So, maybe running at rates like this would trouble the "Internet"= a
bit now, but on internal networks, not so much.

270Mbits is a trivial amount of bandwidth for a modern switched
network. Homes and businesses that are wired are probably close to
universally switched GigE, so internal conversations could possibly
run at max speed and minimal latency.

Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well
above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.

Removing a serious delay-inducing-encoding step makes things like echo
cancellation unneeded, and live lola-like-collaboration possible.

Echo cancellation will probably still be needed.= =A0Audio as exposed to userspace in the operating system is usually not lo= w enough latency to remove the need to do echo cancellation. =A0Packetizati= on also induces delays in the audio/video stack the necessitate echo cancel= lation.

Matthew Fredrickson

--001a11c29f56d21d3904e9f6b589-- From eckert@cisco.com Wed Oct 30 11:59:45 2013 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 49E7421E812F for ; Wed, 30 Oct 2013 11:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYcTJOds0D2D for ; Wed, 30 Oct 2013 11:59:40 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8002611E827F for ; Wed, 30 Oct 2013 11:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5509; q=dns/txt; s=iport; t=1383159557; x=1384369157; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=tosh4zNi2nxAU0rj4JZkJdOWgmCoCFAhY1BEQMPaOqE=; b=MLGO2c156kLINj5gqKHSzJKBCxK2EEGO8wGBOymVfDfGDuIXY+pnYOuI Vav56bGjaoSMLKztLyWXax8RE9zpgqDFQ7gQGSQea5c11wHVv/NvFIFmV c13jvyhUQ9TQBeSrpXehJFTc7xc2MgDGRZpCypa864kvjIcHJUdA5lUeW w=; X-IronPort-AV: E=Sophos;i="4.93,603,1378857600"; d="scan'208";a="93513700" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 30 Oct 2013 18:59:15 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIxDU9005643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 18:59:13 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r9UIxBWo013839; Wed, 30 Oct 2013 11:59:12 -0700 (PDT) Received: (from eckert@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r9UIxBhI013831; Wed, 30 Oct 2013 11:59:11 -0700 (PDT) Date: Wed, 30 Oct 2013 11:59:10 -0700 From: Toerless Eckert To: "Xiaoqing Zhu (xiaoqzhu)" Message-ID: <20131030185910.GA18642@cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91E124C57@xmb-rcd-x14.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Cc: rmcat WG , Varun Singh , "Mo Zanaty \(mzanaty\)" , Michael Welzl , Colin Perkins Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 18:59:45 -0000 These are good modeling ideas/parameters. I think it would be good to hae a plan first though how this can be executed (which will depnd on who is able to contribute work to the process). Eg: Are there going to be a range of actual codec developers that would be able and willing to run with their real codec some combined reference-video+codec+ reference congestion control method to derive the models codec-parameters ? WOuld they be able to claim codec parameters (as outlined by Mo/Xianqing) even without running such tests ? Alternatively: Don't bother about a wider range of (likely proprietary) production codecs, but just pick one reference h264 and one reference VP8 codec and do all modelling based on using the parameters in thoe codecs - and potentially fudging/improving those reference codecs to play beter ball with congestion control. These are of course not the only choices for execution, but i think they give an idea about the type of execution details that IMHO we should know to be feasiable before finalizing on a modelling approach. I would also like to chime into the origianl approach that would much more take the intra-codec rate-control loop out of the picture: I was hoping RMcat would also work in the presence of switched video conferences. A switching MCU can react to congestion by shaping (increasing delay), switch streams or dropping (low priority) video frames. This might be easier to model first, and it also creates a sender that can potentially react faster than a codec (that may need to have a longer sequence of frames in flight before being able to impact new encoding bitrate). Cheers Toerless On Mon, Oct 28, 2013 at 08:15:07PM +0000, Xiaoqing Zhu (xiaoqzhu) wrote: > Agree with Colin and Mo. > > For a statistical video traffic model, I would propose to break down the 2nd point (encoder rate control) in Mo's list further, to three sub-components: > > a) delayed response to a rate change request (e.g., > 0.5s) > b) deviations from the requested rate (maybe as randomly fluctuating around the target?) > c) the different frame types or coding modes inside the encoder will yield some encoded > frames much larger than others. This will lead to burstiness on time scale of frame intervals > (typically 33ms), and later smoothed out by the pacing/shaper. > > Also, if we go for the approach of using uncompressed test video sequence for testing the combination of video codec and congestion control, we should also recommend a reference codec and default configurations. So that focus of the evaluations remains on the congestion control module. What do folks think of x264 (http://www.videolan.org/developers/x264.html)? > > Best, > Xiaoqing > > > > On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) > wrote: > > I agree with Colin. We should be focused on live encoding where the > encoder rate control is highly granular (often fully smooth) and coupled > to the network congestion control, not pre-encoded streaming of a small > set of fixed bitrates like DASH/HLS. > > A more formal approach to the problem would be to decompose the factors > contributing to the final rate placed onto the network. > 1. Video content / source statistics, using a large set of representative > sequences. An estimate of the entropy per frame could simply be the > encoded frame size using constant quantization, i.e. no encoder rate > control. > 2. Video encoder rate control behavior, which modulates the source > statistics to fit into network constraints over rather large time > intervals (>0.5s). > 3. Network transmission pacing / shaper, which smooths out bursts in > encoder output to fit into network constraints over fine time intervals > (<0.5s). > > It should be possible to model all three in an abstract way to arrive at > some statistical model that can then be used for all tests without any > real video content or encoding (to avoid introducing noise in comparisons > if there was any variability in any of the factors). > > Mo > > > > On 10/28/13, 1:49 PM, Colin Perkins > wrote: > > On 27 Oct 2013, at 11:50, Michael Welzl > wrote: > On 27. okt. 2013, at 12:33, Varun Singh > wrote: > Now, next, what if we'd have a set of such sequences, and then stack > them over a codec that produces quite arbitrary bitrates, assuming that > the network can always follow it - > > Do you mean preparing the same video sequence at multiple rates and the > congestion controller picking the appropriate media rate that fits its > estimate? ie rate switch between different media rates of the same > sequence? > > I think that could be a very good idea! > > I'd be more interested in a standard set of *uncompressed* video test > sequences, that we can use to test the combination of video codec and > congestion control. If we're building something for interactive video > congestion control we should assume live encoding, with the codec > potentially having the flexibility to react to the network, and our > testbed ought to reflect that. > > -- > Colin Perkins > http://csperkins.org/ > > > > > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy!