From nobody Sat May 7 21:51:40 2016 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAA512B031; Sat, 7 May 2016 21:51:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160508045135.5910.75170.idtracker@ietfa.amsl.com> Date: Sat, 07 May 2016 21:51:35 -0700 Archived-At: Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-wireless-tests-02.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 04:51:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques of the IETF. Title : Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks Authors : Zaheduzzaman Sarker Ingemar Johansson Xiaoqing Zhu Jiantao Fu Wei-Tian Tan Michael A. Ramalho Filename : draft-ietf-rmcat-wireless-tests-02.txt Pages : 21 Date : 2016-05-07 Abstract: It is evident that to ensure seamless and robust user experience across all type of access networks multimedia communication suits should adapt to the changing network conditions. There is an ongoing effort in IETF RMCAT working group to standardize rate adaptive algorithm(s) to be used in the real-time interactive communication. In this document test cases are described to evaluate the performances of the proposed endpoint adaptation solutions in LTE networks and Wi-Fi networks. The proposed algorithms should be evaluated using the test cases defined in this document to select most optimal solutions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-wireless-tests/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rmcat-wireless-tests-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-wireless-tests-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 7 21:56:49 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2A012B074 for ; Sat, 7 May 2016 21:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTfX7Ei3A8l7 for ; Sat, 7 May 2016 21:56:47 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F6512B031 for ; Sat, 7 May 2016 21:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2853; q=dns/txt; s=iport; t=1462683407; x=1463893007; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hdm17WeemZOicKB3kzPBSN694RvutzCYEAQHKDL1iTU=; b=FXPGA0KxPHow+BjSgMpATso7tKSMJmoCp9r/Jb3syZR+Eeoe162IGEG1 KpUdHfSTk/mJ6Z3qwnsjbZHqE5Nzqpqos+CjaMl6o0jG7+mtcAoDUnuQI iNbwNzRV5L2WP8SKMrI7MMVILOklSOaFqFjSv8XjFEEYwO64mh5bqnK8G U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AgCtxi5X/49dJa1egzhVfQaGB6NLA?= =?us-ascii?q?QSPLAENgXYihW4CgR84FAEBAQEBAQFlHAuEQQEBAQSBCQIBCBEEAQEKJQ8jHQg?= =?us-ascii?q?CBBMbiBAOvVYBAQEBAQEBAQEBAQEBAQEBAQEBARaGIIRMhD+FWQWOFooMAYV8i?= =?us-ascii?q?B+BaU6EAYhfjzoBHgEBQoNrboc6fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,594,1454976000"; d="scan'208";a="270199877" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2016 04:56:46 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u484ukQ8019459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 8 May 2016 04:56:46 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 7 May 2016 23:56:45 -0500 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Sat, 7 May 2016 23:56:45 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "rmcat@ietf.org" Thread-Topic: [rmcat] I-D Action: draft-ietf-rmcat-wireless-tests-02.txt Thread-Index: AQHRqOVgCkjzJzRVvEKYTfQwDHDShZ+ueYRW Date: Sun, 8 May 2016 04:56:45 +0000 Message-ID: <1462683405808.78422@cisco.com> References: <20160508045135.5910.75170.idtracker@ietfa.amsl.com> In-Reply-To: <20160508045135.5910.75170.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.199.196] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-wireless-tests-02.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 04:56:49 -0000 Hi,=0A= =0A= This new version contains some updates on the Wi-Fi test cases (Section 4):= =0A= * Revised PHY- and MAC- layer configurations in the test setup to reflect 8= 02.11n=0A= * Added the two new test cases presented at IETF-95: varying number of RMCA= T clients and RMCAT clients against dynamic background traffic (CBR over UD= P). =0A= =0A= Thanks,=0A= Xiaoqing=0A= =0A= ________________________________________=0A= From: rmcat on behalf of internet-drafts@ietf.org = =0A= Sent: Saturday, May 7, 2016 11:51 PM=0A= To: i-d-announce@ietf.org=0A= Cc: rmcat@ietf.org=0A= Subject: [rmcat] I-D Action: draft-ietf-rmcat-wireless-tests-02.txt=0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= This draft is a work item of the RTP Media Congestion Avoidance Techniques = of the IETF.=0A= =0A= Title : Evaluation Test Cases for Interactive Real-Time M= edia over Wireless Networks=0A= Authors : Zaheduzzaman Sarker=0A= Ingemar Johansson=0A= Xiaoqing Zhu=0A= Jiantao Fu=0A= Wei-Tian Tan=0A= Michael A. Ramalho=0A= Filename : draft-ietf-rmcat-wireless-tests-02.txt=0A= Pages : 21=0A= Date : 2016-05-07=0A= =0A= Abstract:=0A= It is evident that to ensure seamless and robust user experience=0A= across all type of access networks multimedia communication suits=0A= should adapt to the changing network conditions. There is an ongoing=0A= effort in IETF RMCAT working group to standardize rate adaptive=0A= algorithm(s) to be used in the real-time interactive communication.=0A= In this document test cases are described to evaluate the=0A= performances of the proposed endpoint adaptation solutions in LTE=0A= networks and Wi-Fi networks. The proposed algorithms should be=0A= evaluated using the test cases defined in this document to select=0A= most optimal solutions.=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-ietf-rmcat-wireless-tests/=0A= =0A= There's also a htmlized version available at:=0A= https://tools.ietf.org/html/draft-ietf-rmcat-wireless-tests-02=0A= =0A= A diff from the previous version is available at:=0A= https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-wireless-tests-02=0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= From nobody Thu May 19 11:33:24 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132B512DBB5; Thu, 19 May 2016 11:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0v5msBloBe8; Thu, 19 May 2016 11:33:06 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89A212DB99; Thu, 19 May 2016 11:29:40 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:39946 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b3ShW-0005G6-JJ; Thu, 19 May 2016 19:29:38 +0100 To: tsv-area IETF list , AQM IETF list , tcpm IETF list , tsvwg IETF list , "rmcat@ietf.org" From: Bob Briscoe Message-ID: <573E0611.5070803@bobbriscoe.net> Date: Thu, 19 May 2016 19:29:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070606010507000205050305" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: TCP Prague List Subject: [rmcat] L4S/DualQ BoF-forming on tcpprague list: pls air your concerns X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 18:33:11 -0000 This is a multi-part message in MIME format. --------------070606010507000205050305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Multiple IETF Transport mailing lists. This is to announce that discussions are proceeding on the tcpprague@ietf.org list [see archive ] about organising a BoF on Low Latency Low Loss Scalable throughput (L4S) service, for the IETF-96 Berlin timeframe. The proposed L4S BoF will be about the full implications of L4S - on ECN, SCTP, RMCAT, AQM, etc. Despite the name of the mailing list, it is not just about so-called "TCP Prague" and its implications solely on TCP. If you reply to this announcement, please cut all the mailing lists from the distr except tcpprague. Anyone who is sceptical of the L4S approach, or its safety for the public Internet, please air your concerns. Ideally now on the tcpprague list, but certainly at or preferably before the proposed BoF in Berlin. If you prefer to air your concerns on your favourite WG mailing list, pls at least ensure the tcpprague list is aware. You may know L4S as the DualQ Coupled AQM. Background info on L4S including I-Ds, code, videos, etc. can be found here: https://riteproject.eu/dctth/ Cheers Bob > > -------- Forwarded Message -------- > Subject: Volunteers pls: L4S non-WG-forming BoF proposal cut-off > approaching > Date: Wed, 18 May 2016 12:47:26 +0100 > From: Bob Briscoe > To: TCP Prague List > > > > Folks, > > At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in > Buenos Aires, there was support for a BoF about L4S, In the IETF-96 > (Berlin) time-frame. > It was decided to initially use this ML, even tho the scope of L4S is > wider than TCP Prague. > Consensus was to aim for a non-WG-forming BoF, to demonstrate > willingness to work on the pieces in existing IETF WGs, and to > co-ordinate approaches to each WG. > > The cut-off is now 2.5 weeks away. > *2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area > Directors at UTC 23:59. > > To organise a successful BoF (referring to rfc5434 > ), we need volunteers for the > following tasks: > #/ Draft a statement of problem & scope > #/ List planned deliverables (incl. implementation, spec drafting), > milestones and target WG (also identify any critical interdependencies) > #/ Identify and draft any necessary changes to WG charters, to cover > the above deliverables > #/ Discuss with relevant WG chairs and ADs [see background below] > #/ Identify volunteers (pref before the BoF) planning to work on each > deliverable > > Some people have already volunteered in general to help with arranging > the BoF, but we now need to get specific. > > Let's get volunteers for the above priority tasks first, but for > completeness I'll also list the formalities we have to do: > #/ Decide on name of BoF (and mailing list) > #/ BoF facilitators - chairs, scribes, etc > #/ Draft the BoF agenda, incl. time constraints > #/ Decide on the BoF questions > #/ Estimate attendance, list conflicts, decide duration > #/ Submit a formal request for the BoF via > http://www.ietf.org/instructions/MTG-SLOTS.html and > http://www.ietf.org/ietf/1bof-procedures.txt > > I'll start off co-ordinating and chasing all the above, but contact me > if you would like to take on the co-ordinating task. > > *Background work so far** > * > The idea of this BoF has been floated with WG chairs and ADs for some > time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked > with the RMCAT chairs. > Also we have already done considerable work on defining the problem > while writing various drafts and papers about L4S. > > But, that was just a small group of co-authors (me, Koen, Inton, > Olga). There's still a lot to do to build wider consensus. > We can go ahead with a BoF scheduling request even if disagreements on > scope/problem remain. > But before the BoF itself, we need to have any such disagreements > ironed out. > > At the Buenos Aires Bar Bof, we put up a todo list of pieces that will > need to be worked on: > See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf > particularly slides 9 & 10 > and the target WGs for each were: > * TSVWG (the L4S identifier) > * AQM (the AQM - the name gives the clue ;) > * TCPM (the DCTCP-like congestion control, covering SCTP) > * RMCAT (L4S variants of real-time congestion controls, or at least > standardise existing controls using the identifier) > > I believe, formally, each WG has to decide to charter additional work > on its own ML. > > [Since then, Ingemar has pointed out on this list that we also need to > get AQM & ECN-marking in radio networks, and that will require working > with/through other SDOs and/or developer groups that deal with the MAC > layer . > V. important, but let's push that to a separate thread.] > > Many of the pieces have their own rationale, independent of L4S. The > idea of the BoF is to draw the bigger picture that motivates the work. > That doesn't preclude incremental work on the pieces for those who are > not motivated by a big picture. > > Cheers > > > > Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------070606010507000205050305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Multiple IETF Transport mailing lists.

This is to announce that discussions are proceeding on the tcpprague@ietf.org list [see archive] about organising a BoF on Low Latency Low Loss Scalable throughput (L4S) service, for the IETF-96 Berlin timeframe.
The proposed L4S BoF will be about the full implications of L4S - on ECN, SCTP, RMCAT, AQM, etc. Despite the name of the mailing list, it is not just about so-called "TCP Prague" and its implications solely on TCP.

If you reply to this announcement, please cut all the mailing lists from the distr except tcpprague.

Anyone who is sceptical of the L4S approach, or its safety for the public Internet, please air your concerns. Ideally now on the tcpprague list, but certainly at or preferably before the proposed BoF in Berlin.
If you prefer to air your concerns on your favourite WG mailing list, pls at least ensure the tcpprague list is aware.

You may know L4S as the DualQ Coupled AQM. Background info on L4S including I-Ds, code, videos, etc. can be found here:
https://riteproject.eu/dctth/

Cheers




Bob


-------- Forwarded Message --------
Subject: Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching
Date: Wed, 18 May 2016 12:47:26 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: TCP Prague List <tcpPrague@ietf.org>


Folks,

At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) time-frame.
It was decided to initially use this ML, even tho the scope of L4S is wider than TCP Prague.
Consensus was to aim for a non-WG-forming BoF, to demonstrate willingness to work on the pieces in existing IETF WGs, and to co-ordinate approaches to each WG.

The cut-off is now 2.5 weeks away.
*2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area Directors at UTC 23:59.

To organise a successful BoF (referring to rfc5434), we need volunteers for the following tasks:
#/ Draft a statement of problem & scope
#/ List planned deliverables (incl. implementation, spec drafting), milestones and target WG (also identify any critical interdependencies)
#/ Identify and draft any necessary changes to WG charters, to cover the above deliverables
#/ Discuss with relevant WG chairs and ADs [see background below]
#/ Identify volunteers (pref before the BoF) planning to work on each deliverable

Some people have already volunteered in general to help with arranging the BoF, but we now need to get specific.

Let's get volunteers for the above priority tasks first, but for completeness I'll also list the formalities we have to do:
#/ Decide on name of BoF (and mailing list)
#/ BoF facilitators - chairs, scribes, etc
#/ Draft the BoF agenda, incl. time constraints
#/ Decide on the BoF questions
#/ Estimate attendance, list conflicts, decide duration
#/ Submit a formal request for the BoF via
     http://www.ietf.org/instructions/MTG-SLOTS.html and
     http://www.ietf.org/ietf/1bof-procedures.txt

I'll start off co-ordinating and chasing all the above, but contact me if you would like to take on the co-ordinating task.

Background work so far

The idea of this BoF has been floated with WG chairs and ADs for some time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked with the RMCAT chairs.
Also we have already done considerable work on defining the problem while writing various drafts and papers about L4S.

But, that was just a small group of co-authors (me, Koen, Inton, Olga). There's still a lot to do to build wider consensus.
We can go ahead with a BoF scheduling request even if disagreements on scope/problem remain.
But before the BoF itself, we need to have any such disagreements ironed out.

At the Buenos Aires Bar Bof, we put up a todo list of pieces that will need to be worked on:
See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf particularly slides 9 & 10
and the target WGs for each were:
* TSVWG (the L4S identifier)
* AQM (the AQM - the name gives the clue ;)
* TCPM (the DCTCP-like congestion control, covering SCTP)
* RMCAT (L4S variants of real-time congestion controls, or at least standardise existing controls using the identifier)

I believe, formally, each WG has to decide to charter additional work on its own ML.

[Since then, Ingemar has pointed out on this list that we also need to get AQM & ECN-marking in radio networks, and that will require working with/through other SDOs and/or developer groups that deal with the MAC layer .
V. important, but let's push that to a separate thread.]

Many of the pieces have their own rationale, independent of L4S. The idea of the BoF is to draw the bigger picture that motivates the work.
That doesn't preclude incremental work on the pieces for those who are not motivated by a big picture.

Cheers



Bob




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------070606010507000205050305-- From nobody Fri May 20 03:51:38 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B961612D093 for ; Fri, 20 May 2016 03:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZk7g_6UnX7v for ; Fri, 20 May 2016 03:51:35 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C33612D72B for ; Fri, 20 May 2016 03:51:34 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-0c-573eec342d6d Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.E4.12516.43CEE375; Fri, 20 May 2016 12:51:32 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.175]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Fri, 20 May 2016 12:51:32 +0200 From: Ingemar Johansson S To: "rmcat WG (rmcat@ietf.org)" Thread-Topic: SCReAM status and way forward Thread-Index: AdGygWdxvat+Z8FmQ6qqzvanRamBtw== Date: Fri, 20 May 2016 10:51:31 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA43DF3854@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_06BD_01D1B296.550933C0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM2J7oK7JG7twg2nH9S1W3/zA5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOc7prMXtPQwVrz7dZm9gbGxibGLkZNDQsBE4n37XCYIW0zi wr31bF2MXBxCAkcYJV496WSEcJYwSuybO5EZpIpNwEZi5aHvQAkODhEBA4mbvaYgYWYBK4kv x/+ClQgLqEmcm3iLBaJEW+LcZSmQsIiAnsSJ50/A9rIIqEocO3WXHcTmFfCVWPB5K5jNKCAr cf/7PRaIkeISt57Mh7pNROLhxdNsELaoxMvH/1hBxksIKEos75eDKO9llFix0ghipKDEyZlP WCYwCs9CMmkWkrJZSMog4tESX/Z8gbINJO4f6mCFsLUlli18zQxh60u0HVvNjCluLTHj10E2 CFtRYkr3Q3YI21Ti9dGPjAsYuVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBMbiwS2/dXcw rn7teIhRgINRiYd3Qb5duBBrYllxZe4hRhWgOY82rL7AKMWSl5+XqiTC++QVUJo3JbGyKrUo P76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVAPjvMisnTozJSe43tZ4euQT 5+9JW34t3Kv0pXxlfbM3/3ahixHfD7H8NLziodkf/yVpLs/JS/Nly/L0mhNOm2/Xu9rspjcj 4e1G/8K5DM9W3F5rc8HSmmXtHw7VPVZT2/Qso+LaTPZcf7425sZuxp1/6jK3Ze3VqhR95LyS /ULiRgH/vdXdEwWFlViKMxINtZiLihMBxOX2pM0CAAA= Archived-At: Cc: Ingemar Johansson S Subject: [rmcat] SCReAM status and way forward X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 10:51:37 -0000 ------=_NextPart_000_06BD_01D1B296.550933C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_06BE_01D1B296.550933C0" ------=_NextPart_001_06BE_01D1B296.550933C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 The SCReAM congestion control algorithm has undergone an update after a review by Mirja K=FChlewind, Stefan Holmer and Xiaoqing Zhu (thanks!).=20 There will likely be an additional update submitted in a few weeks.=20 =20 I have a few questions : Q1: Is this draft is now ready for WGLC ?=20 =20 Q2: Which simulation data, if any, is required to get the draft into WGLC ?. = I understand that it is now sufficient with simulation results for the = test cases in section 5 in (https://tools.ietf.org/html/draft-ietf-rmcat-eval-test-03 ), the = wireless test cases are optional. Is this interpretation correct ?. =20 Q3: Running code for SCReAM has been published quite a while ago, both as a standalone implementation and as a part of OpenWebRTC, I have however = not seen any reaction or questions or other signs that indicate that this is = of interest to this group. Has anybody looked at this code, experimented = with it, or integrated it in one form or the other ?. Does anybody plan to do anything with the code ? =20 /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc.=20 Master Researcher =20 Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 = ingemar.s.johansson@ericsson.com www.ericsson.com =20 This report, by it=B4s very length,=20 defends itself against the risk of being read Winston Churchill =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ------=_NextPart_001_06BE_01D1B296.550933C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

The SCReAM = congestion control algorithm has undergone an update after a review by = Mirja K=FChlewind, Stefan Holmer and Xiaoqing Zhu (thanks!). =

There will likely be an additional = update submitted in a few weeks.

 

I have a few = questions :

Q1:

Is this draft is now ready for WGLC ? =

 

Q2:

Which = simulation data, if any, is required to get the draft into WGLC ?. I = understand that it is now sufficient with simulation results for the = test cases in section 5 in (https:= //tools.ietf.org/html/draft-ietf-rmcat-eval-test-03 ), the wireless = test cases are optional. Is this interpretation correct = ?.

 

Q3:

Running code = for SCReAM has been published quite a while ago, both as a standalone = implementation and as a part of OpenWebRTC, I have however not seen any = reaction or questions or other signs that indicate that this is of = interest to this group. Has anybody looked at this code, experimented = with it, or integrated it in one form or the other ?. Does anybody plan = to do anything with the code ?

 

/Ingemar

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

Ingemar = Johansson  M.Sc.

Master = Researcher

 

Ericsson = AB

Wireless = Access Networks

Labratoriegr=E4= nd 11

971 28, = Lule=E5, Sweden

Phone = +46-1071 43042

SMS/MMS = +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 This report, by it=B4s very length, =

=A0defends = itself against the risk of being read

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Wins= ton Churchill

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

 

------=_NextPart_001_06BE_01D1B296.550933C0-- ------=_NextPart_000_06BD_01D1B296.550933C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVYzCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGADCCA+igAwIBAgIQ eyeE6FBBHSc8YzDpWR1mVTANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMDIxNDI5MTdaFw0xNzEy MDIxNDI5MTZaMHQxETAPBgNVBAoMCEVyaWNzc29uMRwwGgYDVQQDDBNJbmdlbWFyIEpvaGFuc3Nv biBTMS8wLQYJKoZIhvcNAQkBFiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTEQMA4G A1UEBRMHRVBMSUpPSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6dOkJu7hl4aOKX k6YBf5PgWpDbO6iINxyYJetBuJZJqEdDqKukaHZmP8Rn5hhiQZDWa89koR41DNS7umMwZtHQkN+j m3b5Z1LUMQle7XDtUy3rn47hgjYUFgZOEp1fWYIoAKxZNOTf4AfiMbOGn2t8IFxe8JUYrAVy6tAE YnSnPM+nn4UeipLBwncBVhxUQU5R4W8b5k7tY8HJB+CWGgSbkyLWfxeuiwAA48nKqa6fOqo2ZpS4 ukNf9u8Hk3fIT8XvDJVnT2NwB7Z29oL3Fq20tm4M96SkuLlNjLZ9wvskfmYAk+PUP44ugvkB7Uon cAzoPXlkz3N5IB9Ly7/SIgsCAwEAAaOCAcYwggHCMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVh bGNhdjIuY2VyMCsGA1UdEQQkMCKBIGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcD AjAdBgNVHQ4EFgQUOrfg77a5Xcj2OffxTY1aeC+5CqEwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9v BsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQCddA412wylfbLwBiyQ uVz1IDcaYZ14Yh1L52IhX14BGl0eNc/5BbWL3yCF2eGv8h6FmckZHOM7+OS4g+inNZbaKysTkLah T3UbrUWFPpkZFAS1HfaxBJZTVS3UIVnIYP06ZvRRRNf3VJzwpZSES4tu0euzI2CatWCZLa+N4QyT ZkMnw1JLUXbz0dPA40b9Qdoec23PkpMqf1CxNNuaRBF9L5wKGily7RyPOtkcrWJ3R2oSGC7ugKK9 vWzQzEHoE95txgF/kq7MdRJks8BXqnb3w8Fthu+1zIORjcR9yxv1e9gYo0ZcaPqyjC/LDdzsHv59 5hkwQnxAGyPDBgCdq5Ion/4Lx+YI61SKcyGEH+VYD6CJX44/IfRAE+tq8BHZYOJLW8uCd7Jboqd2 jklsUfSPN8i4cvQpfYzDkrSziyfcvdplEvxSEbTEFZ+w6IbvCtV0xBSfS9+RhqBOn6LZSdw/jp+b 9penQAWekRykrKyKroDtwesqg0HbC7bkprqOwSaar5gcFGYVYJ5JuHT3Ou44hGn/yiwbTnc2Mb12 8nWesZQZvIT2n5Y42ZYebo1cLBYdF6U/Q5OHLOUk596LephQggvKphe7F2w87CpaUUoANa4H1ri+ LTOKdz+itrkbu3dDs6oDZuSwMU3fJaf8d/3PPLoGJtFQWQ8v2e/Oxxe0sDCCBrYwggSeoAMCAQIC EQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJh MR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUy NzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqj ddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZ abrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtV aqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldV JtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJ iOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgv jVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxML WiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvc IzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQw gYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3Qu dGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZx f0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBu ByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9Iewy aV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy0 4/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEu eSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWX I0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5l JPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Y u0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2 QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGC AvMwggLvAgEBME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTIwMTA1MTMxWjAjBgkqhkiG9w0B CQQxFgQURm6+UzME8plk2sJqEnY1rXwpm9AwWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQeyeE6FBBHSc8YzDpWR1mVTBfBgsqhkiG9w0BCRAC CzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwDQYJKoZIhvcNAQEBBQAEggEAbGp1M4t18kcnfehQ OVGbMYijxImYmJjvGUGy7IYu+T5k0vXqce7OgHORUnu7FAaaUEyNHPM/FxdsZbMnqnecq5ObVjrl 8CbKEPOfSgjYWr3YXw7AHXW02cjP7/G2KlwnEsjFLHpILBbNITPQpPh+xP1oYoT84C+Kmf5Jyd2a BMuEiQ1+0t1LROvZCkkLdfYDWFFJKfAbs3SAcn0oPW5+wxxRDHHf2qLUSyHRZmjpdEjFXJNaGmvY t5CdpxNSfJpY/p0KVXQq7/c9PhC6c1iWqIp8vh4GKUvxzQ1JCkjyGprJpt9fXrJBBb2BqhZwfA4Q yUIaSt7Ze/UZo1ZapNnJ5AAAAAAAAA== ------=_NextPart_000_06BD_01D1B296.550933C0-- From nobody Tue May 24 08:35:15 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E090A12D8BA for ; Tue, 24 May 2016 08:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZVXwDH6sunI for ; Tue, 24 May 2016 08:35:12 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C3012D8B1 for ; Tue, 24 May 2016 08:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25638; q=dns/txt; s=iport; t=1464104111; x=1465313711; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=84OpsAK+N7LXpypWQnmaLOhWPT6sKtKCIJTCOoTGEe0=; b=jibBP9NBakD3W72FNigO1coz9Mg9DGWxjTGhXRsIVV3dMYEhUcRSPAMN ffb9Nhg2TPZ3cf/k9FN9A8dUcyrba7JBdDZLfqZTU7X6GCzN5dTpkWkXV pJ7Tza4q+N0toy54/259bA65OSP2GQ/lExHhxCieNSo7RfbJa5bLAH5TZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQBLc0RX/xbLJq1cgmyBIX25fgENg?= =?us-ascii?q?XYehXMCgWoUAQEBAQEBAWUnhEIBAQEEIwocLwEOAgkCEQQBAQEJFgEBBgMCAgk?= =?us-ascii?q?DAgECAQkrCQgGAQwGAgEBiCsOlRSdHZFcAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?AWGIoRMhBEKBwEiMIJLglkBBIgQiyeFAIYAiCCBaYRPgwkjhTiPTB4BAUKCBhy?= =?us-ascii?q?BTToyAYgSCReBHgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,360,1459814400"; d="scan'208,217";a="677344949" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2016 15:35:09 +0000 Received: from [10.0.2.15] ([10.228.220.47]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4OFZ81E021398; Tue, 24 May 2016 15:35:09 GMT To: Ingemar Johansson S , "stefan@webrtc.org" , "randell-ietf@jesup.org" References: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC0906@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA43DC10BF@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA43DC1402@ESESSMB205.ericsson.se> From: Sergio Mena Message-ID: <574474AC.7070608@cisco.com> Date: Tue, 24 May 2016 17:35:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC1402@ESESSMB205.ericsson.se> Content-Type: multipart/alternative; boundary="------------020703050208050303060002" Archived-At: Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Live slide show modeling X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 15:35:14 -0000 This is a multi-part message in MIME format. --------------020703050208050303060002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit All, We would like to announce to the list that we have implemented a new synthetic codec C++ class (SimpleContentSharingCodec), which follows the guidelines that Stefan and Ingemar described in this email thread. You can find it in the latest version of our repo: https://github.com/cisco/syncodecs Let me know if you have questions on how to use it. Regards, Sergio On 07/04/16 14:43, Ingemar Johansson S wrote: > > Did a quick shot where I created a frame size trace according to the > guidelines below , the probability of a large frame is 0.05. > > The bottleneck BW is limited to 500kbps, RTT=100ms > > Please see attached png. > > I did not optimize SCReAM for this, there is a possibility that one > need to turn off the feature that clears the transmit queue if it > becomes too large, this feature can then be defined as optional on a > SCReAM-stream level. > > Another observation is that CWND is estimated too high between ~12 and > 40s. So there is probably room for improvement but at least it does > not break down. > > I also attached the frame size trace, realize that the 1^st frame > should probably be large. > > /Ingemar > > *From:*Stefan Holmer [mailto:stefan@webrtc.org] > *Sent:* den 7 april 2016 12:59 > *To:* Ingemar Johansson S; randell-ietf@jesup.org > *Cc:* rmcat@ietf.org > *Subject:* Re: Live slide show modeling > > Right. My experience is that during the periods of static content, the > congestion controller may run into problems due to being rate limited > and network jitter. Once it's time to transmit a huge frame the > rate/cwnd is very low and it takes several seconds to send the frame > even though the connection is typically good. > > On Thu, Apr 7, 2016 at 11:54 AM Ingemar Johansson S > > wrote: > > Hi > > Ok, thanks, I assume that rate adaptation is not really applicable > here ?. Instead it is more a task to verify that the congestion > control does not transmit more than what fits in the bottleneck, > to avoid excess packet drops or delay ? > > /Ingemar > > *From:*Stefan Holmer [mailto:stefan@webrtc.org > ] > *Sent:* den 7 april 2016 10:27 > *To:* Ingemar Johansson S; Randell Jesup (randell-ietf@jesup.org > ) > *Cc:* rmcat WG (rmcat@ietf.org ) > *Subject:* Re: Live slide show modeling > > I'd model it as a low framerate (~5 fps) stream, where with some > probability (maybe between 0.005 and 0.05) a frame is large due to > a slide change (say 50-400 packets). In between slide changes the > frames can be compressed to a single packet. > > /Stefan > > On Thu, Apr 7, 2016 at 8:39 AM Ingemar Johansson S > > wrote: > > Hi > > Do you have a reasonably rough idea of how to model the > transmission of a live slide show. > > I can, from the discussion on the chat, imagine something like > > Frame period : 1s, or 5s, something else ? > > Frame size : ? a 1920x1080 jpg compressed image is something > like 500+ kB ? > > /Ingemar > > ================================== > > Ingemar Johansson M.Sc. > > Master Researcher > > Ericsson AB > > Wireless Access Networks > > Labratoriegränd 11 > > 971 28, Luleå, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > > www.ericsson.com > > This report, by it´s very length, > > defends itself against the risk of being read > > Winston Churchill > > ================================== > --------------020703050208050303060002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

All,

We would like to announce to the list that we have implemented a new synthetic codec C++ class (SimpleContentSharingCodec), which follows the guidelines that Stefan and Ingemar described in this email thread.

You can find it in the latest version of our repo: https://github.com/cisco/syncodecs

Let me know if you have questions on how to use it.

Regards,

Sergio


On 07/04/16 14:43, Ingemar Johansson S wrote:

Did a quick shot where I created a frame size trace according to the guidelines below , the probability of a large frame is 0.05.

 

The bottleneck BW is limited to 500kbps, RTT=100ms

 

Please see attached png.

I did not optimize SCReAM for this, there is a possibility that one need to turn off the feature that clears the transmit queue if it becomes too large, this feature can then be defined as optional on a SCReAM-stream level.

Another observation is that CWND is estimated too high between ~12 and 40s. So there is probably room for improvement but at least it does not break down.

 

I also attached the frame size trace, realize that the 1st frame should probably be large.

 

/Ingemar

 

 

From: Stefan Holmer [mailto:stefan@webrtc.org]
Sent: den 7 april 2016 12:59
To: Ingemar Johansson S; randell-ietf@jesup.org
Cc: rmcat@ietf.org
Subject: Re: Live slide show modeling

 

Right. My experience is that during the periods of static content, the congestion controller may run into problems due to being rate limited and network jitter. Once it's time to transmit a huge frame the rate/cwnd is very low and it takes several seconds to send the frame even though the connection is typically good.

 

On Thu, Apr 7, 2016 at 11:54 AM Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi

 

Ok, thanks, I assume that rate adaptation is not really applicable here ?. Instead it is more a task to verify that the congestion control does not transmit more than what fits in the bottleneck, to avoid excess packet drops or delay ?

 

/Ingemar

 

From: Stefan Holmer [mailto:stefan@webrtc.org]
Sent: den 7 april 2016 10:27
To: Ingemar Johansson S; Randell Jesup (randell-ietf@jesup.org)
Cc: rmcat WG (rmcat@ietf.org)
Subject: Re: Live slide show modeling

 

I'd model it as a low framerate (~5 fps) stream, where with some probability (maybe between 0.005 and 0.05) a frame is large due to a slide change (say 50-400 packets). In between slide changes the frames can be compressed to a single packet.

 

/Stefan

 

On Thu, Apr 7, 2016 at 8:39 AM Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi

Do you have a reasonably rough idea of how to model the transmission of a live slide show.

I can, from the discussion on the chat, imagine something like

 

Frame period : 1s, or 5s, something else ?

Frame size : ? a 1920x1080 jpg compressed image is something like 500+ kB ?

 

/Ingemar

==================================

Ingemar Johansson  M.Sc.

Master Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

           This report, by it´s very length,

 defends itself against the risk of being read

                       Winston Churchill

==================================

 


--------------020703050208050303060002-- From nobody Tue May 31 12:14:05 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604FD12D891 for ; Tue, 31 May 2016 12:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EelQmS9uc_If for ; Tue, 31 May 2016 12:13:59 -0700 (PDT) Received: from ls-mx3.csir.co.za (unknown [146.64.10.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46DAC12D0B3 for ; Tue, 31 May 2016 12:13:57 -0700 (PDT) Received: from pta-imo.csir.co.za (pta-imo.csir.co.za [146.64.100.49]) by ls-mx3.csir.co.za (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id u4VJDdKS005566 for ; Tue, 31 May 2016 21:13:41 +0200 Received: from PTA-IMO-MTA by pta-imo.csir.co.za with Novell_GroupWise; Tue, 31 May 2016 21:13:30 +0200 Message-Id: <574DFE780200004D000ED614@pta-imo.csir.co.za> X-Mailer: Novell GroupWise Internet Agent 14.0.2 Date: Tue, 31 May 2016 21:13:28 +0200 From: "Ralf Globisch" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (ls-mx3.csir.co.za [146.64.10.248]); Tue, 31 May 2016 21:13:41 +0200 (SAST) X-CSIR-MailScanner-Information: Please contact the ISP for more information X-CSIR-MailScanner-ID: u4VJDdKS005566 X-CSIR-MailScanner: Found to be clean X-CSIR-MailScanner-From: rglobisch@csir.co.za X-CSIR-MailScanner-Watermark: 1465326822.86426@PjhhmY0UOJGJo0xtq+4fTw Archived-At: Subject: [rmcat] SCReAM status and way forward X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:14:04 -0000 Ingemar, for what it's worth, I forked the SCReAM code on github and integr= ated it into an RTP library. I ran some preliminary tests streaming video over my home ADSL line, but of= ten found that the algorithm struggled to stream at higher rates than the minimum (in my case I used 50k= bps as the minimum).=20 If I understand correctly, the algorithm is designed for use over mobile ne= tworks and not ADSL though.=20 If you're interested, perhaps we could investigate the behaviour of the alg= orithm on other network types, etc. It could be that some fine-tuning, etc is needed to make it work in such ca= ses. Of course it could also be, that I was not using your code as intended... R. > Q3: > Running code for SCReAM has been published quite a while ago, both as a > standalone implementation and as a part of OpenWebRTC, I have however not > seen any reaction or questions or other signs that indicate that this is = of > interest to this group. Has anybody looked at this code, experimented with > it, or integrated it in one form or the other ?. Does anybody plan to do > anything with the code ? --=20 This message is subject to the CSIR's copyright terms and conditions, e-mai= l legal notice, and implemented Open Document Format (ODF) standard.=20 The full disclaimer details can be found at http://www.csir.co.za/disclaime= r.html. This message has been scanned for viruses and dangerous content by MailScan= ner,=20 and is believed to be clean. Please consider the environment before printing this email. From nobody Tue May 31 23:58:47 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EB412D114 for ; Tue, 31 May 2016 23:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLG26H6T5_Vd for ; Tue, 31 May 2016 23:58:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7A312D607 for ; Tue, 31 May 2016 23:58:41 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-d2-574e879fa0fb Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E4.3E.27088.F978E475; Wed, 1 Jun 2016 08:58:40 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.112]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0294.000; Wed, 1 Jun 2016 08:58:39 +0200 From: Ingemar Johansson S To: "rglobisch@csir.co.za" , "rmcat WG (rmcat@ietf.org)" Thread-Topic: [rmcat] SCReAM status and way forward Thread-Index: AdG7zSIEwGYie1rzTzytlPrJBLhKfA== Date: Wed, 1 Jun 2016 06:58:38 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA43E063E0@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0254_01D1BBE3.C98964D0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyM2K7t+6Cdr9wg66XLBbvJzayWKy++YHN gcljw+5pjB5LlvxkCmCK4rJJSc3JLEst0rdL4MrY1f2AueDcdcaKj+c2sTYw3jzE2MXIySEh YCKxuX8hM4QtJnHh3nq2LkYuDiGBI4wSO7+eY4JwFjNK3Oo5CtbBJmAjsfLQdzBbRCBRYs+5 +ywgNrOAlcSX43/BJgkLGEmcbYCpMZbo3vGaHcLWk3hx/RFYPYuAisT+tx1sIDavgK/EgTPT wXoZBWQl7n+/BzVTXOLWk/lMENeJSDy8eJoNwhaVePn4H2sXIweQrSixvF8O5E5mgV5Giavz dzNDzBSUODnzCcsERuFZSEbNQlY3C0kdRFG0xIUvW1hnAc1lBrq1bSMjRFheYvvbOcwQtq7E /+cwtrbEsoWvoWxriRm/DrJB2IoSU7ofskPYphKvj35kXMDIvYpRtDi1OCk33chIL7UoM7m4 OD9PLy+1ZBMjMEoPbvltsIPx5XPHQ4wCHIxKPLwJnH7hQqyJZcWVuYcYVYDmPNqw+gKjFEte fl6qkgjv+xagNG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6p Bkb7sEs9WzobsoWa7Jm5jAyMPY+udWheyLvd5fT3Swfdk/N26dv0/+xPuin1NNN9wfy5FUZb lF7abD8b6NQy6+VGnpm3Q9RX9XkvfHWDm2HT1K6nZ692ya5eySnbFdo//5HFXnGJrWedljiu PqV18bfUnRlXrAJifWasfPh6x6+LhbGlb193Fm1VYinOSDTUYi4qTgQAHeoCkdoCAAA= Archived-At: Cc: Ingemar Johansson S Subject: Re: [rmcat] SCReAM status and way forward X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 06:58:46 -0000 ------=_NextPart_000_0254_01D1BBE3.C98964D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0255_01D1BBE3.C98964D0" ------=_NextPart_001_0255_01D1BBE3.C98964D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ralf And thanks for the effort, worth a lot. I assume that you have used the C++ code (https://github.com/EricssonResearch/scream) in your implementation? 50kbps is a very low bitrate for video, there are a few things that can cause extra trouble. + RTCP overhead. At bitrates this low it is sufficient with feedback intervals around 200ms, furthermore reduced size RTCP (RFC5506) is highly recommended, this will give you an RTCP overhead of ~3-5kbps, so a recommendation is that you have a look at how much bandwidth RTCP consumes. Is reduced size RTCP implemented in your RTP library ?, it is implemented in the GStreamer libraries if you wish to have a look at how it is done. + RTP overhead. The function getTargetBitrate has a comment in the header file /* * Get the target bitrate for stream with SSRC * NOTE!, Because SCReAM operates on RTP packets, the target bitrate will * also include the RTP overhead. This means that a subsequent call to set the * media coder target bitrate must subtract an estimate of the RTP + framing * overhead. This is not critical for Video bitrates but can be important * when SCReAM is used to congestion control e.g low bitrate audio streams */ This means that, if the size argument in the addTransmitted function includes also the size of the RTP header (+ possible extensions) then the computed bitrate is the bitrate with the RTP overhead included. This means that you need to subtract the bitrate given by the RTP overhead when you compute the video coder bitrate. The function to compute the video coder bitrate is thus. videoBitrate = getTargetBitrate(..)+rtpOverheadBitrate. A somewhat better alternative, used in the OpenWebRTC implementation is to use the RTP payload size as input to the addTransmitted(..) function. + Video coder output. My grim experience is that the video coder does not always output the desired target bitrate, variations around the target bitrate is natural but in some cases I have seen that the output bitrate is consistently 10-20% above the target bitrate, for that reason it could be good to compute and log the video coder output bitrate. In some cases the video coders are in a non-rate adaptive mode or have the internal rate control tuned too slow, this is a tuning matter. I have fiddled a bit with OpenH264 and VP8, which video codec do you use ? I have only tried out these low bitrates with the experimental code, the code is adapted for audio streaming so it should not be any problems to congestion control video over 50kbps bottlenecks. With the OpenWebRTC implementation I managed to push down the bottleneck bitrate down to 200kbps. The problem there is that I did not have full control over the RTP stack and that RTCP tended to consume too much bandwidth. That said, there are probably some yet to discover issues, it is not too unlikely that you have found an issue in SCReAM but one probably need to rule out the possible issues above before. Is your fork available somewhere ?, could be interesting to try it out as you have integrated it into an RTP library. Regards Ingemar "Ralf Globisch" Tue, 31 May 2016 19:14 UTC Show header Ingemar, for what it's worth, I forked the SCReAM code on github and integrated it into an RTP library. I ran some preliminary tests streaming video over my home ADSL line, but often found that the algorithm struggled to stream at higher rates than the minimum (in my case I used 50kbps as the minimum). If I understand correctly, the algorithm is designed for use over mobile networks and not ADSL though. If you're interested, perhaps we could investigate the behaviour of the algorithm on other network types, etc. It could be that some fine-tuning, etc is needed to make it work in such cases. Of course it could also be, that I was not using your code as intended... ------=_NextPart_001_0255_01D1BBE3.C98964D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ralf

 

And thanks for the = effort, worth a lot.

I assume that you have used the C++ code = (https://github.com/EricssonResearch/scream) in your = implementation?

 

50kbps is a very low = bitrate for video, there are a few things that can cause extra trouble. =

+ RTCP overhead. At bitrates this low it is = sufficient with feedback intervals around 200ms, furthermore reduced = size RTCP (RFC5506) is highly recommended, this will give you an RTCP = overhead of ~3-5kbps, so a recommendation is that you have a look at how = much bandwidth RTCP consumes. Is reduced size RTCP implemented in your = RTP library ?, it is implemented in the GStreamer libraries if you wish = to have a look at how it is done.

 

+ RTP overhead. The = function getTargetBitrate has a comment in the header = file

    /*

    * Get the target bitrate for = stream with SSRC

    * NOTE!, Because SCReAM = operates on RTP packets, the target bitrate will

    *  also include the RTP = overhead. This means that a subsequent call to set the

    *  media coder = target bitrate must subtract an estimate of the RTP + framing =

    *  overhead. This is = not critical for Video bitrates but can be important

    *  when SCReAM is = used to congestion control e.g low bitrate audio streams

    */

   This means that, if the size = argument in the addTransmitted function includes also the size of the RTP = header (+ possible extensions) then the computed bitrate is the bitrate = with the RTP overhead included. This means that you need to subtract the = bitrate given by the RTP overhead when you compute the video coder = bitrate. The function to compute the video coder bitrate is = thus.

videoBitrate =3D = getTargetBitrate(..)+rtpOverheadBitrate.

  A somewhat better = alternative, used in the OpenWebRTC implementation is to use the RTP = payload size as input to the addTransmitted(..) = function.

 

+ Video coder output. My = grim experience is that the video coder does not always output the = desired target bitrate, variations around the target bitrate is natural = but in some cases I have seen that the output bitrate is consistently = 10-20% above the target bitrate, for that reason it could be good to = compute and log the video coder output bitrate. In some cases the video = coders are in a non-rate adaptive mode or have the internal rate control = tuned too slow, this is a tuning matter. I have fiddled a bit with = OpenH264 and VP8, which video codec do you use ?

 

I have only tried out = these low bitrates with the experimental code, the code is adapted for = audio streaming so it should not be any problems to congestion control = video  over 50kbps bottlenecks.

With the OpenWebRTC = implementation I managed to push down the bottleneck bitrate down to = 200kbps. The problem there is that I did not have full control over the = RTP stack and that RTCP tended to consume too much = bandwidth.

 

That said, there are = probably some yet to discover issues, it is not too unlikely that you = have found an issue in  SCReAM but one probably need to rule out = the  possible issues above before.

 

Is your fork available = somewhere ?, could be interesting to try it out as you have integrated = it into an RTP library.

 

Regards

Ingemar

 

 

 

"Ralf Globisch" <rglobisch@csir.co.za><= /span> Tue, 31 May 2016 19:14 = UTCShow = header

Ingemar, for what it's worth, =
I forked the SCReAM code on github and integrated it into an RTP =
library.
I ran some preliminary =
tests streaming video over my home ADSL line, but often found that the =
algorithm
struggled to stream at =
higher rates than the minimum (in my case I used 50kbps as the minimum). =

If I understand correctly, =
the algorithm is designed for use over mobile networks and not ADSL =
though. 
If you're interested, =
perhaps we could investigate the behaviour of the algorithm on other =
network types, etc.
It could be that some =
fine-tuning, etc is needed to make it work in such cases. Of course it =
could also be,
that I was not using your =
code as intended...
 
<= p class=3DMsoNormal> 

 

------=_NextPart_001_0255_01D1BBE3.C98964D0-- ------=_NextPart_000_0254_01D1BBE3.C98964D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVYzCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGADCCA+igAwIBAgIQ eyeE6FBBHSc8YzDpWR1mVTANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMDIxNDI5MTdaFw0xNzEy MDIxNDI5MTZaMHQxETAPBgNVBAoMCEVyaWNzc29uMRwwGgYDVQQDDBNJbmdlbWFyIEpvaGFuc3Nv biBTMS8wLQYJKoZIhvcNAQkBFiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTEQMA4G A1UEBRMHRVBMSUpPSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6dOkJu7hl4aOKX k6YBf5PgWpDbO6iINxyYJetBuJZJqEdDqKukaHZmP8Rn5hhiQZDWa89koR41DNS7umMwZtHQkN+j m3b5Z1LUMQle7XDtUy3rn47hgjYUFgZOEp1fWYIoAKxZNOTf4AfiMbOGn2t8IFxe8JUYrAVy6tAE YnSnPM+nn4UeipLBwncBVhxUQU5R4W8b5k7tY8HJB+CWGgSbkyLWfxeuiwAA48nKqa6fOqo2ZpS4 ukNf9u8Hk3fIT8XvDJVnT2NwB7Z29oL3Fq20tm4M96SkuLlNjLZ9wvskfmYAk+PUP44ugvkB7Uon cAzoPXlkz3N5IB9Ly7/SIgsCAwEAAaOCAcYwggHCMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVh bGNhdjIuY2VyMCsGA1UdEQQkMCKBIGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcD AjAdBgNVHQ4EFgQUOrfg77a5Xcj2OffxTY1aeC+5CqEwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9v BsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQCddA412wylfbLwBiyQ uVz1IDcaYZ14Yh1L52IhX14BGl0eNc/5BbWL3yCF2eGv8h6FmckZHOM7+OS4g+inNZbaKysTkLah T3UbrUWFPpkZFAS1HfaxBJZTVS3UIVnIYP06ZvRRRNf3VJzwpZSES4tu0euzI2CatWCZLa+N4QyT ZkMnw1JLUXbz0dPA40b9Qdoec23PkpMqf1CxNNuaRBF9L5wKGily7RyPOtkcrWJ3R2oSGC7ugKK9 vWzQzEHoE95txgF/kq7MdRJks8BXqnb3w8Fthu+1zIORjcR9yxv1e9gYo0ZcaPqyjC/LDdzsHv59 5hkwQnxAGyPDBgCdq5Ion/4Lx+YI61SKcyGEH+VYD6CJX44/IfRAE+tq8BHZYOJLW8uCd7Jboqd2 jklsUfSPN8i4cvQpfYzDkrSziyfcvdplEvxSEbTEFZ+w6IbvCtV0xBSfS9+RhqBOn6LZSdw/jp+b 9penQAWekRykrKyKroDtwesqg0HbC7bkprqOwSaar5gcFGYVYJ5JuHT3Ou44hGn/yiwbTnc2Mb12 8nWesZQZvIT2n5Y42ZYebo1cLBYdF6U/Q5OHLOUk596LephQggvKphe7F2w87CpaUUoANa4H1ri+ LTOKdz+itrkbu3dDs6oDZuSwMU3fJaf8d/3PPLoGJtFQWQ8v2e/Oxxe0sDCCBrYwggSeoAMCAQIC EQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJh MR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUy NzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqj ddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZ abrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtV aqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldV JtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJ iOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgv jVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxML WiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvc IzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQw gYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3Qu dGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZx f0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBu ByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9Iewy aV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy0 4/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEu eSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWX I0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5l JPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Y u0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2 QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGC AvMwggLvAgEBME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjAxMDY1ODM4WjAjBgkqhkiG9w0B CQQxFgQUNmp4gHDv/rYCvJyknE/i63k+8gYwWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQeyeE6FBBHSc8YzDpWR1mVTBfBgsqhkiG9w0BCRAC CzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwDQYJKoZIhvcNAQEBBQAEggEAQeV8iCAe9MmESrLl xASN7Yn/iHejF+HagA6+hRQ6W/ds3Hbc4IJMYITcqlHAvPlDXeleCGnS9Bc0GRlhMsnxzu1e+q9F jME8goAdlGQk8qnFuTFvuaoTavLVWZo4/el21HoikPtsPqxTsU9CKthOrpsO06lcN2M/rwrOdPHR 990+PY6GT58LthAFq0+h/OULA3yxWVxjvYEfHNPW+JYR6RC4ptP5yL2sMCXPKH67k5zuQQ9YHwjL 6Xg5xKQdKS1+pGiknFqTlcptgWFBdkHBxVA+1G5XFJVr9n0jui2bY/0jV6mwVgEnH5YrAUX/RgHk +S48E8yfS/L3i2NdiZd6XAAAAAAAAA== ------=_NextPart_000_0254_01D1BBE3.C98964D0--