From nobody Thu Jun 4 00:11:27 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4F03A041D for ; Thu, 4 Jun 2020 00:11:26 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUOmHJYIW-P7 for ; Thu, 4 Jun 2020 00:11:25 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0983A07C2 for ; Thu, 4 Jun 2020 00:11:24 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id s1so5955846ljo.0 for ; Thu, 04 Jun 2020 00:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+A1x2J4Vs+Nrr2s2voe+7Y9vN6YEiOx39tOwtG+3euc=; b=hP775voHqgGN3061/3r6b8wnDDvyPk/DF28CCv38M6rKkNRKfJGHNlKMF0GB0uY8sq /pIN/NhhFDB4k2n+IILvRqgdZy+lsmgO3TAyOD17t3ZjhB4hqMBFDw0XrsMSaEGtlakz ytupBcvMwX25mkpkTFC1G44CH8d36uohwl3kDP3TaGID7IIpbSpXnofRkq0YuUawfJSf rc4xKx1b1nQNnU26nDXvTC8BG1eQftXVYwaQ05+vlP+9e1PBlbvSoH1SM5FnArTEfMKk H1qKh/yEY6Z57MyK8lDKfmLL/x+8VC7pTSH5UXkhWAhjgpGvHzFZEuVurhglhBVmVtdH hmNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+A1x2J4Vs+Nrr2s2voe+7Y9vN6YEiOx39tOwtG+3euc=; b=R5/2WwprQOWg3Cc43VNoKvqzQYlY6sedyZsPRKrJXiXrsv3bgzVahBjSRQin42Y3uQ 9+5+a5NSRFGC/m0/U2HuusECLzrYJOtnfAAlGLd5XntZ4tzZsRuT+FbaR9dYifmUaqSN NnsOePcOoCrB0Q5UR4i3sSksXgJUwgJYmunq6Q2cvERTVaaVAO8rb/AsdVHRKjMf5ZH8 FP3K5yyz2HJEgVY4qd4068YsknMcth0RsA7OAw0Tuh4d9rGgQx1zYVow8Hc/rrcFtiKd 1DDOXAop99Wi3h4sR5ASB1LnlI82g+MpKYAlYdN9z6zMpzL6CmfiJCPk+iVdRMgLtBl5 2gqA== X-Gm-Message-State: AOAM5331zsFaH5D0+btYRzBgOGxMm/3ud68QSyMJgNMvGSWyv6TUUL00 Dsb8ABJbSKrUA3Gec6lsUWxDRci6UsWxCzIF9qJ3kNDL0Sc= X-Google-Smtp-Source: ABdhPJx3Fwr9BfjE+z7z+gEGvWc2DN0VMNLD4nnABtDiROBliD2RFwbutR2fKViipFUADRLiP4IFa6xKmNfUCBbY3fc= X-Received: by 2002:a2e:a545:: with SMTP id e5mr1377955ljn.271.1591254682062; Thu, 04 Jun 2020 00:11:22 -0700 (PDT) MIME-Version: 1.0 From: "Ali C. Begen" Date: Thu, 4 Jun 2020 10:11:11 +0300 Message-ID: To: mops@ietf.org Content-Type: multipart/alternative; boundary="000000000000126a8305a73cda3a" Archived-At: Subject: [Mops] Announcing mhv/2020 Online X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 07:11:27 -0000 --000000000000126a8305a73cda3a Content-Type: text/plain; charset="UTF-8" Hi everyone You might have seen this, but I wanted to make sure the MOPS community is aware of the Mile High Video 2020. This year, we are going online on Dec. 1st and 2nd. The call for speakers is now open at http://mile-high.video/ Deadline for submitting a proposal is June 10th. Like the last year, we will have an independent program committee to evaluate the proposals. Please consider submitting a proposal yourself and encourage your colleagues to do so. If you have questions, please let me know. Cheers, -acbegen --000000000000126a8305a73cda3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone

You might have seen this, but I wanted = to make sure the MOPS community is aware of the Mile High Video 2020. This = year, we are going online on Dec. 1st and 2nd. The=C2=A0call for speakers i= s now open at

Deadline for submitting a proposal= is June 10th. Like the last year, we will have an independent program comm= ittee to evaluate the proposals.

Please consider submitting a propos= al yourself and encourage your colleagues to do so.

If you have ques= tions, please let me know.

Cheers,
-acbegen
--000000000000126a8305a73cda3a-- From nobody Fri Jun 5 10:50:16 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A5C3A0C01 for ; Fri, 5 Jun 2020 10:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.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 BRwgJRbClRUR for ; Fri, 5 Jun 2020 10:50:12 -0700 (PDT) Received: from blue.elm.relay.mailchannels.net (blue.elm.relay.mailchannels.net [23.83.212.20]) (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 3F5213A0BFE for ; Fri, 5 Jun 2020 10:50:12 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BBE981E1795; Fri, 5 Jun 2020 17:50:10 +0000 (UTC) Received: from pdx1-sub0-mail-a92.g.dreamhost.com (100-97-66-8.trex.outbound.svc.cluster.local [100.97.66.8]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BE8381E16B6; Fri, 5 Jun 2020 17:50:09 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from pdx1-sub0-mail-a92.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Fri, 05 Jun 2020 17:50:10 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|ldaigle@thinkingcat.com X-MailChannels-Auth-Id: dreamhost X-Exultant-Quick: 1e23f37740d36661_1591379410238_1691679280 X-MC-Loop-Signature: 1591379410238:939837027 X-MC-Ingress-Time: 1591379410238 Received: from pdx1-sub0-mail-a92.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a92.g.dreamhost.com (Postfix) with ESMTP id 779617F134; Fri, 5 Jun 2020 10:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=thinkingcat.com; bh=9mdPjYbMlIKBdr VIhQgk/Ntg5B8=; b=L2NTDbWEdIEAw+3ytFpVnrWFb00+bMNTvNAjC+DtTzHzv0 16L03xfHMKi9n/W00Ey1y+8a2UonJjYO5RiDoatozPpT3S0Gkn/H+kzvJS2/MPJD bOJKD8HNBHwYs1GHS1PERxfYEuHplrNOJtUVZX0a74qu8bhMdmWOQSq2Z78ow= Received: from [192.168.1.57] (vtelinet-216-66-102-83.vermontel.net [216.66.102.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ldaigle@thinkingcat.com) by pdx1-sub0-mail-a92.g.dreamhost.com (Postfix) with ESMTPSA id DEC4A7F142; Fri, 5 Jun 2020 10:50:07 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a92 From: "Leslie Daigle" To: mops@ietf.org Date: Fri, 05 Jun 2020 13:50:03 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <6DD03D99-4C60-4CC7-BDFF-557504B26550@thinkingcat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1B82AC24-68B5-4CB9-B5F6-EA770D7C46B7_=" X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedguddtgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffoffkgggtgfesrgekmherredtjeenucfhrhhomhepfdfnvghslhhivgcuffgrihhglhgvfdcuoehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmqeenucggtffrrghtthgvrhhnpeduueelkeeuudegleeiuddvgffggfejkeetieetteevveffkeejueduhfeugfduvdenucfkphepvdduiedrieeirddutddvrdekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopegludelvddrudeikedruddrheejngdpihhnvghtpedvudeirdeiiedruddtvddrkeefpdhrvghtuhhrnhdqphgrthhhpedfnfgvshhlihgvucffrghighhlvgdfuceolhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomheqpdhmrghilhhfrhhomheplhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomhdpnhhrtghpthhtoheplhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomh Content-Transfer-Encoding: 7bit Archived-At: Subject: [Mops] Planning upcoming meetings X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 17:50:15 -0000 --=_MailMate_1B82AC24-68B5-4CB9-B5F6-EA770D7C46B7_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Hi, Requests for WG slots at the IETF 108 (virtual) meeting are due by June=20 12 =E2=80=94 a week from now! Kyle and I had been tossing around the question of whether MOPS should=20 meet during that week, or do another virtual interim. Given the=20 pressing deadline for requesting a WG session, I=E2=80=99d like to hear i= f=20 people have strong opinions, either way, ASAP. For reference, agenda material we have to cover at this point includes: Update on the OpsCons document Reports from anywhere =E2=80=94 SVA, possibly other service activities Discussion of working formats going forward . more frequent meetings (about=E2=80=A6?) Please also let me know if you have things you=E2=80=99d like to discuss = at a=20 MOPS virtual meeting =E2=80=94 as part of IETF 108 or otherwise. Thanks, Leslie. --=20 ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- --=_MailMate_1B82AC24-68B5-4CB9-B5F6-EA770D7C46B7_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

Requests for WG slots at the IETF 108 (virtual) meeting a= re due by June 12 =E2=80=94 a week from now!

Kyle and I had been tossing around the question of whethe= r MOPS should meet during that week, or do another virtual interim. Giv= en the pressing deadline for requesting a WG session, I=E2=80=99d like to= hear if people have strong opinions, either way, ASAP.

For reference, agenda material we have to cover at this p= oint includes:
Update on the OpsCons document
Reports from anywhere =E2=80=94 SVA, possibly other service activitie= s
Discussion of working formats going forward
. more frequent meetings (about=E2=80=A6?)

Please also let me know if you have things you=E2=80=99d = like to discuss at a MOPS virtual meeting =E2=80=94 as part of IETF 108 o= r otherwise.

Thanks,
Leslie.

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com

--=_MailMate_1B82AC24-68B5-4CB9-B5F6-EA770D7C46B7_=-- From nobody Sun Jun 7 00:41:51 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A613A0A14 for ; Sun, 7 Jun 2020 00:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=jhGjZteO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cqjtDL0W 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 2yIyf3pmaTCQ for ; Sun, 7 Jun 2020 00:41:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277F33A0A12 for ; Sun, 7 Jun 2020 00:41:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 95C1E5C00A4 for ; Sun, 7 Jun 2020 03:32:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 07 Jun 2020 03:32:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=4BDlJ7z5JFSboXgBcblWvmo1svlwmEnF0J457ECMsCE=; b=jhGjZteO 03iaVtqhbEIhSsAjHWmlzvt0Ljr+z0RMRs6R5K1Y/KBqZnrqk72B8ObYOOtO8zka XvL4iuryuKAQvpelw4a9D6cPLucHJgQ5FgXwUOdWGfQqkAmx2gWk85GYolEC3DTh IMyls1MyWgVId1r1l5yv8X1Uijy0N/PFXsTQd4qO0QrpJDlfFPKZjwL2KUoUeFN9 CCw97EAcDblbBOSVvPKO8a/x8dYlodbvj4OkZqXbGIQbFZgFdj41vJPz6JTgVuof hWbpZLrCa7cRzQcKl2w1Sy+1m3awZgDhOoTvga6MNTnnXQeKYBdElZtuOL7691R1 mJmAubEo93XRfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=4BDlJ7z5JFSboXgBcblWvmo1svlwm EnF0J457ECMsCE=; b=cqjtDL0WxHRqj2Cy4rcjvDnKev1CfmUtv4pT0GViCKmYz 6YWN8x8H08J6uZCnUjw+MK790w8VrkbqMbiP7CueuM8iJiEE4pj6QUPcyL/Drup1 OQZavYjuv5oOfJTPrKxhc0LX1AHNeLUn3gY5YoUHGl2QHS8Nof7xBgt6Pl5ElrIN W2PSx6Bco59nfgAm+/5O4GhG5SOzuQfFtgPN8V9RA9Jir15jPsCan4ALz70QOmMw e/312VYCOmH+rmy192HiVhtHidu9f28OzwgbpYJ/cLEsqDrirWayMapfKe1nkXI+ NBWyn/VI96felOLc4ZIh6+HqcybpDIKEHyjSDoGdw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegkedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvdevteffiefhvdehueffgeekuddvgfeugefgtdffkefgledttdeuveehtdefveet necuffhomhgrihhnpegrthhtrdgtohhmpdhgihhthhhusgdrtghomhenucfkphepgedtrd eihedruddufedrudefvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az115.internal.cloudapp.net (unknown [40.65.113.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 414D53280059 for ; Sun, 7 Jun 2020 03:32:43 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3976722231953511644==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mops@ietf.org Message-Id: <20200607073243.414D53280059@mailuser.nyi.internal> Date: Sun, 7 Jun 2020 03:32:43 -0400 (EDT) Archived-At: Subject: [Mops] Weekly github digest (MOPS Activity Summary) X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 07:41:50 -0000 --===============3976722231953511644== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-mops/draft-ietf-mops-streaming-opcons (+1/-0/=F0=9F=92=AC0) 1 issues created: - Better reference for target: https://about.att.com/pages/COVID-19/updat= es.html (by SpencerDawkins) https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues= /24=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons --===============3976722231953511644== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MOPS Activity Summary)

Sunday June 07, 2020

Events without label "editorial"

Issues

ietf-wg-mops/draft-ietf-mops-streaming-opcons (+1/-0/=F0=9F=92=AC0)

1 issues created:

Repositories tracked by this digest:

--===============3976722231953511644==-- From nobody Tue Jun 9 15:19:26 2020 Return-Path: X-Original-To: mops@ietf.org Delivered-To: mops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E3B3A078C; Tue, 9 Jun 2020 15:19:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ldaigle@thinkingcat.com, mops@ietf.org, evyncke@cisco.com, mops-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159174116402.20573.9033330416334542655@ietfa.amsl.com> Date: Tue, 09 Jun 2020 15:19:24 -0700 Archived-At: Subject: [Mops] mops - New Meeting Session Request for IETF 108 X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 22:19:25 -0000 A new meeting session request has just been submitted by Leslie Daigle, a Chair of the mops working group. --------------------------------------------------------- Working Group Name: Media OPerationS Area Name: Operations and Management Area Session Requester: Leslie Daigle Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: add gendispatch Technology Overlap: dispatch mboned People who must be present: Eric Vyncke Spencer Dawkins Leslie Daigle Kyle Rose Jake Holland Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 9 17:34:45 2020 Return-Path: X-Original-To: mops@ietf.org Delivered-To: mops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FA53A0D76; Tue, 9 Jun 2020 17:34:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mops-chairs@ietf.org, mops@ietf.org, krose@krose.org, evyncke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159174927767.12027.17987773842122798262@ietfa.amsl.com> Date: Tue, 09 Jun 2020 17:34:37 -0700 Archived-At: Subject: [Mops] mops - Update to a Meeting Session Request for IETF 108 X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 00:34:44 -0000 An update to a meeting session request has just been submitted by Kyle Rose, a Chair of the mops working group. --------------------------------------------------------- Working Group Name: Media OPerationS Area Name: Operations and Management Area Session Requester: Kyle Rose Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: add gendispatch taps secdispatch iccrg Technology Overlap: dispatch mboned Key Participant Conflict: tsvwg People who must be present: Eric Vyncke Spencer Dawkins Leslie Daigle Kyle Rose Jake Holland Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jun 10 03:19:16 2020 Return-Path: X-Original-To: mops@ietf.org Delivered-To: mops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD2C3A08CA; Wed, 10 Jun 2020 03:19:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: evyncke@cisco.com, mops@ietf.org, ldaigle@thinkingcat.com, mops-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159178435492.13903.3213870456306710996@ietfa.amsl.com> Date: Wed, 10 Jun 2020 03:19:15 -0700 Archived-At: Subject: [Mops] mops - Update to a Meeting Session Request for IETF 108 X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 10:19:15 -0000 An update to a meeting session request has just been submitted by Leslie Daigle, a Chair of the mops working group. --------------------------------------------------------- Working Group Name: Media OPerationS Area Name: Operations and Management Area Session Requester: Leslie Daigle Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: gendispatch add taps secdispatch iccrg Technology Overlap: dispatch mboned Key Participant Conflict: tsvwg quic People who must be present: Eric Vyncke Spencer Dawkins Leslie Daigle Glenn Deen Sanjay Mishra Kyle Rose Jake Holland Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jun 10 15:28:18 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543CD3A0943 for ; Wed, 10 Jun 2020 15:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.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 Ju-GJXQ-L-ys for ; Wed, 10 Jun 2020 15:28:15 -0700 (PDT) Received: from donkey.ash.relay.mailchannels.net (donkey.ash.relay.mailchannels.net [23.83.222.49]) (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 029E53A0028 for ; Wed, 10 Jun 2020 15:28:13 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 623F41814FF; Wed, 10 Jun 2020 22:28:09 +0000 (UTC) Received: from pdx1-sub0-mail-a61.g.dreamhost.com (100-97-66-8.trex.outbound.svc.cluster.local [100.97.66.8]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BC8861814F2; Wed, 10 Jun 2020 22:28:08 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from pdx1-sub0-mail-a61.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Wed, 10 Jun 2020 22:28:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|ldaigle@thinkingcat.com X-MailChannels-Auth-Id: dreamhost X-Bubble-Hook: 10a1d6396342c3eb_1591828089220_1710687957 X-MC-Loop-Signature: 1591828089220:2640178368 X-MC-Ingress-Time: 1591828089220 Received: from pdx1-sub0-mail-a61.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTP id 2DCFFB3919; Wed, 10 Jun 2020 15:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:references:mime-version:content-type; s=thinkingcat.com; bh=UQwKiC09PVGTWjzCJkwsNJOzmM8=; b=dQ700c51s zPp//YlvRQf8MhGkL9tB+KenS5mXt5IvXFXtCZ8Jkx/I0TBdx1DhZ3+j5Mf/Ys4o bon9AKCquJO9h9WIu9Lrp6eLYrEmE02pNx+54PIHGaVoe7j1ftofsl+ndJwJH2TH sGKgBZFFQkjEKIjUeDojaIXTMfyMP6YTnM= Received: from [169.254.91.76] (vtelinet-216-66-102-83.vermontel.net [216.66.102.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ldaigle@thinkingcat.com) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTPSA id 5DD87B3917; Wed, 10 Jun 2020 15:28:06 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a61 From: "Leslie Daigle" To: mops@ietf.org Date: Wed, 10 Jun 2020 18:27:58 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: References: <159181529656.16063.6964178024900109434@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_069B70FB-8F01-40D8-A1C3-D530B7D30532_=" X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudehjedguddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffokfhfgggtsegrtdhmreertdejnecuhfhrohhmpedfnfgvshhlihgvucffrghighhlvgdfuceolhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomheqnecuggftrfgrthhtvghrnhepleetvdefudegveelgfffledtffetgeelvddufeefhefhgeeftdeggeefteeludelnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepvdduiedrieeirddutddvrdekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopegludeiledrvdehgedrledurdejiegnpdhinhgvthepvdduiedrieeirddutddvrdekfedprhgvthhurhhnqdhprghthhepfdfnvghslhhivgcuffgrihhglhgvfdcuoehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmqedpmhgrihhlfhhrohhmpehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmpdhnrhgtphhtthhopehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhm Archived-At: Subject: [Mops] Consider volunteering! Fwd: Nomcom 2020-2021 Second Call For Volunteers X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 22:28:17 -0000 --=_MailMate_069B70FB-8F01-40D8-A1C3-D530B7D30532_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Apologies =E2=80=94 this is going to be the nth copy of the message in yo= ur = inboxes, where n may not be small. But, forwarding as requested by our = OPS AD, Warren Kumari. Volunteer for the NomCom =E2=80=94 it will be interesting, and it=E2=80=99= s = important work! Leslie. -- = ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- Forwarded message: > From: NomCom Chair 2020 > To: IETF Announcement List > Cc: ietf@ietf.org > Subject: Nomcom 2020-2021 Second Call For Volunteers > Date: Wed, 10 Jun 2020 11:54:56 -0700 > > This is the second sending of the call for volunteers for the = > 2020-2021 NomCom. > > I wanted to mention a few updates from the previous email (sent 2 = > weeks ago): > - I've fixed the URL at the bottom of the email to point to = > https://datatracker.ietf.org/nomcom/2020/ instead of /2019/. This was = > a test to see if anyone was paying attention. Apparently, some people = > were. ;) > - The IETF 108 registration form includes a checkbox that will let = > you volunteer. You can use this instead of emailing me, when you = > register for IETF 108. > - I currently have 39 volunteers. Last year had 149. I need more = > volunteers! > -----------------------------------------------------------------------= ---------- > The IETF NomCom appoints people to fill the open slots on the LLC, = > IETF Trust, the IAB, and the IESG. > > Ten voting members for the NomCom are selected in a verifiably random = > way from a pool of volunteers. The more volunteers, the better chance = > we have of choosing a random yet representative cross section of the = > IETF population. > > The details of the operation of the NomCom can be found in BCP 10 (RFC = > 8713). RFC 3797 details the selection algorithm. > > Special for this year (and only this year), we also have RFC 8788 = > (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to = > volunteer: > > Members of the IETF community must have attended at least three = > of > the last five in-person IETF meetings in order to volunteer. > > The five meetings are the five most recent in-person meetings = > that > ended prior to the date on which the solicitation for NomCom > volunteers was submitted for distribution to the IETF community. > Because no IETF 107 in-person meeting was held, for the = > 2020-2021 > Nominating Committee those five meetings are IETFs > 102 [Montreal, Canada; July 2018], > 103 [Bangkok, Thailand; November 2018], > 104 [Prague, Czech Republic; March 2019], > 105 [Montreal, Canada; July 2019], and > 106 [Singapore; November 2019]. > > Keep in mind that eligibility is based on in-person attendance at the = > five listed meetings. You can check your eligibility at: = > https://www.ietf.org/registration/nomcom.py. > > If you qualify, please volunteer. Before you decide to volunteer, = > please remember that anyone appointed to this NomCom will not be = > considered as a candidate for any of the positions that the 2020 - = > 2021 NomCom is responsible for filling. > > People commonly volunteer by ticking the box on IETF registration = > forms. The IETF 106 form did not ask whether people were willing to = > volunteer. IETF 107 did ask, but all those registrations were = > canceled. I have asked the Secretariat if it is possible to get the = > list if volunteers from canceled IETF 107 registrations. If that list = > is available, I will contact all who are verified as eligible. But = > given the uncertainty of this process, I would encourage people to = > volunteer directly (see the bottom of this email for instructions). = > Thank you for volunteering! > > The list of people and posts whose terms end with the March 2021 IETF = > meeting, and thus the positions for which this NomCom is responsible, = > are > > IETF Trust: > Joel Halpern > > LLC: > Maja Andjelkovic > > IAB: > Jari Arkko > Jeff Tantsura > Mark Nottingham > Stephen Farrell > Wes Hardaker > Zhenbin Li > > IESG: > Alissa Cooper, IETF Chair/GEN AD > Alvaro Retana, RTG AD > Barry Leiba, ART AD > Deborah Brungard, RTG AD > =C3=89ric Vyncke, INT AD > Magnus Westerlund, TSV AD > Roman Danyliw, SEC AD > Warren Kumari, OPS AD > > All appointments are for 2 years. The Routing area has 3 ADs and the = > General area has 1; all other areas have 2 ADs. Thus, all areas (that = > have more than one AD) have at least one continuing AD. > > The primary activity for this NomCom will begin in July 2020 and = > should be completed in January 2021. The NomCom will have regularly = > scheduled conference calls to ensure progress. There will be = > activities to collect requirements from the community, review = > candidate questionnaires, review feedback from community members about = > candidates, and talk to candidates. > > While being a NomCom member does require some time commitment it is = > also a very rewarding experience. > > As a member of the NomCom it is very important that you be willing and = > able to attend either videoconference or in-person meetings (which may = > not happen) during 14-20 November (IETF 109 - Bangkok) to conduct = > interviews. Videoconference attendance will be supported whether or = > not there are in-person meetings. Orientation and setting of the = > NomCom schedule will be done by videoconference during the week 20-24 = > July (exact time and date to be determined after NomCom membership is = > finalized on July 12), the week prior to IETF 108. Being at IETF 110 = > (Prague) is not essential. > > Please volunteer by sending me an email before 23:59 UTC June 24, = > 2020, as follows: > > To: nomcom-chair-2020@ietf.org > Subject: NomCom 2020-21 Volunteer > > Please include the following information in the email body: > > Your Full Name: > // as you write it on the IETF registration form > > Current Primary Affiliation: > // Typically what goes in the Company field > // in the IETF Registration Form > > Emails: > // All email addresses used to register for the past 5 IETF = > meetings > // Preferred email address first > > Telephone: > // For confirmation if selected > > You should expect an email response from me within 5 business days = > stating whether or not you are qualified. If you don't receive this = > response, please re-send your email with the tag "RESEND"" added to = > the subject line. > > If you are not yet sure if you would like to volunteer, please = > consider that NomCom members play a very important role in shaping the = > leadership of the IETF. Questions by email or voice are welcome. = > Volunteering for the NomCom is a great way to contribute to the IETF! > > You can find a detailed timeline on the NomCom web site at: > https://datatracker.ietf.org/nomcom/2020/ > > I will be publishing a more detailed target timetable, as well as = > details of the randomness seeds to be used for the RFC 3797 selection = > process, within the next few weeks. > > Thank you! > > Barbara Stark > bs7652 at att dot com > nomcom-chair-2020 at ietf dot org > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --=_MailMate_069B70FB-8F01-40D8-A1C3-D530B7D30532_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

F= rom: NomCom Chair 2020 <nomcom-chair-2020@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: ietf@ietf.org
Subject: Nomcom 2020-2021 Second Call For Volunteers
Date: Wed, 10 Jun 2020 11:54:56 -0700

This is the second sending of the call for volunteers for the 2020-2021 N= omCom.

I wanted to mention a few updates from the previous email (sent 2 weeks a= go):
- I've fixed the URL at the bottom of the email to point to https://da= tatracker.ietf.org/nomcom/2020/ instead of /2019/. This was a test to= see if anyone was paying attention. Apparently, some people were. ;)
= - The IETF 108 registration form includes a checkbox that will let you v= olunteer. You can use this instead of emailing me, when you register for = IETF 108.
- I currently have 39 volunteers. Last year had 149. I need more volunte= ers!
-------------------------------------------------------------------------= --------
The IETF NomCom appoints people to fill the open slots on the LLC, IETF T= rust, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random way= from a pool of volunteers. The more volunteers, the better chance we hav= e of choosing a random yet representative cross section of the IETF popul= ation.

The details of the operation of the NomCom can be found in BCP 10 (RFC 87= 13). RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788 (one-of= f update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:
Members of the IETF community must have attended at least three of<= br> the last five in-person IETF meetings in order to volunteer.

The five meetings are the five most recent in-person meetings that<= br> ended prior to the date on which the solicitation for NomCom
volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs
102 [Montreal, Canada; July 2018],
103 [Bangkok, Thailand; November 2018],
104 [Prague, Czech Republic; March 2019],
105 [Montreal, Canada; July 2019], and
106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the fiv= e listed meetings. You can check your eligibility at: https://www.iet= f.org/registration/nomcom.py.

If you qualify, please volunteer. Before you decide to volunteer, please = remember that anyone appointed to this NomCom will not be considered as a= candidate for any of the positions that the 2020 - 2021 NomCom is respon= sible for filling.

People commonly volunteer by ticking the box on IETF registration forms. = The IETF 106 form did not ask whether people were willing to volunteer. I= ETF 107 did ask, but all those registrations were canceled. I have asked = the Secretariat if it is possible to get the list if volunteers from canc= eled IETF 107 registrations. If that list is available, I will contact al= l who are verified as eligible. But given the uncertainty of this process= , I would encourage people to volunteer directly (see the bottom of this = email for instructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF mee= ting, and thus the positions for which this NomCom is responsible, are
IETF Trust:
Joel Halpern

LLC:
Maja Andjelkovic

IAB:
Jari Arkko
Jeff Tantsura
Mark Nottingham
Stephen Farrell
Wes Hardaker
Zhenbin Li

IESG:
Alissa Cooper, IETF Chair/GEN AD
Alvaro Retana, RTG AD
Barry Leiba, ART AD
Deborah Brungard, RTG AD
=C3=89ric Vyncke, INT AD
Magnus Westerlund, TSV AD
Roman Danyliw, SEC AD
Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the Gene= ral area has 1; all other areas have 2 ADs. Thus, all areas (that have mo= re than one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should b= e completed in January 2021. The NomCom will have regularly scheduled co= nference calls to ensure progress. There will be activities to collect re= quirements from the community, review candidate questionnaires, review fe= edback from community members about candidates, and talk to candidates.
While being a NomCom member does require some time commitment it is also = a very rewarding experience.

As a member of the NomCom it is very important that you be willing and ab= le to attend either videoconference or in-person meetings (which may not = happen) during 14-20 November (IETF 109 - Bangkok) to conduct interviews.= Videoconference attendance will be supported whether or not there are in= -person meetings. Orientation and setting of the NomCom schedule will be = done by videoconference during the week 20-24 July (exact time and date t= o be determined after NomCom membership is finalized on July 12), the wee= k prior to IETF 108. Being at IETF 110 (Prague) is not essential.

Please volunteer by sending me an email before 23:59 UTC June 24, 2020, a= s follows:

To: nomcom-chair-2020@ietf.org
Subject: NomCom 2020-21 Volunteer

Please include the following information in the email body:

Your Full Name:
// as you write it on the IETF registration form

Current Primary Affiliation:
// Typically what goes in the Company field
// in the IETF Registration Form

Emails:
// All email addresses used to register for the past 5 IETF meetings // Preferred email address first

Telephone:
// For confirmation if selected

You should expect an email response from me within 5 business days statin= g whether or not you are qualified. If you don't receive this response, = please re-send your email with the tag "RESEND"" added to the subject lin= e.

If you are not yet sure if you would like to volunteer, please consider t= hat NomCom members play a very important role in shaping the leadership o= f the IETF. Questions by email or voice are welcome. Volunteering for th= e NomCom is a great way to contribute to the IETF!

You can find a detailed timeline on the NomCom web site at:
https://datatracker.ietf.org/nomcom/2020/

I will be publishing a more detailed target timetable, as well as details= of the randomness seeds to be used for the RFC 3797 selection process, w= ithin the next few weeks.

Thank you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2020 at ietf dot org

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--=_MailMate_069B70FB-8F01-40D8-A1C3-D530B7D30532_=-- From nobody Sat Jun 13 09:58:44 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3293A0B92 for ; Sat, 13 Jun 2020 09:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.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 zTXWq7nLsZAA for ; Sat, 13 Jun 2020 09:58:41 -0700 (PDT) Received: from giant.ash.relay.mailchannels.net (giant.ash.relay.mailchannels.net [23.83.222.68]) (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 D06AC3A0B8D for ; Sat, 13 Jun 2020 09:58:40 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6E258640C83; Sat, 13 Jun 2020 16:58:36 +0000 (UTC) Received: from pdx1-sub0-mail-a61.g.dreamhost.com (100-97-68-20.trex.outbound.svc.cluster.local [100.97.68.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C9AD9640BDF; Sat, 13 Jun 2020 16:58:35 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from pdx1-sub0-mail-a61.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Sat, 13 Jun 2020 16:58:36 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|ldaigle@thinkingcat.com X-MailChannels-Auth-Id: dreamhost X-Illegal-Fumbling: 06161cbb26c450e0_1592067516275_1622519090 X-MC-Loop-Signature: 1592067516275:3392727918 X-MC-Ingress-Time: 1592067516275 Received: from pdx1-sub0-mail-a61.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTP id 8BAE083102; Sat, 13 Jun 2020 09:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:mime-version:content-type; s= thinkingcat.com; bh=GEBQpbohzQpKo0zaj3qm7uPwAn4=; b=kqbw5xX5KpFZ c6iQpl6ga+G0L0WouE2XmrVllgYymSJsagYD62v0F2YsCG6v6LaZnFxLEDHsWZhv X89ZViiwUoM3JYockexbrxzb2RLeg2soRhuHdYVmFQ5jQEkl8mxdZWe0c5qAplTU G/XwBOAHC9eYNz8orxKr9ntlA4VlG8c= Received: from [192.168.1.57] (vtelinet-216-66-102-83.vermontel.net [216.66.102.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ldaigle@thinkingcat.com) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTPSA id DD76C830BB; Sat, 13 Jun 2020 09:58:34 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a61 From: "Leslie Daigle" To: mops@ietf.org Date: Sat, 13 Jun 2020 12:58:25 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <9EAA7716-147D-4A93-81F5-5969ABEBAB3B@thinkingcat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_C0B1E970-99DC-4F50-B782-06620AD938F2_=" X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeifedguddtkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffoffkgggtsegrtdhmreertdejnecuhfhrohhmpedfnfgvshhlihgvucffrghighhlvgdfuceolhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomheqnecuggftrfgrthhtvghrnhepgfejhfeuhfekjefgveevfefghfetfeeitdefteejueekffdulefggeeulefhudehnecuffhomhgrihhnpegvlhgvtggrrhgurdgtohhmnecukfhppedvudeirdeiiedruddtvddrkeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurdehjegnpdhinhgvthepvdduiedrieeirddutddvrdekfedprhgvthhurhhnqdhprghthhepfdfnvghslhhivgcuffgrihhglhgvfdcuoehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmqedpmhgrihhlfhhrohhmpehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmpdhnrhgtphhtthhopehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhm Archived-At: Subject: [Mops] Low latency protocol comparision X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 16:58:43 -0000 --=_MailMate_C0B1E970-99DC-4F50-B782-06620AD938F2_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable I thought this was a pretty interesting analysis: Low broadcast latency and protocols for implementation thereof: https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_impl= ementation_thereof Particularly telling is the chart at the end: WebRTC and SRT don=E2=80=99= t = look very similar, in this particular regard. Leslie. -- = ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- --=_MailMate_C0B1E970-99DC-4F50-B782-06620AD938F2_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I thought this was a pretty interesting analysis:

Low broadcast latency and protocols for implementation th= ereof:
https://www.elecar= d.com/page/low_broadcast_latency_and_protocols_for_implementation_thereof=

Particularly telling is the chart at the end: WebRTC and= SRT don=E2=80=99t look very similar, in this particular regard.

Leslie.

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com

--=_MailMate_C0B1E970-99DC-4F50-B782-06620AD938F2_=-- From nobody Sat Jun 13 15:34:19 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06F33A00B2 for ; Sat, 13 Jun 2020 15:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3OHR0G9V6Q7 for ; Sat, 13 Jun 2020 15:34:16 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC02E3A003C for ; Sat, 13 Jun 2020 15:34:15 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id z2so12046051ilq.0 for ; Sat, 13 Jun 2020 15:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nf8nrrwCYjNqwWBjr4lnNVK2VS8aIH36kA2tSGkQxWc=; b=HLH5aS6iTjLhJDnQ8BvqoIN6KYu+q3bS8bJ60wgAUW4YSUCqcpGHYT/70spIit9sq4 QPrZMDdXamGgm7F95LSCjNd6OUIsWQgt1lsdPn/T0T9/sCBFtPLjPV11S6WujGoNfEl9 PNh7hDlw6/4sIzmn6V1v3HjP8wO6OWAvMClAvKsIXG2wzGNFT5AmmBWeVMl6C8wySbpE vaUCNuPijfdBUYH6eM5hkok6ZNr01rmFdD+/hdu6C+qp1gP6Uy1rpaEbr81ooHAVAgzi iK7STKkzLIp63LYNR1moI+YRQaSId5p25GLryDnYpeH708ywMx3/P7jyK42Se09HhpF3 l2Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nf8nrrwCYjNqwWBjr4lnNVK2VS8aIH36kA2tSGkQxWc=; b=OOs8h0wj6Vc95v/pZDG8rggxzdXFA7HaiNx+ZTLkHK5s3aBposMiz6H4PQBcFgpSX7 zSSdHso+u2cvXIwGmi1RbhJEIIlGOCXX1D8Mq4CbGdaCEA3MA+dbs+A1VwC+utJe/BG5 PqqC8Ynb+NIOUjtgmZQooI9EFk8Qfc2dM3f4cWce1CyoEzLTiex9dvvqtAjlv59Dxnqm d7oERw7QNbyrLV02PigRzWZQMt28W0AAMWMRmTwyMhA5Y/t1SKFJlEQPeo14VvhsPIza 3IFOWjm3oO33eTBnnvm00ie6cNAkiylQAtYbvKva0piN+lyKPGhET6CV0mBwp27fyBOL gOzA== X-Gm-Message-State: AOAM532LwuglNW8Eqd2p0e3fSXdTLh0rT/Kb/elNLreyGYFIfn6SyrEH Sv1Ljc/wZzhLqN+b6sWEe3WTirKXuGeRImW9tos= X-Google-Smtp-Source: ABdhPJxKCEou2zp8UqD0cn7T/49EISrS3lSsCh9l2sEMQU8YZYHiMcBCYQ/b6SeuwWbimLHWeqh5QS1u2yg09vBFBho= X-Received: by 2002:a92:5b86:: with SMTP id c6mr20343693ilg.100.1592087654702; Sat, 13 Jun 2020 15:34:14 -0700 (PDT) MIME-Version: 1.0 References: <9EAA7716-147D-4A93-81F5-5969ABEBAB3B@thinkingcat.com> In-Reply-To: <9EAA7716-147D-4A93-81F5-5969ABEBAB3B@thinkingcat.com> From: Alexandre GOUAILLARD Date: Sun, 14 Jun 2020 00:34:03 +0200 Message-ID: To: Leslie Daigle Cc: mops@ietf.org Content-Type: multipart/alternative; boundary="0000000000001c24d205a7fecba2" Archived-At: Subject: Re: [Mops] Low latency protocol comparision X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 22:34:18 -0000 --0000000000001c24d205a7fecba2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are multiple inaccurate statements in the linked documents. Most of them that have been carried around for many years by other SRT vendors like Wowza and already called out (here for example). I'm just going to point to three of the most egregious (read "verifiably wrong") statements, that by themselves undermine the credibility of the entire document. - "Maximum supported resolution: 720p, 30 frames per second with a bit rate of up to 2 Mbps." - There is no limit to the spatial and temporal resolution in webrtc/rtcweb protocol. Stadia for example send up to 4K@30fps. "WebRTC is inferior to its colleagues in terms of the coding quality and maximum amount of transmitted data. - There is no limit to the bandwidth used in the webrtc/rtcweb protocol. - There is a limit of 2Mbps per peer connection on the sending-side *only in the google chrome implementation*, only by default (web application can lift this limit), and only for webcams devices (screensharing has no bandwidth limit). This is a chrome implementation detail, and not a protocol limit. -While VP8 and H264 are both mandatory to implement (original IETF discussion = ) anybody can add any codec to webrtc as long as an RTP payload specification exists. -- Google chrome, and firefox, both supports real-time VP9 mode 2 (4:4:4, 10 bits, HDR) https://source.chromium.org/chromium/chromium/src/+/master:third_party/webr= tc/modules/video_coding/codecs/vp9/vp9_impl.cc;l=3D985 -- Chrome has a real-time AV1 implementation in webrtc, which goes up to high profile (4:4:4, 8~10bits, HDR). https://source.chromium.org/chromium/chromium/src/+/master:third_party/webr= tc/modules/video_coding/codecs/av1/ In terms of quality, only codecs at high profile (i.e. 12bits) can do better, and none of those have a "real-time" version today. In terms of coding efficiency, AV1 is still the best codec available in production. "WebRTC is not available in Safari and partially unavailable in Bowser and Edge." - webrtc is fully available in Edge, and Safari. https://caniuse.com/#search=3Dwebrtc official daily W3C results: https://wpt.fyi/results/?label=3Dmaster&label=3Dexperimental&aligned&q=3Dwe= brtc - Safari has added H.265 support in addition to the mandatory to implement VP8 and H.264 in the latest safari tech preview. I'm not going into the Discussion about webrtc's underlying RTC/RTCP protocol and corresponding extension: NACK, RTX, FEC, RED, or Congestion Control (REMB, Google-cc, BBR, NADA), as IETF members I'm sure you re all aware of RFC3550 and all its derivatives. Many authors of those RFCs are part of this group. Maybe more overlooked is the most recent Draft for end-to-end encryption on top of webrtc co-authored by google: https://tools.ietf.org/html/draft-omara-sframe-00 I'm not saying that SRT is worse, or better than WebRTC. I'm just saying, this comparison is not egregiously incorrect, and I'm a little bit surprised that we are discussing marketing blogs that go in the face of so many IETF specs. If anybody is interested in going deep into a real thorough comparison between all those protocols, why not doing it during the IETF hackathon in July, or in october (hopefully in BKK) just like we did group co-testing with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF hackathons? Regards, On Sat, Jun 13, 2020 at 6:58 PM Leslie Daigle wrote: > I thought this was a pretty interesting analysis: > > Low broadcast latency and protocols for implementation thereof: > > https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_impl= ementation_thereof > > Particularly telling is the chart at the end: WebRTC and SRT don=E2=80=99= t look > very similar, in this particular regard. > > Leslie. > > -- > ------------------------------ > > Leslie Daigle > Principal, ThinkingCat Enterprises > ldaigle@thinkingcat.com > -- > Mops mailing list > Mops@ietf.org > https://www.ietf.org/mailman/listinfo/mops > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- President - CoSMo Software Consulting, Singapore ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --0000000000001c24d205a7fecba2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are multiple inaccur= ate statements in the linked documents. Most of them that have been carried= around for many years by other SRT vendors like Wowza and already called o= ut (here for example).

<= div>I'm just going to point=C2=A0to three of the most egregious=C2=A0(r= ead "verifiably wrong") statements, that by themselves undermine = the credibility of the entire document.

- &= quot;Maximum supported resolution: 720p, 30 frames per second with a bit ra= te of up to 2 Mbps."
- There is no limit to the spatial and tempora= l resolution in webrtc/rtcweb protocol.
Stadia for ex= ample send up to 4K@30fps.

"WebRTC is inferior to its colleagues in terms of the coding quality = and maximum amount of transmitted data.
- There is no= limit to the bandwidth used in the webrtc/rtcweb protocol.
- There is a limit of 2Mbps per peer connection on the sending-sid= e only in the google chrome implementation, only by default (web app= lication can lift this limit), and only for webcams devices (screensharing = has no bandwidth limit). This is a chrome implementation detail, and not a = protocol limit.
-While VP8 and H264 are both mandatory to impleme= nt (original IETF discussion) anybody can add any codec to w= ebrtc as long as an RTP payload specification exists.
-- Google chrome, and firefox, both supports real-time VP9 mode 2 (4:4:4, = 10 bits, HDR)
-- Chrome has a real-time AV1 impleme= ntation in webrtc, which goes up to high profile (4:4:4, 8~10bits, HDR).
In terms of quality,= only codecs at high profile (i.e. 12bits) can do better, and none of those= have a "real-time" version today.
In terms= of coding efficiency, AV1 is still the best codec available in production.=

"WebRTC is not available in Safari and partially unavailable i= n Bowser and Edge."
- webrtc is fully available in Edge, and= Safari.
- Safari = has added H.265 support in addition to the mandatory to implement VP8 and H= .264 in the latest safari tech preview.

I'm not going into the Discussion about webrtc's underlying RTC/R= TCP protocol and corresponding extension: NACK, RTX, FEC, RED, or Congestio= n Control (REMB, Google-cc, BBR, NADA), as IETF members I'm sure you re= all aware of RFC3550 and all its derivatives. Many authors of those RFCs a= re part of this group.

Maybe more overlooked is th= e most recent Draft for end-to-end encryption on top of webrtc co-authored = by google:

I'm not saying that SRT is worse, or better than WebRTC= . I'm just saying, this comparison is not egregiously incorrect, and I&= #39;m a little bit surprised that we are discussing marketing blogs that go= in the face of so many IETF specs.=C2=A0

If anybo= dy is interested in going deep into a real =C2=A0thorough comparison betwee= n all those protocols, why not doing it during the IETF hackathon in July, = or in october (hopefully in BKK) just like we did group co-testing with IET= F's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF hackathons= ?

Regards,



On Sat, Jun 13, 2020 at 6:= 58 PM Leslie Daigle <ldaigle@= thinkingcat.com> wrote:

I thought this was a pretty interesting analysis:

Low broadcast latency and protocols for implementation ther= eof:
https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_im= plementation_thereof

Particularly telling is the chart at the end: WebRTC and S= RT don=E2=80=99t look very similar, in this particular regard.

Leslie.

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com=

--
Mops mailing list
Mops@ietf.org
https://www.ietf.org/mailman/listinfo/mops


--
Alex. Gouaillard, PhD, PhD, MBA
-------------= -----------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
---------= ---------------------------------------------------------------------------=

--0000000000001c24d205a7fecba2-- From nobody Sat Jun 13 15:41:52 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8933A03FF for ; Sat, 13 Jun 2020 15:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.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 tQKdGfHPNbFN for ; Sat, 13 Jun 2020 15:41:46 -0700 (PDT) Received: from chocolate.birch.relay.mailchannels.net (chocolate.birch.relay.mailchannels.net [23.83.209.35]) (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 E98563A03F3 for ; Sat, 13 Jun 2020 15:41:45 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D51FB20B57; Sat, 13 Jun 2020 22:41:44 +0000 (UTC) Received: from pdx1-sub0-mail-a61.g.dreamhost.com (100-96-22-28.trex.outbound.svc.cluster.local [100.96.22.28]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3689D20872; Sat, 13 Jun 2020 22:41:44 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from pdx1-sub0-mail-a61.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Sat, 13 Jun 2020 22:41:44 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|ldaigle@thinkingcat.com X-MailChannels-Auth-Id: dreamhost X-Chief-Daffy: 7341c2c522d41005_1592088104684_1368413538 X-MC-Loop-Signature: 1592088104684:2455384564 X-MC-Ingress-Time: 1592088104683 Received: from pdx1-sub0-mail-a61.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTP id DD13E91F83; Sat, 13 Jun 2020 15:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type; s=thinkingcat.com; bh=cSm3Z1Jp52IfqiTU65UPjzMSgUQ =; b=X30vFWT0ynh2JV0K11RSmQcqqqTDGNftWk7QXeKutECI8x1eufa/B/JJq9b Ue4vicAXCnVm6aj2LnS1VA4Q6OW7QzexGwjiEUjZaX8sBnRX7CEo9loHm0dw87vU b6saZWBKO9B2WlRznSV/Fbcb12FlAqeMO/tLwrjtH6MeVew8= Received: from [192.168.1.57] (vtelinet-216-66-102-83.vermontel.net [216.66.102.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ldaigle@thinkingcat.com) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTPSA id E41D2838E4; Sat, 13 Jun 2020 15:41:41 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a61 From: "Leslie Daigle" To: "Alexandre GOUAILLARD" Cc: mops@ietf.org Date: Sat, 13 Jun 2020 18:41:32 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <0807B637-529D-4F69-834B-80304DD5F276@thinkingcat.com> In-Reply-To: References: <9EAA7716-147D-4A93-81F5-5969ABEBAB3B@thinkingcat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_FB2BA0C3-DE83-475A-ACED-55A39E95F324_=" Embedded-HTML: [{"HTML":[1217, 8031], "plain":[576, 4569], "uuid":"7108787B-A899-4249-A418-55FE735A5899"}] X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeigedgudegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffoffkjghfgggtsegrtdhmreertdejnecuhfhrohhmpedfnfgvshhlihgvucffrghighhlvgdfuceolhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomheqnecuggftrfgrthhtvghrnhepveejvdehgfeuffeuteevtedvgfelheevgedutdeikeejfffgueegueffleehvdegnecuffhomhgrihhnpeifvggsrhhttggshigurhgrlhgvgidrtghomhdpihgvthhfrdhorhhgpdgthhhrohhmihhumhdrohhrghdptggrnhhiuhhsvgdrtghomhdpfihpthdrfhihihdpvghlvggtrghrugdrtghomhdplhhinhhkvgguihhnrdgtohhmnecukfhppedvudeirdeiiedruddtvddrkeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurdehjegnpdhinhgvthepvdduiedrieeirddutddvrdekfedprhgvthhurhhnqdhprghthhepfdfnvghslhhivgcuffgrihhglhgvfdcuoehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmqedpmhgrihhlfhhrohhmpehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtoh hmpdhnrhgtphhtthhopehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhm Archived-At: Subject: Re: [Mops] Low latency protocol comparision X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 22:41:51 -0000 --=_MailMate_FB2BA0C3-DE83-475A-ACED-55A39E95F324_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi, [You wrote:] > If anybody is interested in going deep into a real thorough = > comparison > between all those protocols, why not doing it during the IETF = > hackathon in > July, or in october (hopefully in BKK) just like we did group = > co-testing > with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF > hackathons? Volunteering? :-> If there=E2=80=99s interest in doing it, along the specific vector of vid= eo = delivery, and willingness to write it up as an I-D afterwards, I think = it would be great. Leslie. On 13 Jun 2020, at 18:34, Alexandre GOUAILLARD wrote: > There are multiple inaccurate statements in the linked documents. Most = > of > them that have been carried around for many years by other SRT vendors = > like > Wowza and already called out (here > > for example). > > I'm just going to point to three of the most egregious (read = > "verifiably > wrong") statements, that by themselves undermine the credibility of = > the > entire document. > > - "Maximum supported resolution: 720p, 30 frames per second with a bit = > rate > of up to 2 Mbps." > - There is no limit to the spatial and temporal resolution in = > webrtc/rtcweb > protocol. > Stadia for example send up to 4K@30fps. > > "WebRTC is inferior to its colleagues in terms of the coding quality = > and > maximum amount of transmitted data. > - There is no limit to the bandwidth used in the webrtc/rtcweb = > protocol. > - There is a limit of 2Mbps per peer connection on the sending-side = > *only > in the google chrome implementation*, only by default (web application = > can > lift this limit), and only for webcams devices (screensharing has no > bandwidth limit). This is a chrome implementation detail, and not a > protocol limit. > -While VP8 and H264 are both mandatory to implement (original IETF > discussion > ) > anybody can add any codec to webrtc as long as an RTP payload = > specification > exists. > -- Google chrome, and firefox, both supports real-time VP9 mode 2 = > (4:4:4, > 10 bits, HDR) > https://source.chromium.org/chromium/chromium/src/+/master:third_party/= webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc;l=3D985 > -- Chrome has a real-time AV1 implementation in webrtc, which goes up = > to > high profile (4:4:4, 8~10bits, HDR). > https://source.chromium.org/chromium/chromium/src/+/master:third_party/= webrtc/modules/video_coding/codecs/av1/ > In terms of quality, only codecs at high profile (i.e. 12bits) can do > better, and none of those have a "real-time" version today. > In terms of coding efficiency, AV1 is still the best codec available = > in > production. > > "WebRTC is not available in Safari and partially unavailable in Bowser = > and > Edge." > - webrtc is fully available in Edge, and Safari. > https://caniuse.com/#search=3Dwebrtc > official daily W3C results: > https://wpt.fyi/results/?label=3Dmaster&label=3Dexperimental&aligned&q=3D= webrtc > - Safari has added H.265 support in addition to the mandatory to = > implement > VP8 and H.264 in the latest safari tech preview. > > I'm not going into the Discussion about webrtc's underlying RTC/RTCP > protocol and corresponding extension: NACK, RTX, FEC, RED, or = > Congestion > Control (REMB, Google-cc, BBR, NADA), as IETF members I'm sure you re = > all > aware of RFC3550 and all its derivatives. Many authors of those RFCs = > are > part of this group. > > Maybe more overlooked is the most recent Draft for end-to-end = > encryption on > top of webrtc co-authored by google: > https://tools.ietf.org/html/draft-omara-sframe-00 > > I'm not saying that SRT is worse, or better than WebRTC. I'm just = > saying, > this comparison is not egregiously incorrect, and I'm a little bit > surprised that we are discussing marketing blogs that go in the face = > of so > many IETF specs. > > If anybody is interested in going deep into a real thorough = > comparison > between all those protocols, why not doing it during the IETF = > hackathon in > July, or in october (hopefully in BKK) just like we did group = > co-testing > with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF > hackathons? > > Regards, > > > > On Sat, Jun 13, 2020 at 6:58 PM Leslie Daigle = > > wrote: > >> I thought this was a pretty interesting analysis: >> >> Low broadcast latency and protocols for implementation thereof: >> >> https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_i= mplementation_thereof >> >> Particularly telling is the chart at the end: WebRTC and SRT don=E2=80= =99t = >> look >> very similar, in this particular regard. >> >> Leslie. >> >> -- >> ------------------------------ >> >> Leslie Daigle >> Principal, ThinkingCat Enterprises >> ldaigle@thinkingcat.com >> -- >> Mops mailing list >> Mops@ietf.org >> https://www.ietf.org/mailman/listinfo/mops >> > > > -- = > Alex. Gouaillard, PhD, PhD, MBA > -----------------------------------------------------------------------= ------------- > President - CoSMo Software Consulting, Singapore > -----------------------------------------------------------------------= ------------- > sg.linkedin.com/agouaillard > > - -- = ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- --=_MailMate_FB2BA0C3-DE83-475A-ACED-55A39E95F324_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

[You wrote:]

I= f anybody is interested in going deep into a real thorough comparison between all those protocols, why not doing it during the IETF hackathon i= n
July, or in october (hopefully in BKK) just like we did group co-testing<= br> with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF
hackathons?

Volunteering? :->

If there=E2=80=99s interest in doing it, along the specif= ic vector of video delivery, and willingness to write it up as an I-D aft= erwards, I think it would be great.

Leslie.

On 13 Jun 2020, at 18:34, Alexandre GOUAILLARD wrote:

=
There are multiple inacc= urate statements in the linked documents. Most of them that have been car= ried around for many years by other SRT vendors like Wowza and already ca= lled out (here for example).
<= br>
I'm just going to point=C2=A0to three of the most egreg= ious=C2=A0(read "verifiably wrong") statements, that by themsel= ves undermine the credibility of the entire document.

- "Maximum supported resolution: 720p, 30 frames per se= cond with a bit rate of up to 2 Mbps."
- There is no limit to the= spatial and temporal resolution in webrtc/rtcweb protocol.
Stadia for example send up to 4K@30fps.
"WebRTC is inferior to its colleagues in te= rms of the coding quality and maximum amount of transmitted data.
- There is no limit to the bandwidth used in the webrtc/rt= cweb protocol.
- There is a limit of 2Mbps per peer= connection on the sending-side only in the google chrome implementati= on, only by default (web application can lift this limit), and only f= or webcams devices (screensharing has no bandwidth limit). This is a chro= me implementation detail, and not a protocol limit.
-While VP8 = and H264 are both mandatory to implement (original IETF disc= ussion) anybody can add any codec to webrtc as long as an RTP payload= specification exists.
-- Google chrome, and firefo= x, both supports real-time VP9 mode 2 (4:4:4, 10 bits, HDR)
https://source.chromium.org/chromium/chromium/src/+/master:third_par= ty/webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc;l=3D985
-- Chrome has a real-time AV1 implementation in webrtc= , which goes up to high profile (4:4:4, 8~10bits, HDR).
In terms of quality, only c= odecs at high profile (i.e. 12bits) can do better, and none of those have= a "real-time" version today.
In terms of= coding efficiency, AV1 is still the best codec available in production.<= br>
"WebRTC is not available in Safari and partially unavailable = in Bowser and Edge."
- webrtc is fully available in Edge, = and Safari.
<= div>- Safari has added H.265 support in addition to the mandatory to impl= ement VP8 and H.264 in the latest safari tech preview.

I'm not going into the Discussion about webrtc'= ;s underlying RTC/RTCP protocol and corresponding extension: NACK, RTX, F= EC, RED, or Congestion Control (REMB, Google-cc, BBR, NADA), as IETF memb= ers I'm sure you re all aware of RFC3550 and all its derivatives. Man= y authors of those RFCs are part of this group.

= Maybe more overlooked is the most recent Draft for end-to-end encryption = on top of webrtc co-authored by google:

I'm not saying that = SRT is worse, or better than WebRTC. I'm just saying, this comparison= is not egregiously incorrect, and I'm a little bit surprised that we= are discussing marketing blogs that go in the face of so many IETF specs= =2E=C2=A0

If anybody is interested in going deep= into a real =C2=A0thorough comparison between all those protocols, why n= ot doing it during the IETF hackathon in July, or in october (hopefully i= n BKK) just like we did group co-testing with IETF's AVTCORE/AVEXT/QU= IC/RTCWEB/RMCAT during the previous IETF hackathons?

=
Regards,


<= /div>

On Sat, Jun 13, 2020 at 6:58 PM Leslie Dai= gle <ldaigle@thinkingcat.co= m> wrote:

I thought this was a pretty interesting analysis:

Low broadcast latency and protocols for implementation th= ereof:
https://www.elecard.com/page/low_broadcast_latency_and_protocols_= for_implementation_thereof

Particularly telling is the chart at the end: WebRTC and= SRT don=E2=80=99t look very similar, in this particular regard.

Leslie.

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com=

--
Mops mailing list
Mops@ietf.org
https://www.ietf.org/mailman/listinfo/mops


--
Alex. Gouaillard, PhD, PhD, MBA
--------= -------------------------------------------------------------------------= ---
President - CoSMo Software Consulting, Singapore
= -------------------------------------------------------------------------= -----------

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com

--=_MailMate_FB2BA0C3-DE83-475A-ACED-55A39E95F324_=-- From nobody Sat Jun 13 16:05:55 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F853A0771 for ; Sat, 13 Jun 2020 16:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAFvBenPXpTz for ; Sat, 13 Jun 2020 16:05:51 -0700 (PDT) Received: from mx0a-00176a04.pphosted.com (mx0b-00176a04.pphosted.com [67.231.157.49]) (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 0CAD03A0770 for ; Sat, 13 Jun 2020 16:05:50 -0700 (PDT) Received: from pps.filterd (m0048207.ppops.net [127.0.0.1]) by m0048207.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 05DN2Ip7042965 for ; Sat, 13 Jun 2020 19:05:49 -0400 Received: from usushmgip004.mail.tfayd.com ([216.178.109.223]) by m0048207.ppops.net-00176a04. with ESMTP id 31mt2eyy3j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 13 Jun 2020 19:05:49 -0400 IronPort-SDR: RkgvL5LaEUCxZIlGKL2RCpwYDHJmNG6xYDCMO5r3TNOYEAio3YyZSmTlPLM4j4qO0qgIV9Ju7h 1oFRakShcwpA== Received: from unknown (HELO potemwp00007.mail.tfayd.com) ([100.124.56.31]) by USUSHMGIP004.mail.tfayd.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 13 Jun 2020 19:05:48 -0400 Received: from potemwp00001.mail.tfayd.com (100.124.56.25) by potemwp00006.mail.tfayd.com (100.124.56.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5; Sat, 13 Jun 2020 17:05:46 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (10.40.33.204) by potemwp00001.mail.tfayd.com (100.124.56.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5 via Frontend Transport; Sat, 13 Jun 2020 17:05:46 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S3TFcjhM2/+BExl5JWAefPI5NJaoQ53rjfGqR2rjwu52Nu9O4oLfWDJ9Mn2rZ8ZKXeFy3Xy7jQ9k3X+NLrTFAqqQgruNoF8XrxBqzQVkIrFYjXYnNB5Zda9AqVCabtITmtqdrNUCqfoaM0HjCOfs1cg/rRPYL00kVB3bfRzwd2X2S+DIF4t+jkH8H0rxKWVZdij8TItH67gZECvqYMWH5mf3E351jHkWz3iQ67oDvIAD2K+VYj0FutZRhzC8+uRhDFOs/oHIJ3k/4O+J2zMB0Ca7wf8DOwA/UH2ZTSw0tKSz/DF2G+cjZWSKNxQlidWiWfriVmPZGkafoKgJdBsXfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8qxyJCKSDrZGszyx3H5wY/+TDhLzG9STMWVAZd1W2i0=; b=G4NzCcN5ZP6aYBk68i4ts5QyIVVxWFuz9BJ2eIeDiEc7kimsxamyGO5XQR3oH+FuV/E14haFcphS9GoSoUe/ODAI8GPdkArwmAqjj8icHcLZ5+HY3YzoX6hUDwhtxSFE76PJgDKqBoWV9P/78l5Jr7HxWuBEsopqzqxa5OXawlUUewJ57d0NDBCfPiMSABNQhpqIhS4kGy8C8ohEKoEhfYBk8q6wj7qDPRztxiFfzOxBQ7rsqAEaxB+6Uvuqbt3tRIrPxzP0si6KOT1YDhN8A8tCwQJilZx2b76hKfgxdl2//7B/cu6SEZXW9r0wXmxsN5AwX5OKHZaCAtUe8uIHFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8qxyJCKSDrZGszyx3H5wY/+TDhLzG9STMWVAZd1W2i0=; b=WJT0Mi1vByieBqouuVZcL7vM2bum6EbVXqsAIqpCV5IW2XL6Mh2+gPpzhg1LCrvtwyfuohuIE30Pj7L4SRj6PbHza0u7Ux0MpvhF1XbvhuPly5+pPKeYyw04KEQYYZf6WtPgIc8JUiOZlA80ji2hn/A89o/U7RP3a9+22G7qqno= Received: from BYAPR14MB3094.namprd14.prod.outlook.com (2603:10b6:a03:14d::30) by BYAPR14MB3238.namprd14.prod.outlook.com (2603:10b6:a03:d8::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.25; Sat, 13 Jun 2020 23:05:44 +0000 Received: from BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::e074:901e:d085:be5c]) by BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::e074:901e:d085:be5c%7]) with mapi id 15.20.3088.026; Sat, 13 Jun 2020 23:05:44 +0000 From: "Deen, Glenn (NBCUniversal)" To: Alexandre GOUAILLARD CC: Leslie Daigle , "mops@ietf.org" Thread-Topic: [Mops] Low latency protocol comparision Thread-Index: AQHWQdcq8Q+Yi3u+70+RPiLbZImHfA== Date: Sat, 13 Jun 2020 23:05:43 +0000 Message-ID: <17635DFD-B536-4B22-8A5D-314BCBEFF19C@nbcuni.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nbcuni.com; dkim=none (message not signed) header.d=none;nbcuni.com; dmarc=none action=none header.from=nbcuni.com; x-originating-ip: [2605:e000:141b:121:ad32:16f1:5adc:8d37] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55caa450-ee1c-4216-6029-08d80fee4d03 x-ms-traffictypediagnostic: BYAPR14MB3238: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0433DB2766 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3fDXGZk+yt43DAFUEfHZT5tOD5N7qppaTehIfW+1oHaotQ0fNuSpFOZNClSnYiQ2zXesF3JSXkd2XjvfvlqrM0JzI/9bb3H51O/Uu/9gU/IGcIHl3+mB4roGS1PmHKY+N+bhsOWBHgG8q4Vdewc59whD9QPQWXbpBU59T64i+GOEoCnDHP8Yl5kHTWh0RoUePs8+ZqUXsn6MmNBd1U8Or152M6rsBGUAjGfr8hC6+d/L+Whvdb9FfMrSIbo218A+a5tfTos0htXjNOtvAb6CaKHOJHdbUKAclvdrwL5cyIixJYQtptCsA347vq+7FTCufp7oUMVldD4YJ7dXRG65QSBe9a5H4nWcqmB/WTwVTqi8CgHaob545UL7R81LM6+sEB7uNWCoJrSUCg2BdoKx2w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR14MB3094.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(136003)(376002)(39860400002)(396003)(2906002)(6486002)(2616005)(478600001)(966005)(66556008)(66476007)(6916009)(53546011)(5660300002)(6506007)(66946007)(66446008)(64756008)(45080400002)(36756003)(6512007)(186003)(7066003)(166002)(33656002)(8676002)(86362001)(16799955002)(54906003)(4326008)(316002)(8936002)(76116006)(71200400001)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 3M5fC9WiCy9j39TnhUL4uYAgnDCWNzfAju43Ha65sZMGp0dPG+4baTsU/xky3j+wE8WhHULMfp26DYKzXwLOxlunxcINLwlsSo54GqiENmcrIE/BoiMSH3Tzky7g0AdiQmLw7awI+r5/dMqcbJwQn36fEQWyVmSds+kpv61zQ0hJQXS2ZfJx8YxrhJwOfnhG73JS4DtQLGhxq7+Pqdqh2/IP8c7EnXSM95xzG7Q51pQCKZnUNVrZtokOUyuJnr0vW5yvDZ8x8ArT35JFWOjYk5+V/X8Ds56HqLMQOD8KdkAtCBmH3Y2t9sVA8SwObtPSbCPnGxMAbRHQQsguc7lz/D2r64/0vc3jajJWbCo55n0zGUCBCL9wMfGj1x66qijd02T+vGJu115pH58ylDmwXI/FhX5SRpaMZuTcDGwj/zsRiFwZzBJTRQPTSDQsmbPiPxu2CJN0y6Ig5hmIsD+7GUq7CAlT+ucwfhxt5JqpKPJ7JdXcRGhBN6vAhOtpMXMxmpQSHljlyzjQ5b8fdphNwXJM63LxBjITC4dc62MBKBbc3/7xsK/ZT0OuYg3n8I1q Content-Type: multipart/alternative; boundary="_000_17635DFDB5364B228A5D314BCBEFF19Cnbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 55caa450-ee1c-4216-6029-08d80fee4d03 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2020 23:05:43.9916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: c7IqNXirtWbFAG0WGbnmtmZBRuy0ZqF3JTq09U96mJIqU+Ga7Ttls46JtxJlTLZgf9SZoRhVS8lyW4tdwLqyaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR14MB3238 X-OriginatorOrg: nbcuni.com X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-13_11:2020-06-12, 2020-06-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 adultscore=0 clxscore=1011 cotscore=-2147483648 mlxscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006130203 Archived-At: Subject: Re: [Mops] Low latency protocol comparision X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 23:05:54 -0000 --_000_17635DFDB5364B228A5D314BCBEFF19Cnbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBpdOKAmXMgYSBiaXQgbWFya2V0aW5nLCBidXQgaXTigJlzIGFsc28gb25lIG9mIHRoZSBm ZXcgd3JpdGUgdXBzIHRoYXQgYXR0ZW1wdHMgdG8gcHV0IHRoZSBwb3B1bGFyIG1lZGlhIHRyYW5z cG9ydHMgc2lkZSBieSBzaWRlIGZvciBwZW9wbGUgdG8gdW5kZXJzdGFuZCB0aGVpciBzdHJlbmd0 aHMgYW5kIGFiaWxpdGllcy4gICBUaGUgbWFya2V0aW5nIGJsb2dzIGFsc28gZ2l2ZSB1cywgdGhl IElFVEYsIGluc2lnaHQgaW50byBob3cgdGhlIG91dHNpZGUgd29ybGQgb2YgYWRvcHRlcnMgYW5k IHNlbGxlcnMgb2Ygb3VyIHdvcmsgc2VlIHRoaW5ncy4NCg0KSSByZWFsbHkgd2lzaCB0aGF0IGFs bCB3ZWIgZG9jdW1lbnRzIGFuZCBwYWdlcyBjb250YWluZWQgYSBwb3N0aW5nIGRhdGUuICAgVGhp cyBvbmUgZG9lc27igJl0IGdhdmUgaXQgYSBkYXRlLiAgSG93ZXZlciwgdGhlIHBhZ2UgbXVzdCBi ZSBmcm9tIGF0IGxlYXN0IG1pZCAyMDE5IGFzIGl0IG1lbnRpb25zIHRoaW5ncyB0aGF0IHdlcmUg cmVsZWFzZWQgdGhlbi4NCg0KSSBsaWtlIHlvdXIgd3JpdGUgdXAgb2YgdGhlIFdlYlJUQyBpbmFj Y3VyYWNpZXMuICBJdCB3b3VsZCBiZSBncmVhdCBpZiBhbnkgU1JUIGZvbGtzIG9uIHRoaXMgbGlz dCBjb3VsZCBkbyBzb21ldGhpbmcgc2ltaWxhciwgIHRvIHRvIG1lbnRpb24gdGhvc2Ugd29ya2lu ZyB3aXRoIENNQUYgYW5kIExMIEhMUy4gIFRoZXJlIGEgbG90IG9mIGFkb3B0ZXJzIG91dCB0aGVy ZSB3aG8gYXJlIHdvcmtpbmcgdGhyb3VnaCB3aGF0IHByb3RvY29sIGJlc3QgZml0cyB0aGVpciBw YXJ0aWN1bGFyIG5lZWRzIC0gd2ViUlRDPyAgIFNSVD8gIFNvbWV0aGluZyB0aGF0IGJyaWdodCBz dW1tZXIgaW50ZXJuIHdyb3RlIHdoaWxlIHNoZSB3YXMgaGVyZSBsYXN0IHN1bW1lcj8NCg0KIENh cHR1cmluZyBzb21ldGhpbmcgbGlrZSB0aGlzLCBhbmQgZXZlbiBiZXR0ZXIgc29tZSBzb3J0IG9m IGJha2Ugb2ZmIGFzIHlvdSBzdWdnZXN0IHdvdWxkIGJlIHZhbHVhYmxlIHRvIGEgbG90IG9mIHBl b3BsZS4gIFRob3VnaCBpdCBtYXkgaGF2ZSB0byB3YWl0IHRvIGdldCBjcml0aWNhbCBtYXNzIG9m IHBhcnRpY2lwYW50cyB1bnRpbCBuZXh0IHllYXIuDQoNCkdsZW5uDQoNCk9uIEp1biAxMywgMjAy MCwgYXQgMzozNCBQTSwgQWxleGFuZHJlIEdPVUFJTExBUkQgPGFnb3VhaWxsYXJkQGdtYWlsLmNv bT4gd3JvdGU6DQoNCu+7vw0KVGhlcmUgYXJlIG11bHRpcGxlIGluYWNjdXJhdGUgc3RhdGVtZW50 cyBpbiB0aGUgbGlua2VkIGRvY3VtZW50cy4gTW9zdCBvZiB0aGVtIHRoYXQgaGF2ZSBiZWVuIGNh cnJpZWQgYXJvdW5kIGZvciBtYW55IHllYXJzIGJ5IG90aGVyIFNSVCB2ZW5kb3JzIGxpa2UgV293 emEgYW5kIGFscmVhZHkgY2FsbGVkIG91dCAoaGVyZTxodHRwOi8vd2VicnRjYnlkcmFsZXguY29t L2luZGV4LnBocC8yMDE5LzA1LzE4L3dvd3phcy1tYXJrZXRpbmctYXQtd29yay1hZ2Fpbi13ZWJy dGMvPiBmb3IgZXhhbXBsZSkuDQoNCkknbSBqdXN0IGdvaW5nIHRvIHBvaW50IHRvIHRocmVlIG9m IHRoZSBtb3N0IGVncmVnaW91cyAocmVhZCAidmVyaWZpYWJseSB3cm9uZyIpIHN0YXRlbWVudHMs IHRoYXQgYnkgdGhlbXNlbHZlcyB1bmRlcm1pbmUgdGhlIGNyZWRpYmlsaXR5IG9mIHRoZSBlbnRp cmUgZG9jdW1lbnQuDQoNCi0gIk1heGltdW0gc3VwcG9ydGVkIHJlc29sdXRpb246IDcyMHAsIDMw IGZyYW1lcyBwZXIgc2Vjb25kIHdpdGggYSBiaXQgcmF0ZSBvZiB1cCB0byAyIE1icHMuIg0KLSBU aGVyZSBpcyBubyBsaW1pdCB0byB0aGUgc3BhdGlhbCBhbmQgdGVtcG9yYWwgcmVzb2x1dGlvbiBp biB3ZWJydGMvcnRjd2ViIHByb3RvY29sLg0KU3RhZGlhIGZvciBleGFtcGxlIHNlbmQgdXAgdG8g NEtAMzBmcHMuDQoNCiJXZWJSVEMgaXMgaW5mZXJpb3IgdG8gaXRzIGNvbGxlYWd1ZXMgaW4gdGVy bXMgb2YgdGhlIGNvZGluZyBxdWFsaXR5IGFuZCBtYXhpbXVtIGFtb3VudCBvZiB0cmFuc21pdHRl ZCBkYXRhLg0KLSBUaGVyZSBpcyBubyBsaW1pdCB0byB0aGUgYmFuZHdpZHRoIHVzZWQgaW4gdGhl IHdlYnJ0Yy9ydGN3ZWIgcHJvdG9jb2wuDQotIFRoZXJlIGlzIGEgbGltaXQgb2YgMk1icHMgcGVy IHBlZXIgY29ubmVjdGlvbiBvbiB0aGUgc2VuZGluZy1zaWRlIG9ubHkgaW4gdGhlIGdvb2dsZSBj aHJvbWUgaW1wbGVtZW50YXRpb24sIG9ubHkgYnkgZGVmYXVsdCAod2ViIGFwcGxpY2F0aW9uIGNh biBsaWZ0IHRoaXMgbGltaXQpLCBhbmQgb25seSBmb3Igd2ViY2FtcyBkZXZpY2VzIChzY3JlZW5z aGFyaW5nIGhhcyBubyBiYW5kd2lkdGggbGltaXQpLiBUaGlzIGlzIGEgY2hyb21lIGltcGxlbWVu dGF0aW9uIGRldGFpbCwgYW5kIG5vdCBhIHByb3RvY29sIGxpbWl0Lg0KLVdoaWxlIFZQOCBhbmQg SDI2NCBhcmUgYm90aCBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IChvcmlnaW5hbCBJRVRGIGRpc2N1 c3Npb248aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydGN3ZWIvanVWc1pL cC1BbVJwWUxDZ3ktdXdhcnR1TnJZLz4pIGFueWJvZHkgY2FuIGFkZCBhbnkgY29kZWMgdG8gd2Vi cnRjIGFzIGxvbmcgYXMgYW4gUlRQIHBheWxvYWQgc3BlY2lmaWNhdGlvbiBleGlzdHMuDQotLSBH b29nbGUgY2hyb21lLCBhbmQgZmlyZWZveCwgYm90aCBzdXBwb3J0cyByZWFsLXRpbWUgVlA5IG1v ZGUgMiAoNDo0OjQsIDEwIGJpdHMsIEhEUikNCmh0dHBzOi8vc291cmNlLmNocm9taXVtLm9yZy9j aHJvbWl1bS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXI6dGhpcmRfcGFydHkvd2VicnRjL21vZHVsZXMv dmlkZW9fY29kaW5nL2NvZGVjcy92cDkvdnA5X2ltcGwuY2M7bD05ODUNCi0tIENocm9tZSBoYXMg YSByZWFsLXRpbWUgQVYxIGltcGxlbWVudGF0aW9uIGluIHdlYnJ0Yywgd2hpY2ggZ29lcyB1cCB0 byBoaWdoIHByb2ZpbGUgKDQ6NDo0LCA4fjEwYml0cywgSERSKS4NCmh0dHBzOi8vc291cmNlLmNo cm9taXVtLm9yZy9jaHJvbWl1bS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXI6dGhpcmRfcGFydHkvd2Vi cnRjL21vZHVsZXMvdmlkZW9fY29kaW5nL2NvZGVjcy9hdjEvDQpJbiB0ZXJtcyBvZiBxdWFsaXR5 LCBvbmx5IGNvZGVjcyBhdCBoaWdoIHByb2ZpbGUgKGkuZS4gMTJiaXRzKSBjYW4gZG8gYmV0dGVy LCBhbmQgbm9uZSBvZiB0aG9zZSBoYXZlIGEgInJlYWwtdGltZSIgdmVyc2lvbiB0b2RheS4NCklu IHRlcm1zIG9mIGNvZGluZyBlZmZpY2llbmN5LCBBVjEgaXMgc3RpbGwgdGhlIGJlc3QgY29kZWMg YXZhaWxhYmxlIGluIHByb2R1Y3Rpb24uDQoNCiJXZWJSVEMgaXMgbm90IGF2YWlsYWJsZSBpbiBT YWZhcmkgYW5kIHBhcnRpYWxseSB1bmF2YWlsYWJsZSBpbiBCb3dzZXIgYW5kIEVkZ2UuIg0KLSB3 ZWJydGMgaXMgZnVsbHkgYXZhaWxhYmxlIGluIEVkZ2UsIGFuZCBTYWZhcmkuDQpodHRwczovL2Nh bml1c2UuY29tLyNzZWFyY2g9d2VicnRjDQpvZmZpY2lhbCBkYWlseSBXM0MgcmVzdWx0czogaHR0 cHM6Ly93cHQuZnlpL3Jlc3VsdHMvP2xhYmVsPW1hc3RlciZsYWJlbD1leHBlcmltZW50YWwmYWxp Z25lZCZxPXdlYnJ0Yw0KLSBTYWZhcmkgaGFzIGFkZGVkIEguMjY1IHN1cHBvcnQgaW4gYWRkaXRp b24gdG8gdGhlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgVlA4IGFuZCBILi4yNjQgaW4gdGhlIGxh dGVzdCBzYWZhcmkgdGVjaCBwcmV2aWV3Lg0KDQpJJ20gbm90IGdvaW5nIGludG8gdGhlIERpc2N1 c3Npb24gYWJvdXQgd2VicnRjJ3MgdW5kZXJseWluZyBSVEMvUlRDUCBwcm90b2NvbCBhbmQgY29y cmVzcG9uZGluZyBleHRlbnNpb246IE5BQ0ssIFJUWCwgRkVDLCBSRUQsIG9yIENvbmdlc3Rpb24g Q29udHJvbCAoUkVNQiwgR29vZ2xlLWNjLCBCQlIsIE5BREEpLCBhcyBJRVRGIG1lbWJlcnMgSSdt IHN1cmUgeW91IHJlIGFsbCBhd2FyZSBvZiBSRkMzNTUwIGFuZCBhbGwgaXRzIGRlcml2YXRpdmVz LiBNYW55IGF1dGhvcnMgb2YgdGhvc2UgUkZDcyBhcmUgcGFydCBvZiB0aGlzIGdyb3VwLg0KDQpN YXliZSBtb3JlIG92ZXJsb29rZWQgaXMgdGhlIG1vc3QgcmVjZW50IERyYWZ0IGZvciBlbmQtdG8t ZW5kIGVuY3J5cHRpb24gb24gdG9wIG9mIHdlYnJ0YyBjby1hdXRob3JlZCBieSBnb29nbGU6DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb21hcmEtc2ZyYW1lLTAwDQoNCkknbSBu b3Qgc2F5aW5nIHRoYXQgU1JUIGlzIHdvcnNlLCBvciBiZXR0ZXIgdGhhbiBXZWJSVEMuLiBJJ20g anVzdCBzYXlpbmcsIHRoaXMgY29tcGFyaXNvbiBpcyBub3QgZWdyZWdpb3VzbHkgaW5jb3JyZWN0 LCBhbmQgSSdtIGEgbGl0dGxlIGJpdCBzdXJwcmlzZWQgdGhhdCB3ZSBhcmUgZGlzY3Vzc2luZyBt YXJrZXRpbmcgYmxvZ3MgdGhhdCBnbyBpbiB0aGUgZmFjZSBvZiBzbyBtYW55IElFVEYgc3BlY3Mu DQoNCklmIGFueWJvZHkgaXMgaW50ZXJlc3RlZCBpbiBnb2luZyBkZWVwIGludG8gYSByZWFsICB0 aG9yb3VnaCBjb21wYXJpc29uIGJldHdlZW4gYWxsIHRob3NlIHByb3RvY29scywgd2h5IG5vdCBk b2luZyBpdCBkdXJpbmcgdGhlIElFVEYgaGFja2F0aG9uIGluIEp1bHksIG9yIGluIG9jdG9iZXIg KGhvcGVmdWxseSBpbiBCS0spIGp1c3QgbGlrZSB3ZSBkaWQgZ3JvdXAgY28tdGVzdGluZyB3aXRo IElFVEYncyBBVlRDT1JFL0FWRVhUL1FVSUMvUlRDV0VCL1JNQ0FUIGR1cmluZyB0aGUgcHJldmlv dXMgSUVURiBoYWNrYXRob25zPw0KDQpSZWdhcmRzLA0KDQoNCg0KT24gU2F0LCBKdW4gMTMsIDIw MjAgYXQgNjo1OCBQTSBMZXNsaWUgRGFpZ2xlIDxsZGFpZ2xlQHRoaW5raW5nY2F0LmNvbTxtYWls dG86bGRhaWdsZUB0aGlua2luZ2NhdC5jb20+PiB3cm90ZToNCg0KSSB0aG91Z2h0IHRoaXMgd2Fz IGEgcHJldHR5IGludGVyZXN0aW5nIGFuYWx5c2lzOg0KDQpMb3cgYnJvYWRjYXN0IGxhdGVuY3kg YW5kIHByb3RvY29scyBmb3IgaW1wbGVtZW50YXRpb24gdGhlcmVvZjoNCmh0dHBzOi8vd3d3LmVs ZWNhcmQuY29tL3BhZ2UvbG93X2Jyb2FkY2FzdF9sYXRlbmN5X2FuZF9wcm90b2NvbHNfZm9yX2lt cGxlbWVudGF0aW9uX3RoZXJlb2YNCg0KUGFydGljdWxhcmx5IHRlbGxpbmcgaXMgdGhlIGNoYXJ0 IGF0IHRoZSBlbmQ6IFdlYlJUQyBhbmQgU1JUIGRvbuKAmXQgbG9vayB2ZXJ5IHNpbWlsYXIsIGlu IHRoaXMgcGFydGljdWxhciByZWdhcmQuDQoNCkxlc2xpZS4NCg0KLS0NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KTGVzbGllIERhaWdsZQ0KUHJpbmNpcGFsLCBUaGlua2lu Z0NhdCBFbnRlcnByaXNlcw0KDQpsZGFpZ2xlQHRoaW5raW5nY2F0LmNvbTxtYWlsdG86bGRhaWds ZUB0aGlua2luZ2NhdC5jb20+DQotLQ0KTW9wcyBtYWlsaW5nIGxpc3QNCk1vcHNAaWV0Zi5vcmc8 bWFpbHRvOk1vcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21vcHMNCg0KDQotLQ0KQWxleC4gR291YWlsbGFyZCwgUGhELCBQaEQsIE1CQQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpQcmVzaWRlbnQgLSBDb1NNbyBTb2Z0d2FyZSBDb25zdWx0 aW5nLCBTaW5nYXBvcmUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0Kc2cubGlua2VkaW4u Y29tL2Fnb3VhaWxsYXJkPGh0dHA6Ly9zZy5saW5rZWRpbi5jb20vYWdvdWFpbGxhcmQ+DQoNCiAg Kg0KDQoNCi0tDQpNb3BzIG1haWxpbmcgbGlzdA0KTW9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tb3BzDQo= --_000_17635DFDB5364B228A5D314BCBEFF19Cnbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IGRpcj0ibHRyIj5ZZXMsIGl04oCZcyBhIGJpdCBtYXJrZXRpbmcsIGJ1dCBpdOKAmXMgYWxz byBvbmUgb2YgdGhlIGZldyB3cml0ZSB1cHMgdGhhdCBhdHRlbXB0cyB0byBwdXQgdGhlIHBvcHVs YXIgbWVkaWEgdHJhbnNwb3J0cyBzaWRlIGJ5IHNpZGUgZm9yIHBlb3BsZSB0byB1bmRlcnN0YW5k IHRoZWlyIHN0cmVuZ3RocyBhbmQgYWJpbGl0aWVzLiAmbmJzcDsgVGhlIG1hcmtldGluZyBibG9n cyBhbHNvIGdpdmUgdXMsIHRoZSBJRVRGLCBpbnNpZ2h0IGludG8NCiBob3cgdGhlIG91dHNpZGUg d29ybGQgb2YgYWRvcHRlcnMgYW5kIHNlbGxlcnMgb2Ygb3VyIHdvcmsgc2VlIHRoaW5ncy48L2Rp dj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4gc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij5JIHJl YWxseSB3aXNoIHRoYXQgYWxsIHdlYiBkb2N1bWVudHMgYW5kIHBhZ2VzIGNvbnRhaW5lZCBhIHBv c3RpbmcgZGF0ZS4gJm5ic3A7IFRoaXMgb25lIGRvZXNu4oCZdCBnYXZlIGl0IGEgZGF0ZS4gJm5i c3A7SG93ZXZlciwgdGhlJm5ic3A7PC9zcGFuPnBhZ2UgbXVzdCBiZSBmcm9tIGF0IGxlYXN0IG1p ZCAyMDE5IGFzIGl0IG1lbnRpb25zDQogdGhpbmdzIHRoYXQgd2VyZSByZWxlYXNlZCB0aGVuLjwv ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5JIGxpa2Ug eW91ciB3cml0ZSB1cCBvZiB0aGUgV2ViUlRDIGluYWNjdXJhY2llcy4gJm5ic3A7SXQgd291bGQg YmUgZ3JlYXQgaWYgYW55IFNSVCBmb2xrcyBvbiB0aGlzIGxpc3QgY291bGQgZG8gc29tZXRoaW5n IHNpbWlsYXIsICZuYnNwO3RvIHRvIG1lbnRpb24gdGhvc2Ugd29ya2luZyB3aXRoIENNQUYgYW5k IExMIEhMUy4gJm5ic3A7VGhlcmUgYSBsb3Qgb2YgYWRvcHRlcnMgb3V0IHRoZXJlIHdobyBhcmUg d29ya2luZyB0aHJvdWdoIHdoYXQgcHJvdG9jb2wNCiBiZXN0IGZpdHMgdGhlaXIgcGFydGljdWxh ciBuZWVkcyAtIHdlYlJUQz8gJm5ic3A7IFNSVD8gJm5ic3A7U29tZXRoaW5nIHRoYXQgYnJpZ2h0 IHN1bW1lciBpbnRlcm4gd3JvdGUgd2hpbGUgc2hlIHdhcyBoZXJlIGxhc3Qgc3VtbWVyPyZuYnNw OzwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJz cDtDYXB0dXJpbmcgc29tZXRoaW5nIGxpa2UgdGhpcywgYW5kIGV2ZW4gYmV0dGVyIHNvbWUgc29y dCBvZiBiYWtlIG9mZiBhcyB5b3Ugc3VnZ2VzdCB3b3VsZCBiZSB2YWx1YWJsZSB0byBhIGxvdCBv ZiBwZW9wbGUuICZuYnNwO1Rob3VnaCBpdCBtYXkgaGF2ZSB0byB3YWl0IHRvIGdldCBjcml0aWNh bCBtYXNzIG9mIHBhcnRpY2lwYW50cyB1bnRpbCBuZXh0IHllYXIuPC9kaXY+DQo8ZGl2IGRpcj0i bHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPkdsZW5uJm5ic3A7PC9kaXY+DQo8ZGl2 IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+T24gSnVuIDEzLCAyMDIwLCBhdCAzOjM0IFBNLCBBbGV4YW5kcmUgR09VQUlMTEFS RCAmbHQ7YWdvdWFpbGxhcmRAZ21haWwuY29tJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+ 77u/DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8 ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXY+VGhlcmUgYXJlIG11bHRpcGxlIGluYWNjdXJhdGUgc3RhdGVtZW50cyBp biB0aGUgbGlua2VkIGRvY3VtZW50cy4gTW9zdCBvZiB0aGVtIHRoYXQgaGF2ZSBiZWVuIGNhcnJp ZWQgYXJvdW5kIGZvciBtYW55IHllYXJzIGJ5IG90aGVyIFNSVCB2ZW5kb3JzIGxpa2UgV293emEg YW5kIGFscmVhZHkgY2FsbGVkIG91dCAoPGEgaHJlZj0iaHR0cDovL3dlYnJ0Y2J5ZHJhbGV4LmNv bS9pbmRleC5waHAvMjAxOS8wNS8xOC93b3d6YXMtbWFya2V0aW5nLWF0LXdvcmstYWdhaW4td2Vi cnRjLyI+aGVyZTwvYT4NCiBmb3IgZXhhbXBsZSkuPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5JJ20ganVzdCBnb2luZyB0byBwb2ludCZuYnNwO3RvIHRocmVlIG9mIHRoZSBt b3N0IGVncmVnaW91cyZuYnNwOyhyZWFkICZxdW90O3ZlcmlmaWFibHkgd3JvbmcmcXVvdDspIHN0 YXRlbWVudHMsIHRoYXQgYnkgdGhlbXNlbHZlcyB1bmRlcm1pbmUgdGhlIGNyZWRpYmlsaXR5IG9m IHRoZSBlbnRpcmUgZG9jdW1lbnQuPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4N Ci0gJnF1b3Q7TWF4aW11bSBzdXBwb3J0ZWQgcmVzb2x1dGlvbjogNzIwcCwgMzAgZnJhbWVzIHBl ciBzZWNvbmQgd2l0aCBhIGJpdCByYXRlIG9mIHVwIHRvIDIgTWJwcy4mcXVvdDs8YnI+DQotIFRo ZXJlIGlzIG5vIGxpbWl0IHRvIHRoZSBzcGF0aWFsIGFuZCB0ZW1wb3JhbCByZXNvbHV0aW9uIGlu IHdlYnJ0Yy9ydGN3ZWIgcHJvdG9jb2wuPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5TdGFkaWEgZm9y IGV4YW1wbGUgc2VuZCB1cCB0byA0S0AzMGZwcy48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4N CjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+JnF1b3Q7V2ViUlRDIGlzIGluZmVyaW9yIHRvIGl0cyBj b2xsZWFndWVzIGluIHRlcm1zIG9mIHRoZSBjb2RpbmcgcXVhbGl0eSBhbmQgbWF4aW11bSBhbW91 bnQgb2YgdHJhbnNtaXR0ZWQgZGF0YS48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPi0gVGhlcmUgaXMg bm8gbGltaXQgdG8gdGhlIGJhbmR3aWR0aCB1c2VkIGluIHRoZSB3ZWJydGMvcnRjd2ViIHByb3Rv Y29sLjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+LSBUaGVyZSBpcyBhIGxpbWl0IG9mIDJNYnBzIHBl ciBwZWVyIGNvbm5lY3Rpb24gb24gdGhlIHNlbmRpbmctc2lkZQ0KPGI+b25seSBpbiB0aGUgZ29v Z2xlIGNocm9tZSBpbXBsZW1lbnRhdGlvbjwvYj4sIG9ubHkgYnkgZGVmYXVsdCAod2ViIGFwcGxp Y2F0aW9uIGNhbiBsaWZ0IHRoaXMgbGltaXQpLCBhbmQgb25seSBmb3Igd2ViY2FtcyBkZXZpY2Vz IChzY3JlZW5zaGFyaW5nIGhhcyBubyBiYW5kd2lkdGggbGltaXQpLiBUaGlzIGlzIGEgY2hyb21l IGltcGxlbWVudGF0aW9uIGRldGFpbCwgYW5kIG5vdCBhIHByb3RvY29sIGxpbWl0LjwvZGl2Pg0K PGRpdj4tV2hpbGUgVlA4IGFuZCBIMjY0IGFyZSBib3RoIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQg KDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcnRjd2ViL2p1 VnNaS3AtQW1ScFlMQ2d5LXV3YXJ0dU5yWS8iPm9yaWdpbmFsIElFVEYgZGlzY3Vzc2lvbjwvYT4p IGFueWJvZHkgY2FuIGFkZCBhbnkgY29kZWMgdG8gd2VicnRjIGFzIGxvbmcgYXMgYW4gUlRQIHBh eWxvYWQgc3BlY2lmaWNhdGlvbiBleGlzdHMuPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4tLSBHb29n bGUgY2hyb21lLCBhbmQgZmlyZWZveCwgYm90aCBzdXBwb3J0cyByZWFsLXRpbWUgVlA5IG1vZGUg MiAoNDo0OjQsIDEwIGJpdHMsIEhEUik8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxhIGhyZWY9Imh0 dHBzOi8vc291cmNlLmNocm9taXVtLm9yZy9jaHJvbWl1bS9jaHJvbWl1bS9zcmMvJiM0MzsvbWFz dGVyOnRoaXJkX3BhcnR5L3dlYnJ0Yy9tb2R1bGVzL3ZpZGVvX2NvZGluZy9jb2RlY3MvdnA5L3Zw OV9pbXBsLmNjO2w9OTg1Ij5odHRwczovL3NvdXJjZS5jaHJvbWl1bS5vcmcvY2hyb21pdW0vY2hy b21pdW0vc3JjLyYjNDM7L21hc3Rlcjp0aGlyZF9wYXJ0eS93ZWJydGMvbW9kdWxlcy92aWRlb19j b2RpbmcvY29kZWNzL3ZwOS92cDlfaW1wbC5jYztsPTk4NTwvYT48YnI+DQo8L2Rpdj4NCjxkaXYg ZGlyPSJsdHIiPi0tIENocm9tZSBoYXMgYSByZWFsLXRpbWUgQVYxIGltcGxlbWVudGF0aW9uIGlu IHdlYnJ0Yywgd2hpY2ggZ29lcyB1cCB0byBoaWdoIHByb2ZpbGUgKDQ6NDo0LCA4fjEwYml0cywg SERSKS48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxhIGhyZWY9Imh0dHBzOi8vc291cmNlLmNocm9t aXVtLm9yZy9jaHJvbWl1bS9jaHJvbWl1bS9zcmMvJiM0MzsvbWFzdGVyOnRoaXJkX3BhcnR5L3dl YnJ0Yy9tb2R1bGVzL3ZpZGVvX2NvZGluZy9jb2RlY3MvYXYxLyI+aHR0cHM6Ly9zb3VyY2UuY2hy b21pdW0ub3JnL2Nocm9taXVtL2Nocm9taXVtL3NyYy8mIzQzOy9tYXN0ZXI6dGhpcmRfcGFydHkv d2VicnRjL21vZHVsZXMvdmlkZW9fY29kaW5nL2NvZGVjcy9hdjEvPC9hPjwvZGl2Pg0KPGRpdiBk aXI9Imx0ciI+SW4gdGVybXMgb2YgcXVhbGl0eSwgb25seSBjb2RlY3MgYXQgaGlnaCBwcm9maWxl IChpLmUuIDEyYml0cykgY2FuIGRvIGJldHRlciwgYW5kIG5vbmUgb2YgdGhvc2UgaGF2ZSBhICZx dW90O3JlYWwtdGltZSZxdW90OyB2ZXJzaW9uIHRvZGF5LjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ SW4gdGVybXMgb2YgY29kaW5nIGVmZmljaWVuY3ksIEFWMSBpcyBzdGlsbCB0aGUgYmVzdCBjb2Rl YyBhdmFpbGFibGUgaW4gcHJvZHVjdGlvbi48YnI+DQo8YnI+DQomcXVvdDtXZWJSVEMgaXMgbm90 IGF2YWlsYWJsZSBpbiBTYWZhcmkgYW5kIHBhcnRpYWxseSB1bmF2YWlsYWJsZSBpbiBCb3dzZXIg YW5kIEVkZ2UuJnF1b3Q7PC9kaXY+DQo8ZGl2Pi0gd2VicnRjIGlzIGZ1bGx5IGF2YWlsYWJsZSBp biBFZGdlLCBhbmQgU2FmYXJpLjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL2Nhbml1c2Uu Y29tLyNzZWFyY2g9d2VicnRjIj5odHRwczovL2Nhbml1c2UuY29tLyNzZWFyY2g9d2VicnRjPC9h Pjxicj4NCjwvZGl2Pg0KPGRpdj5vZmZpY2lhbCBkYWlseSBXM0MgcmVzdWx0czombmJzcDs8YSBo cmVmPSJodHRwczovL3dwdC5meWkvcmVzdWx0cy8/bGFiZWw9bWFzdGVyJmFtcDtsYWJlbD1leHBl cmltZW50YWwmYW1wO2FsaWduZWQmYW1wO3E9d2VicnRjIj5odHRwczovL3dwdC5meWkvcmVzdWx0 cy8/bGFiZWw9bWFzdGVyJmFtcDtsYWJlbD1leHBlcmltZW50YWwmYW1wO2FsaWduZWQmYW1wO3E9 d2VicnRjPC9hPjwvZGl2Pg0KPGRpdj4tIFNhZmFyaSBoYXMgYWRkZWQgSC4yNjUgc3VwcG9ydCBp biBhZGRpdGlvbiB0byB0aGUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBWUDggYW5kIEguLjI2NCBp biB0aGUgbGF0ZXN0IHNhZmFyaSB0ZWNoIHByZXZpZXcuPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48 YnI+DQo8L2Rpdj4NCjxkaXY+SSdtIG5vdCBnb2luZyBpbnRvIHRoZSBEaXNjdXNzaW9uIGFib3V0 IHdlYnJ0YydzIHVuZGVybHlpbmcgUlRDL1JUQ1AgcHJvdG9jb2wgYW5kIGNvcnJlc3BvbmRpbmcg ZXh0ZW5zaW9uOiBOQUNLLCBSVFgsIEZFQywgUkVELCBvciBDb25nZXN0aW9uIENvbnRyb2wgKFJF TUIsIEdvb2dsZS1jYywgQkJSLCBOQURBKSwgYXMgSUVURiBtZW1iZXJzIEknbSBzdXJlIHlvdSBy ZSBhbGwgYXdhcmUgb2YgUkZDMzU1MCBhbmQgYWxsIGl0cyBkZXJpdmF0aXZlcy4NCiBNYW55IGF1 dGhvcnMgb2YgdGhvc2UgUkZDcyBhcmUgcGFydCBvZiB0aGlzIGdyb3VwLjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+TWF5YmUgbW9yZSBvdmVybG9va2VkIGlzIHRoZSBtb3N0IHJlY2Vu dCBEcmFmdCBmb3IgZW5kLXRvLWVuZCBlbmNyeXB0aW9uIG9uIHRvcCBvZiB3ZWJydGMgY28tYXV0 aG9yZWQgYnkgZ29vZ2xlOjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtb21hcmEtc2ZyYW1lLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtb21hcmEtc2ZyYW1lLTAwPC9hPjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SSdtIG5vdCBzYXlpbmcgdGhhdCBTUlQgaXMgd29yc2UsIG9yIGJldHRlciB0aGFu IFdlYlJUQy4uIEknbSBqdXN0IHNheWluZywgdGhpcyBjb21wYXJpc29uIGlzIG5vdCBlZ3JlZ2lv dXNseSBpbmNvcnJlY3QsIGFuZCBJJ20gYSBsaXR0bGUgYml0IHN1cnByaXNlZCB0aGF0IHdlIGFy ZSBkaXNjdXNzaW5nIG1hcmtldGluZyBibG9ncyB0aGF0IGdvIGluIHRoZSBmYWNlIG9mIHNvIG1h bnkgSUVURiBzcGVjcy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklmIGFu eWJvZHkgaXMgaW50ZXJlc3RlZCBpbiBnb2luZyBkZWVwIGludG8gYSByZWFsICZuYnNwO3Rob3Jv dWdoIGNvbXBhcmlzb24gYmV0d2VlbiBhbGwgdGhvc2UgcHJvdG9jb2xzLCB3aHkgbm90IGRvaW5n IGl0IGR1cmluZyB0aGUgSUVURiBoYWNrYXRob24gaW4gSnVseSwgb3IgaW4gb2N0b2JlciAoaG9w ZWZ1bGx5IGluIEJLSykganVzdCBsaWtlIHdlIGRpZCBncm91cCBjby10ZXN0aW5nIHdpdGggSUVU RidzIEFWVENPUkUvQVZFWFQvUVVJQy9SVENXRUIvUk1DQVQNCiBkdXJpbmcgdGhlIHByZXZpb3Vz IElFVEYgaGFja2F0aG9ucz88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMs PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iZ21haWxfYXR0ciI+T24gU2F0LCBKdW4gMTMsIDIwMjAgYXQgNjo1OCBQTSBMZXNsaWUgRGFp Z2xlICZsdDs8YSBocmVmPSJtYWlsdG86bGRhaWdsZUB0aGlua2luZ2NhdC5jb20iPmxkYWlnbGVA dGhpbmtpbmdjYXQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVy LWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO2JvcmRlci1sZWZ0LWNvbG9y OnJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8dT48L3U+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6c2Fucy1zZXJpZiI+DQo8ZGl2IHN0eWxlPSJ3aGl0ZS1zcGFj ZTpub3JtYWwiPg0KPHAgZGlyPSJhdXRvIj5JIHRob3VnaHQgdGhpcyB3YXMgYSBwcmV0dHkgaW50 ZXJlc3RpbmcgYW5hbHlzaXM6PC9wPg0KPHAgZGlyPSJhdXRvIj5Mb3cgYnJvYWRjYXN0IGxhdGVu Y3kgYW5kIHByb3RvY29scyBmb3IgaW1wbGVtZW50YXRpb24gdGhlcmVvZjo8YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5lbGVjYXJkLmNvbS9wYWdlL2xvd19icm9hZGNhc3RfbGF0ZW5jeV9hbmRf cHJvdG9jb2xzX2Zvcl9pbXBsZW1lbnRhdGlvbl90aGVyZW9mIiBzdHlsZT0iY29sb3I6cmdiKDU3 LDEzMSwxOTYpIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuZWxlY2FyZC5jb20vcGFnZS9s b3dfYnJvYWRjYXN0X2xhdGVuY3lfYW5kX3Byb3RvY29sc19mb3JfaW1wbGVtZW50YXRpb25fdGhl cmVvZjwvYT48L3A+DQo8cCBkaXI9ImF1dG8iPlBhcnRpY3VsYXJseSB0ZWxsaW5nIGlzIHRoZSBj aGFydCBhdCB0aGUgZW5kOiBXZWJSVEMgYW5kIFNSVCBkb27igJl0IGxvb2sgdmVyeSBzaW1pbGFy LCBpbiB0aGlzIHBhcnRpY3VsYXIgcmVnYXJkLjwvcD4NCjxwIGRpcj0iYXV0byI+TGVzbGllLjwv cD4NCjxwIGRpcj0iYXV0byI+LS0gPC9wPg0KPGhyIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJn Yig1MSw1MSw1MSk7YmFja2dyb3VuZC1pbWFnZTpsaW5lYXItZ3JhZGllbnQodG8gcmlnaHQscmdi KDIwNCwyMDQsMjA0KSxyZ2IoNTEsNTEsNTEpLHJnYigyMDQsMjA0LDIwNCkpO2JvcmRlcjowcHg7 aGVpZ2h0OjFweDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5k LXJlcGVhdDppbml0aWFsIGluaXRpYWwiIGhlaWdodD0iMSI+DQo8cCBkaXI9ImF1dG8iPkxlc2xp ZSBEYWlnbGU8YnI+DQpQcmluY2lwYWwsIFRoaW5raW5nQ2F0IEVudGVycHJpc2VzPC9wPg0KPGgy IHN0eWxlPSJmb250LXNpemU6MS4yZW0iPjxhIGhyZWY9Im1haWx0bzpsZGFpZ2xlQHRoaW5raW5n Y2F0LmNvbSIgc3R5bGU9ImNvbG9yOnJnYig1NywxMzEsMTk2KSIgdGFyZ2V0PSJfYmxhbmsiPmxk YWlnbGVAdGhpbmtpbmdjYXQuY29tPC9hPjwvaDI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQot LSA8YnI+DQpNb3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpNb3BzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+TW9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vcHMiIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9w czwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGVhcj0iYWxsIj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQotLSA8YnI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfc2lnbmF0 dXJlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9 Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj5BbGV4LiBHb3VhaWxsYXJkLCBQaEQsIFBoRCwgTUJBDQo8 ZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRpdj5QcmVzaWRlbnQgLSBD b1NNbyBTb2Z0d2FyZSBDb25zdWx0aW5nLCBTaW5nYXBvcmU8L2Rpdj4NCjxkaXY+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHA6Ly9zZy5saW5rZWRp bi5jb20vYWdvdWFpbGxhcmQiIHRhcmdldD0iX2JsYW5rIj5zZy5saW5rZWRpbi5jb20vYWdvdWFp bGxhcmQ8L2E+PC9kaXY+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW46MHB4O3BhZGRpbmc6MHB4 IDBweCA4cHg7Ym9yZGVyOjBweDtvdXRsaW5lOjBweDtmb250LXNpemU6MTJweDtmb250LWZhbWls eTpIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTtsaXN0 LXN0eWxlOm5vbmU7bGluZS1oZWlnaHQ6MTdweDtkaXNwbGF5OnRhYmxlLWNlbGw7d2lkdGg6NTA0 cHg7Y29sb3I6cmdiKDUxLDUxLDUxKSI+DQo8bGkgc3R5bGU9Im1hcmdpbjowcHg7cGFkZGluZzo4 cHggMTJweCAycHggMHB4O2JvcmRlcjowcHg7b3V0bGluZTowcHg7Zm9udC1zdHlsZTppbmhlcml0 O2ZvbnQtc2l6ZToxMXB4O2ZvbnQtZmFtaWx5OmluaGVyaXQ7dmVydGljYWwtYWxpZ246YmFzZWxp bmU7Zm9udC12YXJpYW50LWxpZ2F0dXJlczppbmhlcml0O2ZvbnQtdmFyaWFudC1jYXBzOmluaGVy aXQ7Zm9udC12YXJpYW50LW51bWVyaWM6aW5oZXJpdDtmb250LXZhcmlhbnQtYWx0ZXJuYXRlczpp bmhlcml0O2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOmluaGVyaXQ7bGluZS1oZWlnaHQ6MS4yZW0i Pg0KPGRsIHN0eWxlPSJtYXJnaW46MHB4O3BhZGRpbmc6MHB4O2JvcmRlcjowcHg7b3V0bGluZTow cHg7Zm9udC1zdHlsZTppbmhlcml0O2ZvbnQtZmFtaWx5OmluaGVyaXQ7dmVydGljYWwtYWxpZ246 YmFzZWxpbmU7Zm9udC12YXJpYW50LWxpZ2F0dXJlczppbmhlcml0O2ZvbnQtdmFyaWFudC1jYXBz OmluaGVyaXQ7Zm9udC12YXJpYW50LW51bWVyaWM6aW5oZXJpdDtmb250LXZhcmlhbnQtYWx0ZXJu YXRlczppbmhlcml0O2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOmluaGVyaXQ7bGluZS1oZWlnaHQ6 aW5oZXJpdDt3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8YnI+DQo8L2RsPg0KPC9saT48L3VsPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 c3Bhbj4tLSA8L3NwYW4+PGJyPg0KPHNwYW4+TW9wcyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0K PHNwYW4+TW9wc0BpZXRmLm9yZzwvc3Bhbj48YnI+DQo8c3Bhbj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21vcHM8L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_17635DFDB5364B228A5D314BCBEFF19Cnbcunicom_-- From nobody Sat Jun 13 16:27:56 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DB73A07D8 for ; Sat, 13 Jun 2020 16:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGF6oCxyp7LJ for ; Sat, 13 Jun 2020 16:27:52 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73973A07C5 for ; Sat, 13 Jun 2020 16:27:52 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id a13so12127870ilh.3 for ; Sat, 13 Jun 2020 16:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mxNYGu4+sA+A+9kaM0goPi9HL6IQZxittahDQJh/Crc=; b=WpVWy49jbp8DH+Zw8PLWLN78U3spgwpCn8bszdLP7RSp+E1UcF83xsASM0qadp1u0E tEJFpTHkUu5NFrPCqbzXjGEvD5M108MP1Cxxk5w+OUgfUFTURbJJhfOaRsGHt3acXW6K AlmhHJOATrClFtNE4//2KpAWddIoeCNkI7syVOVWvwyiAn0RX2tSdXmNW20p1L3HIMA7 Ixf5w37oLuVq5I2ObgwZoaD7GfE64sq9IengGTqfJ+dl0GE7jNVM+ptZ2rH9XrcGJWYk DWuWXxXOS0OC0ebR811Mhx1xR+SGIpDFqfmmm3dZnQ/SnyOlnDtvE4INbGtl38vjjSbV NrCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mxNYGu4+sA+A+9kaM0goPi9HL6IQZxittahDQJh/Crc=; b=mIxavs4bt6s2PzBdgIDad1e5hrGiOUbIXhkG2miT5KjirQOWt+YmCGiZ6YcXEzz1+l QcgJtCIxaSBm+2VWU62QGyjG1TWj0nZcNAumPYrKqVJ8xcHmRf/8WvQEg26znmryzw/x Zfv0ohxNqcPAdSqQqEGh9iAszF6KVszZWEZx0iBgf6Ry/DgdwlueQffEQHO2QfYGRZ7w 6nODwW8mmTl9jzXJ0bHj2qaGcrC0MM94+S9b0vvuWqCtL+avIgUVKqlIWbq2yeAhty53 LJiDgaU7gRtJ5NtINR2CC5yQw8/NsjNq6faXMuCEK0LMfki5OW3MTJiObPX9dFpDqwO1 gMTg== X-Gm-Message-State: AOAM533BpvRxF75bfQ0Kud1ZSPTaFD51OPY3R2DwdtxDAtiO6zMV9gov t6z4uFnUsXVDbxAkydO6Esd3gOFElteCwrRxBck= X-Google-Smtp-Source: ABdhPJxsxRPt+cVTPJeIS+guHKGjKU1Jyhu7ExluXy0RBA98Rrz1YADLyCy1GX+miLmLZEDwpFe6GmTGChXegobqmRc= X-Received: by 2002:a92:d151:: with SMTP id t17mr20929974ilg.197.1592090871927; Sat, 13 Jun 2020 16:27:51 -0700 (PDT) MIME-Version: 1.0 References: <17635DFD-B536-4B22-8A5D-314BCBEFF19C@nbcuni.com> In-Reply-To: <17635DFD-B536-4B22-8A5D-314BCBEFF19C@nbcuni.com> From: Alexandre GOUAILLARD Date: Sun, 14 Jun 2020 01:27:40 +0200 Message-ID: To: "Deen, Glenn (NBCUniversal)" Cc: Leslie Daigle , "mops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000df186305a7ff8ad7" Archived-At: Subject: Re: [Mops] Low latency protocol comparision X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 23:27:55 -0000 --000000000000df186305a7ff8ad7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Deen, agreed. I gave it a try though a couple of years back. Let me know if that would go in the right direction and I can update it with everything I learned in the mean time, and taking into account the updates to the different protocols (e.g. new HLS informational draft by pantos): http://webrtcbydralex.com/index.php/2018/05/15/streaming-protocols-and-ultr= a-low-latency-including-webrtc/ @Leslie, I volunteer every year, every hackathon :-) However, I am more knowledgeable about webrtc than other protocols, so in that regard, I am biased. I think to be fair each protocol should have a reasonable representative/champion that at least validates that the testing protocol chosen is adequate, and garantees the accuracy and the fairness of the result. For webrtc, it was problematic as well, as each browser vendor did not want someone else to benchmark their implementation, so we ended up with one representant of each browser vendor at 104 I believe (pragues), to validate its result, and did it again in montreal: https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon/webrtc if we manage to get the same setting, I think it could be very successful in getting fair and accurate results. I think we could handle the webrtc testing (as in writing open source tests and providing results that would be deterministic and independently verifiable by any and all). - Maybe Veriskope, which is trying to push an RTMP 2.0, could be interested in joining for RTMP. - Magnus W for RTSP 2.0 ? - Then we would need one volunteer for SRT, - and another one for QUIC (maybe martin thompson can point us in the right direction). QUIC is always the biggest table so it should not be too difficult. - Jonathan Lennox, chairman of AVTCORE is always around and could help, especially on the congestion control, Error concealment, and bandwidth adaptation part - We could motivate EKR to comment on the security aspects. - I'm not sure if we want to asses IPv6 and NAT traversal readiness (ICE) What do you think? Regards, Dr. Alex On Sun, Jun 14, 2020 at 1:05 AM Deen, Glenn (NBCUniversal) < Glenn.Deen@nbcuni.com> wrote: > Yes, it=E2=80=99s a bit marketing, but it=E2=80=99s also one of the few w= rite ups that > attempts to put the popular media transports side by side for people to > understand their strengths and abilities. The marketing blogs also give > us, the IETF, insight into how the outside world of adopters and sellers = of > our work see things. > > I really wish that all web documents and pages contained a posting date. > This one doesn=E2=80=99t gave it a date. However, the page must be from = at least > mid 2019 as it mentions things that were released then. > > I like your write up of the WebRTC inaccuracies. It would be great if an= y > SRT folks on this list could do something similar, to to mention those > working with CMAF and LL HLS. There a lot of adopters out there who are > working through what protocol best fits their particular needs - webRTC? > SRT? Something that bright summer intern wrote while she was here last > summer? > > Capturing something like this, and even better some sort of bake off as > you suggest would be valuable to a lot of people. Though it may have to > wait to get critical mass of participants until next year. > > Glenn > > On Jun 13, 2020, at 3:34 PM, Alexandre GOUAILLARD > wrote: > > =EF=BB=BF > There are multiple inaccurate statements in the linked documents. Most of > them that have been carried around for many years by other SRT vendors li= ke > Wowza and already called out (here > > for example). > > I'm just going to point to three of the most egregious (read "verifiably > wrong") statements, that by themselves undermine the credibility of the > entire document. > > - "Maximum supported resolution: 720p, 30 frames per second with a bit > rate of up to 2 Mbps." > - There is no limit to the spatial and temporal resolution in > webrtc/rtcweb protocol. > Stadia for example send up to 4K@30fps. > > "WebRTC is inferior to its colleagues in terms of the coding quality and > maximum amount of transmitted data. > - There is no limit to the bandwidth used in the webrtc/rtcweb protocol. > - There is a limit of 2Mbps per peer connection on the sending-side *only > in the google chrome implementation*, only by default (web application > can lift this limit), and only for webcams devices (screensharing has no > bandwidth limit). This is a chrome implementation detail, and not a > protocol limit. > -While VP8 and H264 are both mandatory to implement (original IETF > discussion > ) > anybody can add any codec to webrtc as long as an RTP payload specificati= on > exists. > -- Google chrome, and firefox, both supports real-time VP9 mode 2 (4:4:4, > 10 bits, HDR) > > https://source.chromium.org/chromium/chromium/src/+/master:third_party/we= brtc/modules/video_coding/codecs/vp9/vp9_impl.cc;l=3D985 > -- Chrome has a real-time AV1 implementation in webrtc, which goes up to > high profile (4:4:4, 8~10bits, HDR). > > https://source.chromium.org/chromium/chromium/src/+/master:third_party/we= brtc/modules/video_coding/codecs/av1/ > In terms of quality, only codecs at high profile (i.e. 12bits) can do > better, and none of those have a "real-time" version today. > In terms of coding efficiency, AV1 is still the best codec available in > production. > > "WebRTC is not available in Safari and partially unavailable in Bowser an= d > Edge." > - webrtc is fully available in Edge, and Safari. > https://caniuse.com/#search=3Dwebrtc > official daily W3C results: > https://wpt.fyi/results/?label=3Dmaster&label=3Dexperimental&aligned&q=3D= webrtc > - Safari has added H.265 support in addition to the mandatory to implemen= t > VP8 and H..264 in the latest safari tech preview. > > I'm not going into the Discussion about webrtc's underlying RTC/RTCP > protocol and corresponding extension: NACK, RTX, FEC, RED, or Congestion > Control (REMB, Google-cc, BBR, NADA), as IETF members I'm sure you re all > aware of RFC3550 and all its derivatives. Many authors of those RFCs are > part of this group. > > Maybe more overlooked is the most recent Draft for end-to-end encryption > on top of webrtc co-authored by google: > https://tools.ietf.org/html/draft-omara-sframe-00 > > I'm not saying that SRT is worse, or better than WebRTC.. I'm just saying= , > this comparison is not egregiously incorrect, and I'm a little bit > surprised that we are discussing marketing blogs that go in the face of s= o > many IETF specs. > > If anybody is interested in going deep into a real thorough comparison > between all those protocols, why not doing it during the IETF hackathon i= n > July, or in october (hopefully in BKK) just like we did group co-testing > with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF > hackathons? > > Regards, > > > > On Sat, Jun 13, 2020 at 6:58 PM Leslie Daigle > wrote: > >> I thought this was a pretty interesting analysis: >> >> Low broadcast latency and protocols for implementation thereof: >> >> https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_imp= lementation_thereof >> >> Particularly telling is the chart at the end: WebRTC and SRT don=E2=80= =99t look >> very similar, in this particular regard. >> >> Leslie. >> >> -- >> ------------------------------ >> >> Leslie Daigle >> Principal, ThinkingCat Enterprises >> ldaigle@thinkingcat.com >> -- >> Mops mailing list >> Mops@ietf.org >> https://www.ietf.org/mailman/listinfo/mops >> > > > -- > Alex. Gouaillard, PhD, PhD, MBA > > -------------------------------------------------------------------------= ----------- > President - CoSMo Software Consulting, Singapore > > -------------------------------------------------------------------------= ----------- > sg.linkedin.com/agouaillard > > - > > -- > Mops mailing list > Mops@ietf.org > https://www.ietf.org/mailman/listinfo/mops > > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- President - CoSMo Software Consulting, Singapore ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --000000000000df186305a7ff8ad7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Deen, agreed.=C2=A0I ga= ve it a try though a couple of years back. Let me=C2=A0know if that would= =C2=A0go in the right direction=C2=A0and I can update it with everything I = learned in the mean time, and taking into account the updates to the differ= ent protocols (e.g. new HLS informational draft by pantos):

@Leslie, I volu= nteer every year, every hackathon :-)
However, I am more knowledg= eable about webrtc than other protocols,=C2=A0so in that regard, I am biase= d.
I think to be fair=C2=A0each protocol should have a reasonable= =C2=A0representative/champion that at least validates that the testing prot= ocol chosen is adequate, and garantees=C2=A0the accuracy and the fairness o= f the result.

For webrtc, it was problematic as we= ll, as each browser vendor did not want someone else to benchmark their=C2= =A0implementation, so we ended up with one representant=C2=A0of each browse= r vendor at 104 I believe=C2=A0(pragues), to validate its result, and did i= t again in montreal:
if we manage to get the same setti= ng, I think it could=C2=A0be very successful in=C2=A0getting=C2=A0fair and = accurate results.

I think we could handle the webr= tc testing (as in writing open source tests and providing results that woul= d be deterministic and independently=C2=A0verifiable=C2=A0by any and all).<= /div>
- Maybe Veriskope, which is trying to push an RTMP 2.0, could be = interested in joining=C2=A0for RTMP.
- Magnus W for RTSP 2.0 ?
- Then we would need one volunteer for SRT,
- and another= one for QUIC (maybe martin thompson can point us in the right direction). = QUIC is always the biggest table so it should not be too difficult.
<= div>- Jonathan Lennox, chairman of AVTCORE is always around and could help,= especially on the congestion control, Error concealment, and bandwidth ada= ptation part
- We could motivate EKR to comment on the security a= spects.
- I'm not sure if we want to asses IPv6 and NAT trave= rsal readiness (ICE)

What do you think?
=
Regards,=C2=A0

Dr. Alex
<= br>




=

On Sun, Jun 14, 2020 at 1:05 AM Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:
=
Yes, it=E2=80=99s a bit marketing, but it=E2=80=99s also o= ne of the few write ups that attempts to put the popular media transports s= ide by side for people to understand their strengths and abilities. =C2=A0 = The marketing blogs also give us, the IETF, insight into how the outside world of adopters and sellers of our work see things.

I really wish that all we= b documents and pages contained a posting date. =C2=A0 This one doesn=E2=80= =99t gave it a date.=C2=A0 However, the=C2=A0page must be from at le= ast mid 2019 as it mentions things that were released then.

I like your write up of the WebRTC inaccuracies.=C2=A0 It = would be great if any SRT folks on this list could do something similar, = =C2=A0to to mention those working with CMAF and LL HLS.=C2=A0 There a lot o= f adopters out there who are working through what protocol best fits their particular needs - webRTC? =C2=A0 SRT?=C2=A0 Something tha= t bright summer intern wrote while she was here last summer?=C2=A0

=C2=A0Capturing something like this, and even better some = sort of bake off as you suggest would be valuable to a lot of people.=C2=A0= Though it may have to wait to get critical mass of participants until next= year.

Glenn=C2=A0

On Jun 13, 2020, at 3:34 PM, Alexandre GOUAILLARD= <agouaillard= @gmail.com> wrote:

=EF=BB=BF
There are multiple inaccurate statements in the linked documents. Most= of them that have been carried around for many years by other SRT vendors = like Wowza and already called out (here for example).

I'm just going to point=C2=A0to three of the most egregious=C2=A0(= read "verifiably wrong") statements, that by themselves undermine= the credibility of the entire document.

- "Maximum supported resolution: 720p, 30 frames per second with a bit= rate of up to 2 Mbps."
- There is no limit to the spatial and temporal resolution in webrtc/rtcweb= protocol.
Stadia for example send up to 4K@30fps.

"WebRTC is inferior to its colleagues in terms of the= coding quality and maximum amount of transmitted data.
- There is no limit to the bandwidth used in the webrtc/rt= cweb protocol.
- There is a limit of 2Mbps per peer connection on the sen= ding-side only in the google chrome implementation, only by default (web appli= cation can lift this limit), and only for webcams devices (screensharing ha= s no bandwidth limit). This is a chrome implementation detail, and not a pr= otocol limit.
-While VP8 and H264 are both mandatory to implement (original IETF discussion) anybody can add any codec to webr= tc as long as an RTP payload specification exists.
-- Google chrome, and firefox, both supports real-time VP9= mode 2 (4:4:4, 10 bits, HDR)
-- Chrome has a real-time AV1 implementation in webrtc, wh= ich goes up to high profile (4:4:4, 8~10bits, HDR).
In terms of quality, only codecs at high profile (i.e. 12b= its) can do better, and none of those have a "real-time" version = today.
In terms of coding efficiency, AV1 is still the best codec= available in production.

"WebRTC is not available in Safari and partially unavailable in Bowser= and Edge."
- webrtc is fully available in Edge, and Safari.
- Safari has added H.265 support in addition to the mandatory to imple= ment VP8 and H..264 in the latest safari tech preview.

I'm not going into the Discussion about webrtc's underlying RT= C/RTCP protocol and corresponding extension: NACK, RTX, FEC, RED, or Conges= tion Control (REMB, Google-cc, BBR, NADA), as IETF members I'm sure you= re all aware of RFC3550 and all its derivatives. Many authors of those RFCs are part of this group.

Maybe more overlooked is the most recent Draft for end-to-end encrypti= on on top of webrtc co-authored by google:

I'm not saying that SRT is worse, or better than WebRTC.. I'm = just saying, this comparison is not egregiously incorrect, and I'm a li= ttle bit surprised that we are discussing marketing blogs that go in the fa= ce of so many IETF specs.=C2=A0

If anybody is interested in going deep into a real =C2=A0thorough comp= arison between all those protocols, why not doing it during the IETF hackat= hon in July, or in october (hopefully in BKK) just like we did group co-tes= ting with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF hackathons?

Regards,



On Sat, Jun 13, 2020 at 6:58 PM Lesli= e Daigle <l= daigle@thinkingcat.com> wrote:

I thought this was a pretty interesting analysis:

Low broadcast latency and protocols for implementation ther= eof:
https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_im= plementation_thereof

Particularly telling is the chart at the end: WebRTC and SR= T don=E2=80=99t look very similar, in this particular regard.

Leslie.

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com=

--
Mops mailing list
Mops@ietf.org
https://www.ietf.org/mailman/listinfo/mops


--
Alex. Gouaillard, PhD, PhD, MBA
----------------------------------------------------------------------= --------------
President - CoSMo Software Consulting, Singapore
----------------------------------------------------------------------= --------------

--
Mops mailing list
Mops@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/mops


--
Alex. Gouaillard, PhD, PhD, MBA
-------------= -----------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
---------= ---------------------------------------------------------------------------=

--000000000000df186305a7ff8ad7-- From nobody Sun Jun 14 13:05:26 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA093A11AF for ; Sun, 14 Jun 2020 13:05:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hai365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv3dT43x5EtB for ; Sun, 14 Jun 2020 13:05:22 -0700 (PDT) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660065.outbound.protection.outlook.com [40.107.66.65]) (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 749FA3A11AA for ; Sun, 14 Jun 2020 13:05:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LErbctvMlzNq7Qu6g2ijLGWpQ5Hx7rzxTphOhIA1FaNwRbOF1hOUOk91NZ4c1BpbS+AHQomrbTUtGDqKby5kCNna3+sdC3U/6ASOgxTKVz9EGfyaXVbSUrDOaUPl5SU+7Mc/LDL82KQX9Y9c39rVHN2Ee8MpfLX1MONbGCiHsvNJF4zK/j7JxNtCh8yFEQpt1kYVg/uTjWB8T041jBv6Eb3Q1yEy0dgp04Sdn3UE3kk9Lm1MBF4CxejJCF6aNqRVL7L6PnWZ7hcyQQKTJRMkuP3xted89Y/iQx9ALqw186YM63j4v7SFdjaaOfyuG3cSVhbCRyJ2d5wY1k08wxICgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2Ib0m+Ui93iNJWw3xr7g/L7ygiip7Vx80Vw8T48KV5I=; b=KaUH34BHwL0bjhXMQMt7E6GtKACxM7l2lZnOTAcncP+cR1FV1LVb71rIg1Hm5g0Q/9/YzURdGY+bYMKxu74P8VXjaOgSbjxnYgA41YX8NMaedr6xIXfVENMFnbXtDORiIXtCtBkBfnFRZh/0PcxJZwi0TNtElDeJRYWrEYeeeWTKXx8No7SJ2LO9hdqB7Fnu58WQKeZNVu6XDRCkabmeSMdjSWv70VunZqdQ67iBQERyS+87E88ASyoeyJ3dCxnCo8DVo15NCjRF3qmVCs+MEj5n8xFq60fxK9yy4SnvilZlqSiaTek6wWLo1PDBsUM7djlIAt96+NHZcsnGd4l35A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=haivision.com; dmarc=pass action=none header.from=haivision.com; dkim=pass header.d=haivision.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Hai365.onmicrosoft.com; s=selector2-Hai365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2Ib0m+Ui93iNJWw3xr7g/L7ygiip7Vx80Vw8T48KV5I=; b=NxbH07Q2PZYWhOtgxVQhEBFeyVAJGGDrfaTV4t/ptYhe3eEjUTWwgYQDWP9BmnuUlfxnWECPAJh+L7h2OTvOGSU8GZBqoZs7H35rYrMjZ6Tx3PLyVW6uOya5tRCO8kjVLQoylU9x8HdbC6e3f2y7x5H7zhYz49+V/FdxjV79luQ= Received: from QB1PR01MB3826.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:3a::10) by QB1PR01MB3587.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:3e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.26; Sun, 14 Jun 2020 20:05:14 +0000 Received: from QB1PR01MB3826.CANPRD01.PROD.OUTLOOK.COM ([fe80::80d9:d445:e88f:f931]) by QB1PR01MB3826.CANPRD01.PROD.OUTLOOK.COM ([fe80::80d9:d445:e88f:f931%6]) with mapi id 15.20.3088.028; Sun, 14 Jun 2020 20:05:14 +0000 From: Maxim Sharabayko To: Alexandre GOUAILLARD , "Deen, Glenn (NBCUniversal)" CC: Leslie Daigle , "mops@ietf.org" Thread-Topic: [Mops] Low latency protocol comparision Thread-Index: AQHWQaPph2USpf/JDk28uQNEPpwAU6jXIjKAgAAI2YCAAAYiAIABe0yA Date: Sun, 14 Jun 2020 20:05:14 +0000 Message-ID: <7D14F27F-5914-46EC-9E27-9A61D3CEF820@haivision.com> References: <17635DFD-B536-4B22-8A5D-314BCBEFF19C@nbcuni.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=haivision.com; x-originating-ip: [2a01:c22:8877:8a00:9ddf:b94a:e2d0:9b97] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d7580a1-5587-41fc-67ae-08d8109e4084 x-ms-traffictypediagnostic: QB1PR01MB3587: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04347F8039 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xxrHVdrEt75yisrbYmhkimD1o1dDRs0iH6Pr3/uCwU50jLE8ffepoJNnx3FzMI9t3v33hAiE1N5WKhZIBz6NWnxpgaQlDmwB1VvP7fo3t0/oGhxVWSxnl37nBp6UO2WaP1b4x/MYcfuYcPIYHaDL8QASakZCisAEuEGDY5bXguZvR7pTFl1aJeJqJcxJ56PUQ61gwXOf0dfHShoc062NF2qGf3iagUYtD+TyRN5+OzAXCggkNHwIYH+dTNW6ReoJodt+QnkBBC7hmI9ROv85orSSNgJP1BlxplQxLI4QRurnpz/qbbSzLb2FzdzE3zn4lF1I1p37ZQj4wmNfTEWpVEOcB48CdiYNzJos2LFoOHdGG4tx4TTPdXlq4RoB03QN2LkRuXUrUQhPTdDxKgJbfQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:QB1PR01MB3826.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(396003)(376002)(366004)(39830400003)(7066003)(83380400001)(66946007)(64756008)(91956017)(66556008)(6486002)(66446008)(76116006)(53546011)(66476007)(33656002)(5660300002)(66574014)(316002)(166002)(71200400001)(4326008)(110136005)(2906002)(54906003)(45080400002)(186003)(2616005)(8676002)(478600001)(6512007)(86362001)(16799955002)(8936002)(966005)(6506007)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: verym/Eoxs7HdLMEfwDimAqV+iepZki/pjL6cgDCZWcQIHkWBKnBqu7owp5kks/R4KK/14pFMFRM06HRmLU45eVLuPo/E6JxrwudU3ZSWO0ZMPRYfLkbUTZINBJEkzw1jJIl4zDnMX4/QNU3fgE6qm5Plszne/SKH+N2kW+jYiWzw+sPIydluVW+YD+mLjbAf/MDRG4C/ar+Dik7ALNpLgR3UU8Bq8hJT0UqXg1CZ6RM8k/asFHHXMoA/k/RSWtCf2MJcXr7xgjHohst4iQnp1U4UHRxIwllDXNrawwG6zWnfZbsf/K87BjGxGpFN8A23V78f3LOwYwl36iONM9eh1bUOWw3poi+1kf/aJyeFTKEo5Idpr5xunEwbz1s33C9fakBgCgQaKKRbqvjlNGpE2xz1K8Fnmu+uS1tBwbthLdTOgO8OnuViC99l3YslqGQe5f6o/uCoggkxx1Ru1VYpPr9Pj/mqW0VsfOTlRUl9qVpQZoLOXLx7ZMBjonE3ZKrZOWbpVfxWaX1dis6PZ9lDL5T1AFR9DgbaAc8a/6spAUwoqPJnxPuefDYttVlvheq x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_7D14F27F591446EC9E279A61D3CEF820haivisioncom_" MIME-Version: 1.0 X-OriginatorOrg: haivision.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d7580a1-5587-41fc-67ae-08d8109e4084 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2020 20:05:14.5232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a88156c4-f3f7-4104-8fad-43b93f27493d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K14F1xcFj96MzYffJ8HZ2mauM82aouKWzOpXnbs7LjLtHpZWi3wv8p6vmCIJ3xQCUoWoSZqp4MekGPgGXd2P1cNWePU57PwiCt3JtrWEnW4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3587 Archived-At: Subject: Re: [Mops] Low latency protocol comparision X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 20:05:25 -0000 --_000_7D14F27F591446EC9E279A61D3CEF820haivisioncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBpZGVhIG9mIHBlcmZvcm1pbmcgdGhlIGNvbXBhcmlzb24gaXMgdmVyeSBleGNp dGluZyEgSSB3b3VsZCBiZSBnbGFkIHRvIHBhcnRpY2lwYXRlIGFzIGEgZGVsZWdhdGUgZnJvbSBT UlQuDQoNCkBHbGVuDQpJdCB3b3VsZCBiZSBncmVhdCBpZiBhbnkgU1JUIGZvbGtzIG9uIHRoaXMg bGlzdCBjb3VsZCBkbyBzb21ldGhpbmcgc2ltaWxhciwgIHRvIHRvIG1lbnRpb24gdGhvc2Ugd29y a2luZyB3aXRoIENNQUYgYW5kIExMIEhMUy4NCg0KVGhlcmUgYXJlIG9mIGNvdXJzZSBzb21lIGlu YWNjdXJhY2llcyBpbiB0aGUgZGVzY3JpcHRpb24gb2YgU1JULg0KVGhlIHJlY2VpdmVyIGJ1ZmZl ciBsYXRlbmN5IG9mIDEyMCBtcyBpcyB0aGUgZGVmYXVsdCB2YWx1ZSwgbm90IHRoZSBtaW5pbXVt LiBUaGUgbWluaW11bSBpcyAxIG1zLg0KVGhlcmUgaXMgbm8gbGltaXQgb2YgdGhlIG51bWJlciBv ZiBwYWNrZXQgcmV0cmFuc21pc3Npb25zLCBhbHRob3VnaCB0aGUgY29uZmlndXJhYmxlIGxpbWl0 IG1pZ2h0IGJlIGFkZGVkIHNvb24uDQpITFMgYW5kIERBU0ggY2FuIGJlIHRyYW5zbWl0dGVkIG92 ZXIgU1JULiBBbmQgc28gb24uDQoNCkJ1dCBpbiBnZW5lcmFsIGV2ZW4gd2l0aCB0aGVzZSBpbmFj Y3VyYWNpZXMsIHRoZSBvdmVydmlldyBvZiB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIG9uIHRoZSBt YXJrZXQgaXMgcXVpdGUgZ29vZC4NCg0KLS0NClJlZ2FyZHMsDQpNYXhpbSBTaGFyYWJheWtvDQpT ZW5pb3IgU29mdHdhcmUgRGV2ZWxvcGVyIHwgSGFpdmlzaW9uDQoNCkZyb206IE1vcHMgPG1vcHMt Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEFsZXhhbmRyZSBHT1VBSUxMQVJEIDxhZ291 YWlsbGFyZEBnbWFpbC5jb20+DQpEYXRlOiBTdW5kYXksIDE0LiBKdW5lIDIwMjAgYXQgMDE6MjgN ClRvOiAiRGVlbiwgR2xlbm4gKE5CQ1VuaXZlcnNhbCkiIDxHbGVubi5EZWVuQG5iY3VuaS5jb20+ DQpDYzogTGVzbGllIERhaWdsZSA8bGRhaWdsZUB0aGlua2luZ2NhdC5jb20+LCAibW9wc0BpZXRm Lm9yZyIgPG1vcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01vcHNdIExvdyBsYXRlbmN5IHBy b3RvY29sIGNvbXBhcmlzaW9uDQoNCkBEZWVuLCBhZ3JlZWQuIEkgZ2F2ZSBpdCBhIHRyeSB0aG91 Z2ggYSBjb3VwbGUgb2YgeWVhcnMgYmFjay4gTGV0IG1lIGtub3cgaWYgdGhhdCB3b3VsZCBnbyBp biB0aGUgcmlnaHQgZGlyZWN0aW9uIGFuZCBJIGNhbiB1cGRhdGUgaXQgd2l0aCBldmVyeXRoaW5n IEkgbGVhcm5lZCBpbiB0aGUgbWVhbiB0aW1lLCBhbmQgdGFraW5nIGludG8gYWNjb3VudCB0aGUg dXBkYXRlcyB0byB0aGUgZGlmZmVyZW50IHByb3RvY29scyAoZS5nLiBuZXcgSExTIGluZm9ybWF0 aW9uYWwgZHJhZnQgYnkgcGFudG9zKToNCmh0dHA6Ly93ZWJydGNieWRyYWxleC5jb20vaW5kZXgu cGhwLzIwMTgvMDUvMTUvc3RyZWFtaW5nLXByb3RvY29scy1hbmQtdWx0cmEtbG93LWxhdGVuY3kt aW5jbHVkaW5nLXdlYnJ0Yy8NCg0KQExlc2xpZSwgSSB2b2x1bnRlZXIgZXZlcnkgeWVhciwgZXZl cnkgaGFja2F0aG9uIDotKQ0KSG93ZXZlciwgSSBhbSBtb3JlIGtub3dsZWRnZWFibGUgYWJvdXQg d2VicnRjIHRoYW4gb3RoZXIgcHJvdG9jb2xzLCBzbyBpbiB0aGF0IHJlZ2FyZCwgSSBhbSBiaWFz ZWQuDQpJIHRoaW5rIHRvIGJlIGZhaXIgZWFjaCBwcm90b2NvbCBzaG91bGQgaGF2ZSBhIHJlYXNv bmFibGUgcmVwcmVzZW50YXRpdmUvY2hhbXBpb24gdGhhdCBhdCBsZWFzdCB2YWxpZGF0ZXMgdGhh dCB0aGUgdGVzdGluZyBwcm90b2NvbCBjaG9zZW4gaXMgYWRlcXVhdGUsIGFuZCBnYXJhbnRlZXMg dGhlIGFjY3VyYWN5IGFuZCB0aGUgZmFpcm5lc3Mgb2YgdGhlIHJlc3VsdC4NCg0KRm9yIHdlYnJ0 YywgaXQgd2FzIHByb2JsZW1hdGljIGFzIHdlbGwsIGFzIGVhY2ggYnJvd3NlciB2ZW5kb3IgZGlk IG5vdCB3YW50IHNvbWVvbmUgZWxzZSB0byBiZW5jaG1hcmsgdGhlaXIgaW1wbGVtZW50YXRpb24s IHNvIHdlIGVuZGVkIHVwIHdpdGggb25lIHJlcHJlc2VudGFudCBvZiBlYWNoIGJyb3dzZXIgdmVu ZG9yIGF0IDEwNCBJIGJlbGlldmUgKHByYWd1ZXMpLCB0byB2YWxpZGF0ZSBpdHMgcmVzdWx0LCBh bmQgZGlkIGl0IGFnYWluIGluIG1vbnRyZWFsOg0KaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv aWV0Zi9tZWV0aW5nL3dpa2kvMTA1aGFja2F0aG9uL3dlYnJ0Yw0KaWYgd2UgbWFuYWdlIHRvIGdl dCB0aGUgc2FtZSBzZXR0aW5nLCBJIHRoaW5rIGl0IGNvdWxkIGJlIHZlcnkgc3VjY2Vzc2Z1bCBp biBnZXR0aW5nIGZhaXIgYW5kIGFjY3VyYXRlIHJlc3VsdHMuDQoNCkkgdGhpbmsgd2UgY291bGQg aGFuZGxlIHRoZSB3ZWJydGMgdGVzdGluZyAoYXMgaW4gd3JpdGluZyBvcGVuIHNvdXJjZSB0ZXN0 cyBhbmQgcHJvdmlkaW5nIHJlc3VsdHMgdGhhdCB3b3VsZCBiZSBkZXRlcm1pbmlzdGljIGFuZCBp bmRlcGVuZGVudGx5IHZlcmlmaWFibGUgYnkgYW55IGFuZCBhbGwpLg0KLSBNYXliZSBWZXJpc2tv cGUsIHdoaWNoIGlzIHRyeWluZyB0byBwdXNoIGFuIFJUTVAgMi4wLCBjb3VsZCBiZSBpbnRlcmVz dGVkIGluIGpvaW5pbmcgZm9yIFJUTVAuDQotIE1hZ251cyBXIGZvciBSVFNQIDIuMCA/DQotIFRo ZW4gd2Ugd291bGQgbmVlZCBvbmUgdm9sdW50ZWVyIGZvciBTUlQsDQotIGFuZCBhbm90aGVyIG9u ZSBmb3IgUVVJQyAobWF5YmUgbWFydGluIHRob21wc29uIGNhbiBwb2ludCB1cyBpbiB0aGUgcmln aHQgZGlyZWN0aW9uKS4gUVVJQyBpcyBhbHdheXMgdGhlIGJpZ2dlc3QgdGFibGUgc28gaXQgc2hv dWxkIG5vdCBiZSB0b28gZGlmZmljdWx0Lg0KLSBKb25hdGhhbiBMZW5ub3gsIGNoYWlybWFuIG9m IEFWVENPUkUgaXMgYWx3YXlzIGFyb3VuZCBhbmQgY291bGQgaGVscCwgZXNwZWNpYWxseSBvbiB0 aGUgY29uZ2VzdGlvbiBjb250cm9sLCBFcnJvciBjb25jZWFsbWVudCwgYW5kIGJhbmR3aWR0aCBh ZGFwdGF0aW9uIHBhcnQNCi0gV2UgY291bGQgbW90aXZhdGUgRUtSIHRvIGNvbW1lbnQgb24gdGhl IHNlY3VyaXR5IGFzcGVjdHMuDQotIEknbSBub3Qgc3VyZSBpZiB3ZSB3YW50IHRvIGFzc2VzIElQ djYgYW5kIE5BVCB0cmF2ZXJzYWwgcmVhZGluZXNzIChJQ0UpDQoNCldoYXQgZG8geW91IHRoaW5r Pw0KDQpSZWdhcmRzLA0KDQpEci4gQWxleA0KDQoNCg0KDQoNCg0KT24gU3VuLCBKdW4gMTQsIDIw MjAgYXQgMTowNSBBTSBEZWVuLCBHbGVubiAoTkJDVW5pdmVyc2FsKSA8R2xlbm4uRGVlbkBuYmN1 bmkuY29tPG1haWx0bzpHbGVubi5EZWVuQG5iY3VuaS5jb20+PiB3cm90ZToNClllcywgaXTigJlz IGEgYml0IG1hcmtldGluZywgYnV0IGl04oCZcyBhbHNvIG9uZSBvZiB0aGUgZmV3IHdyaXRlIHVw cyB0aGF0IGF0dGVtcHRzIHRvIHB1dCB0aGUgcG9wdWxhciBtZWRpYSB0cmFuc3BvcnRzIHNpZGUg Ynkgc2lkZSBmb3IgcGVvcGxlIHRvIHVuZGVyc3RhbmQgdGhlaXIgc3RyZW5ndGhzIGFuZCBhYmls aXRpZXMuICAgVGhlIG1hcmtldGluZyBibG9ncyBhbHNvIGdpdmUgdXMsIHRoZSBJRVRGLCBpbnNp Z2h0IGludG8gaG93IHRoZSBvdXRzaWRlIHdvcmxkIG9mIGFkb3B0ZXJzIGFuZCBzZWxsZXJzIG9m IG91ciB3b3JrIHNlZSB0aGluZ3MuDQoNCkkgcmVhbGx5IHdpc2ggdGhhdCBhbGwgd2ViIGRvY3Vt ZW50cyBhbmQgcGFnZXMgY29udGFpbmVkIGEgcG9zdGluZyBkYXRlLiAgIFRoaXMgb25lIGRvZXNu 4oCZdCBnYXZlIGl0IGEgZGF0ZS4gIEhvd2V2ZXIsIHRoZSBwYWdlIG11c3QgYmUgZnJvbSBhdCBs ZWFzdCBtaWQgMjAxOSBhcyBpdCBtZW50aW9ucyB0aGluZ3MgdGhhdCB3ZXJlIHJlbGVhc2VkIHRo ZW4uDQoNCkkgbGlrZSB5b3VyIHdyaXRlIHVwIG9mIHRoZSBXZWJSVEMgaW5hY2N1cmFjaWVzLiAg SXQgd291bGQgYmUgZ3JlYXQgaWYgYW55IFNSVCBmb2xrcyBvbiB0aGlzIGxpc3QgY291bGQgZG8g c29tZXRoaW5nIHNpbWlsYXIsICB0byB0byBtZW50aW9uIHRob3NlIHdvcmtpbmcgd2l0aCBDTUFG IGFuZCBMTCBITFMuICBUaGVyZSBhIGxvdCBvZiBhZG9wdGVycyBvdXQgdGhlcmUgd2hvIGFyZSB3 b3JraW5nIHRocm91Z2ggd2hhdCBwcm90b2NvbCBiZXN0IGZpdHMgdGhlaXIgcGFydGljdWxhciBu ZWVkcyAtIHdlYlJUQz8gICBTUlQ/ICBTb21ldGhpbmcgdGhhdCBicmlnaHQgc3VtbWVyIGludGVy biB3cm90ZSB3aGlsZSBzaGUgd2FzIGhlcmUgbGFzdCBzdW1tZXI/DQoNCiBDYXB0dXJpbmcgc29t ZXRoaW5nIGxpa2UgdGhpcywgYW5kIGV2ZW4gYmV0dGVyIHNvbWUgc29ydCBvZiBiYWtlIG9mZiBh cyB5b3Ugc3VnZ2VzdCB3b3VsZCBiZSB2YWx1YWJsZSB0byBhIGxvdCBvZiBwZW9wbGUuICBUaG91 Z2ggaXQgbWF5IGhhdmUgdG8gd2FpdCB0byBnZXQgY3JpdGljYWwgbWFzcyBvZiBwYXJ0aWNpcGFu dHMgdW50aWwgbmV4dCB5ZWFyLg0KDQpHbGVubg0KDQpPbiBKdW4gMTMsIDIwMjAsIGF0IDM6MzQg UE0sIEFsZXhhbmRyZSBHT1VBSUxMQVJEIDxhZ291YWlsbGFyZEBnbWFpbC5jb208bWFpbHRvOmFn b3VhaWxsYXJkQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhlcmUgYXJlIG11bHRpcGxlIGluYWNjdXJh dGUgc3RhdGVtZW50cyBpbiB0aGUgbGlua2VkIGRvY3VtZW50cy4gTW9zdCBvZiB0aGVtIHRoYXQg aGF2ZSBiZWVuIGNhcnJpZWQgYXJvdW5kIGZvciBtYW55IHllYXJzIGJ5IG90aGVyIFNSVCB2ZW5k b3JzIGxpa2UgV293emEgYW5kIGFscmVhZHkgY2FsbGVkIG91dCAoaGVyZTxodHRwOi8vd2VicnRj YnlkcmFsZXguY29tL2luZGV4LnBocC8yMDE5LzA1LzE4L3dvd3phcy1tYXJrZXRpbmctYXQtd29y ay1hZ2Fpbi13ZWJydGMvPiBmb3IgZXhhbXBsZSkuDQoNCkknbSBqdXN0IGdvaW5nIHRvIHBvaW50 IHRvIHRocmVlIG9mIHRoZSBtb3N0IGVncmVnaW91cyAocmVhZCAidmVyaWZpYWJseSB3cm9uZyIp IHN0YXRlbWVudHMsIHRoYXQgYnkgdGhlbXNlbHZlcyB1bmRlcm1pbmUgdGhlIGNyZWRpYmlsaXR5 IG9mIHRoZSBlbnRpcmUgZG9jdW1lbnQuDQoNCi0gIk1heGltdW0gc3VwcG9ydGVkIHJlc29sdXRp b246IDcyMHAsIDMwIGZyYW1lcyBwZXIgc2Vjb25kIHdpdGggYSBiaXQgcmF0ZSBvZiB1cCB0byAy IE1icHMuIg0KLSBUaGVyZSBpcyBubyBsaW1pdCB0byB0aGUgc3BhdGlhbCBhbmQgdGVtcG9yYWwg cmVzb2x1dGlvbiBpbiB3ZWJydGMvcnRjd2ViIHByb3RvY29sLg0KU3RhZGlhIGZvciBleGFtcGxl IHNlbmQgdXAgdG8gNEtAMzBmcHMuDQoNCiJXZWJSVEMgaXMgaW5mZXJpb3IgdG8gaXRzIGNvbGxl YWd1ZXMgaW4gdGVybXMgb2YgdGhlIGNvZGluZyBxdWFsaXR5IGFuZCBtYXhpbXVtIGFtb3VudCBv ZiB0cmFuc21pdHRlZCBkYXRhLg0KLSBUaGVyZSBpcyBubyBsaW1pdCB0byB0aGUgYmFuZHdpZHRo IHVzZWQgaW4gdGhlIHdlYnJ0Yy9ydGN3ZWIgcHJvdG9jb2wuDQotIFRoZXJlIGlzIGEgbGltaXQg b2YgMk1icHMgcGVyIHBlZXIgY29ubmVjdGlvbiBvbiB0aGUgc2VuZGluZy1zaWRlIG9ubHkgaW4g dGhlIGdvb2dsZSBjaHJvbWUgaW1wbGVtZW50YXRpb24sIG9ubHkgYnkgZGVmYXVsdCAod2ViIGFw cGxpY2F0aW9uIGNhbiBsaWZ0IHRoaXMgbGltaXQpLCBhbmQgb25seSBmb3Igd2ViY2FtcyBkZXZp Y2VzIChzY3JlZW5zaGFyaW5nIGhhcyBubyBiYW5kd2lkdGggbGltaXQpLiBUaGlzIGlzIGEgY2hy b21lIGltcGxlbWVudGF0aW9uIGRldGFpbCwgYW5kIG5vdCBhIHByb3RvY29sIGxpbWl0Lg0KLVdo aWxlIFZQOCBhbmQgSDI2NCBhcmUgYm90aCBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IChvcmlnaW5h bCBJRVRGIGRpc2N1c3Npb248aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9y dGN3ZWIvanVWc1pLcC1BbVJwWUxDZ3ktdXdhcnR1TnJZLz4pIGFueWJvZHkgY2FuIGFkZCBhbnkg Y29kZWMgdG8gd2VicnRjIGFzIGxvbmcgYXMgYW4gUlRQIHBheWxvYWQgc3BlY2lmaWNhdGlvbiBl eGlzdHMuDQotLSBHb29nbGUgY2hyb21lLCBhbmQgZmlyZWZveCwgYm90aCBzdXBwb3J0cyByZWFs LXRpbWUgVlA5IG1vZGUgMiAoNDo0OjQsIDEwIGJpdHMsIEhEUikNCmh0dHBzOi8vc291cmNlLmNo cm9taXVtLm9yZy9jaHJvbWl1bS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXI6dGhpcmRfcGFydHkvd2Vi cnRjL21vZHVsZXMvdmlkZW9fY29kaW5nL2NvZGVjcy92cDkvdnA5X2ltcGwuY2M7bD05ODUNCi0t IENocm9tZSBoYXMgYSByZWFsLXRpbWUgQVYxIGltcGxlbWVudGF0aW9uIGluIHdlYnJ0Yywgd2hp Y2ggZ29lcyB1cCB0byBoaWdoIHByb2ZpbGUgKDQ6NDo0LCA4fjEwYml0cywgSERSKS4NCmh0dHBz Oi8vc291cmNlLmNocm9taXVtLm9yZy9jaHJvbWl1bS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXI6dGhp cmRfcGFydHkvd2VicnRjL21vZHVsZXMvdmlkZW9fY29kaW5nL2NvZGVjcy9hdjEvDQpJbiB0ZXJt cyBvZiBxdWFsaXR5LCBvbmx5IGNvZGVjcyBhdCBoaWdoIHByb2ZpbGUgKGkuZS4gMTJiaXRzKSBj YW4gZG8gYmV0dGVyLCBhbmQgbm9uZSBvZiB0aG9zZSBoYXZlIGEgInJlYWwtdGltZSIgdmVyc2lv biB0b2RheS4NCkluIHRlcm1zIG9mIGNvZGluZyBlZmZpY2llbmN5LCBBVjEgaXMgc3RpbGwgdGhl IGJlc3QgY29kZWMgYXZhaWxhYmxlIGluIHByb2R1Y3Rpb24uDQoNCiJXZWJSVEMgaXMgbm90IGF2 YWlsYWJsZSBpbiBTYWZhcmkgYW5kIHBhcnRpYWxseSB1bmF2YWlsYWJsZSBpbiBCb3dzZXIgYW5k IEVkZ2UuIg0KLSB3ZWJydGMgaXMgZnVsbHkgYXZhaWxhYmxlIGluIEVkZ2UsIGFuZCBTYWZhcmku DQpodHRwczovL2Nhbml1c2UuY29tLyNzZWFyY2g9d2VicnRjDQpvZmZpY2lhbCBkYWlseSBXM0Mg cmVzdWx0czogaHR0cHM6Ly93cHQuZnlpL3Jlc3VsdHMvP2xhYmVsPW1hc3RlciZsYWJlbD1leHBl cmltZW50YWwmYWxpZ25lZCZxPXdlYnJ0Yw0KLSBTYWZhcmkgaGFzIGFkZGVkIEguMjY1IHN1cHBv cnQgaW4gYWRkaXRpb24gdG8gdGhlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgVlA4IGFuZCBILi4y NjQgaW4gdGhlIGxhdGVzdCBzYWZhcmkgdGVjaCBwcmV2aWV3Lg0KDQpJJ20gbm90IGdvaW5nIGlu dG8gdGhlIERpc2N1c3Npb24gYWJvdXQgd2VicnRjJ3MgdW5kZXJseWluZyBSVEMvUlRDUCBwcm90 b2NvbCBhbmQgY29ycmVzcG9uZGluZyBleHRlbnNpb246IE5BQ0ssIFJUWCwgRkVDLCBSRUQsIG9y IENvbmdlc3Rpb24gQ29udHJvbCAoUkVNQiwgR29vZ2xlLWNjLCBCQlIsIE5BREEpLCBhcyBJRVRG IG1lbWJlcnMgSSdtIHN1cmUgeW91IHJlIGFsbCBhd2FyZSBvZiBSRkMzNTUwIGFuZCBhbGwgaXRz IGRlcml2YXRpdmVzLiBNYW55IGF1dGhvcnMgb2YgdGhvc2UgUkZDcyBhcmUgcGFydCBvZiB0aGlz IGdyb3VwLg0KDQpNYXliZSBtb3JlIG92ZXJsb29rZWQgaXMgdGhlIG1vc3QgcmVjZW50IERyYWZ0 IGZvciBlbmQtdG8tZW5kIGVuY3J5cHRpb24gb24gdG9wIG9mIHdlYnJ0YyBjby1hdXRob3JlZCBi eSBnb29nbGU6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb21hcmEtc2ZyYW1l LTAwDQoNCkknbSBub3Qgc2F5aW5nIHRoYXQgU1JUIGlzIHdvcnNlLCBvciBiZXR0ZXIgdGhhbiBX ZWJSVEMuLiBJJ20ganVzdCBzYXlpbmcsIHRoaXMgY29tcGFyaXNvbiBpcyBub3QgZWdyZWdpb3Vz bHkgaW5jb3JyZWN0LCBhbmQgSSdtIGEgbGl0dGxlIGJpdCBzdXJwcmlzZWQgdGhhdCB3ZSBhcmUg ZGlzY3Vzc2luZyBtYXJrZXRpbmcgYmxvZ3MgdGhhdCBnbyBpbiB0aGUgZmFjZSBvZiBzbyBtYW55 IElFVEYgc3BlY3MuDQoNCklmIGFueWJvZHkgaXMgaW50ZXJlc3RlZCBpbiBnb2luZyBkZWVwIGlu dG8gYSByZWFsICB0aG9yb3VnaCBjb21wYXJpc29uIGJldHdlZW4gYWxsIHRob3NlIHByb3RvY29s cywgd2h5IG5vdCBkb2luZyBpdCBkdXJpbmcgdGhlIElFVEYgaGFja2F0aG9uIGluIEp1bHksIG9y IGluIG9jdG9iZXIgKGhvcGVmdWxseSBpbiBCS0spIGp1c3QgbGlrZSB3ZSBkaWQgZ3JvdXAgY28t dGVzdGluZyB3aXRoIElFVEYncyBBVlRDT1JFL0FWRVhUL1FVSUMvUlRDV0VCL1JNQ0FUIGR1cmlu ZyB0aGUgcHJldmlvdXMgSUVURiBoYWNrYXRob25zPw0KDQpSZWdhcmRzLA0KDQoNCg0KT24gU2F0 LCBKdW4gMTMsIDIwMjAgYXQgNjo1OCBQTSBMZXNsaWUgRGFpZ2xlIDxsZGFpZ2xlQHRoaW5raW5n Y2F0LmNvbTxtYWlsdG86bGRhaWdsZUB0aGlua2luZ2NhdC5jb20+PiB3cm90ZToNCg0KSSB0aG91 Z2h0IHRoaXMgd2FzIGEgcHJldHR5IGludGVyZXN0aW5nIGFuYWx5c2lzOg0KDQpMb3cgYnJvYWRj YXN0IGxhdGVuY3kgYW5kIHByb3RvY29scyBmb3IgaW1wbGVtZW50YXRpb24gdGhlcmVvZjoNCmh0 dHBzOi8vd3d3LmVsZWNhcmQuY29tL3BhZ2UvbG93X2Jyb2FkY2FzdF9sYXRlbmN5X2FuZF9wcm90 b2NvbHNfZm9yX2ltcGxlbWVudGF0aW9uX3RoZXJlb2YNCg0KUGFydGljdWxhcmx5IHRlbGxpbmcg aXMgdGhlIGNoYXJ0IGF0IHRoZSBlbmQ6IFdlYlJUQyBhbmQgU1JUIGRvbuKAmXQgbG9vayB2ZXJ5 IHNpbWlsYXIsIGluIHRoaXMgcGFydGljdWxhciByZWdhcmQuDQoNCkxlc2xpZS4NCg0KLS0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTGVzbGllIERhaWdsZQ0KUHJpbmNp cGFsLCBUaGlua2luZ0NhdCBFbnRlcnByaXNlcw0KDQpsZGFpZ2xlQHRoaW5raW5nY2F0LmNvbTxt YWlsdG86bGRhaWdsZUB0aGlua2luZ2NhdC5jb20+DQotLQ0KTW9wcyBtYWlsaW5nIGxpc3QNCk1v cHNAaWV0Zi5vcmc8bWFpbHRvOk1vcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21vcHMNCg0KDQotLQ0KQWxleC4gR291YWlsbGFyZCwgUGhELCBQaEQs IE1CQQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpQcmVzaWRlbnQgLSBDb1NNbyBTb2Z0 d2FyZSBDb25zdWx0aW5nLCBTaW5nYXBvcmUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K c2cubGlua2VkaW4uY29tL2Fnb3VhaWxsYXJkPGh0dHA6Ly9zZy5saW5rZWRpbi5jb20vYWdvdWFp bGxhcmQ+DQrCtw0KLS0NCk1vcHMgbWFpbGluZyBsaXN0DQpNb3BzQGlldGYub3JnPG1haWx0bzpN b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tb3Bz DQoNCg0KLS0NCkFsZXguIEdvdWFpbGxhcmQsIFBoRCwgUGhELCBNQkENCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KUHJlc2lkZW50IC0gQ29TTW8gU29mdHdhcmUgQ29uc3VsdGluZywgU2lu Z2Fwb3JlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnNnLmxpbmtlZGluLmNvbS9hZ291 YWlsbGFyZDxodHRwOi8vc2cubGlua2VkaW4uY29tL2Fnb3VhaWxsYXJkPg0KwrcNCg== --_000_7D14F27F591446EC9E279A61D3CEF820haivisioncom_ Content-Type: text/html; charset="utf-8" Content-ID: <649B788324A85142A6DB776419FC7109@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FsaWJyaSBMaWdodCI7DQoJcGFub3NlLTE6MiAxNSAzIDIgMiAyIDQgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTppbmhlcml0Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg MiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiBc KEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpoMg0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIENoYXIiOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5IZWFkaW5nMkNoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCglt c28tc3R5bGUtbGluazoiSGVhZGluZyAyIjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIs c2Fucy1zZXJpZjsNCgljb2xvcjojMkY1NDk2O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4OTYwODg0Njg7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjY0MzMyNTQzMDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMjUwMzg3NjE1 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzI2NDkzMTA4O30NCkBsaXN0IGwxOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy MTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLURFIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5UaGUgaWRlYSBvZiBwZXJmb3JtaW5nIHRoZSBjb21wYXJpc29uIGlzIHZl cnkgZXhjaXRpbmchIEkgd291bGQgYmUgZ2xhZCB0byBwYXJ0aWNpcGF0ZSBhcyBhIGRlbGVnYXRl IGZyb20gU1JULjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkBH bGVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JdCB3b3VsZCBiZSBncmVh dCBpZiBhbnkgU1JUIGZvbGtzIG9uIHRoaXMgbGlzdCBjb3VsZCBkbyBzb21ldGhpbmcgc2ltaWxh ciwmbmJzcDsgdG8gdG8gbWVudGlvbiB0aG9zZSB3b3JraW5nIHdpdGggQ01BRiBhbmQgTEwgSExT LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZXJlIGFyZSBvZiBjb3Vyc2Ug c29tZSBpbmFjY3VyYWNpZXMgaW4gdGhlIGRlc2NyaXB0aW9uIG9mIFNSVC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSByZWNlaXZlciBidWZmZXIg bGF0ZW5jeSBvZiAxMjAgbXMgaXMgdGhlIGRlZmF1bHQgdmFsdWUsIG5vdCB0aGUgbWluaW11bS4g VGhlIG1pbmltdW0gaXMgMSBtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGVyZSBpcyBubyBsaW1pdCBvZiB0aGUgbnVtYmVyIG9mIHBhY2tldCByZXRy YW5zbWlzc2lvbnMsIGFsdGhvdWdoIHRoZSBjb25maWd1cmFibGUgbGltaXQgbWlnaHQgYmUgYWRk ZWQgc29vbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5I TFMgYW5kIERBU0ggY2FuIGJlIHRyYW5zbWl0dGVkIG92ZXIgU1JULiBBbmQgc28gb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QnV0IGluIGdlbmVyYWwgZXZl biB3aXRoIHRoZXNlIGluYWNjdXJhY2llcywgdGhlIG92ZXJ2aWV3IG9mIHRoZSBleGlzdGluZyBw cm90b2NvbHMgb24gdGhlIG1hcmtldCBpcyBxdWl0ZSBnb29kLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1heGltIFNoYXJhYmF5a288bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TZW5pb3IgU29mdHdhcmUgRGV2 ZWxvcGVyIHwgSGFpdmlzaW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+TW9wcyAmbHQ7bW9wcy1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgQWxleGFuZHJlIEdPVUFJTExBUkQgJmx0O2Fnb3VhaWxsYXJk QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCAxNC4gSnVuZSAyMDIwIGF0 IDAxOjI4PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtEZWVuLCBHbGVubiAoTkJDVW5pdmVyc2FsKSZx dW90OyAmbHQ7R2xlbm4uRGVlbkBuYmN1bmkuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+TGVzbGll IERhaWdsZSAmbHQ7bGRhaWdsZUB0aGlua2luZ2NhdC5jb20mZ3Q7LCAmcXVvdDttb3BzQGlldGYu b3JnJnF1b3Q7ICZsdDttb3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W01vcHNdIExvdyBsYXRlbmN5IHByb3RvY29sIGNvbXBhcmlzaW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkBEZWVuLCBhZ3JlZWQuJm5ic3A7SSBnYXZlIGl0IGEgdHJ5IHRob3VnaCBhIGNvdXBsZSBvZiB5 ZWFycyBiYWNrLiBMZXQgbWUmbmJzcDtrbm93IGlmIHRoYXQgd291bGQmbmJzcDtnbyBpbiB0aGUg cmlnaHQgZGlyZWN0aW9uJm5ic3A7YW5kIEkgY2FuIHVwZGF0ZSBpdCB3aXRoIGV2ZXJ5dGhpbmcg SSBsZWFybmVkIGluIHRoZSBtZWFuIHRpbWUsIGFuZCB0YWtpbmcgaW50byBhY2NvdW50IHRoZSB1 cGRhdGVzIHRvIHRoZSBkaWZmZXJlbnQgcHJvdG9jb2xzDQogKGUuZy4gbmV3IEhMUyBpbmZvcm1h dGlvbmFsIGRyYWZ0IGJ5IHBhbnRvcyk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd2VicnRjYnlkcmFsZXguY29tL2lu ZGV4LnBocC8yMDE4LzA1LzE1L3N0cmVhbWluZy1wcm90b2NvbHMtYW5kLXVsdHJhLWxvdy1sYXRl bmN5LWluY2x1ZGluZy13ZWJydGMvIj5odHRwOi8vd2VicnRjYnlkcmFsZXguY29tL2luZGV4LnBo cC8yMDE4LzA1LzE1L3N0cmVhbWluZy1wcm90b2NvbHMtYW5kLXVsdHJhLWxvdy1sYXRlbmN5LWlu Y2x1ZGluZy13ZWJydGMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QExlc2xpZSwgSSB2b2x1bnRlZXIgZXZlcnkgeWVhciwg ZXZlcnkgaGFja2F0aG9uIDotKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgSSBhbSBtb3JlIGtub3dsZWRnZWFibGUgYWJvdXQgd2Vi cnRjIHRoYW4gb3RoZXIgcHJvdG9jb2xzLCZuYnNwO3NvIGluIHRoYXQgcmVnYXJkLCBJIGFtIGJp YXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgdG8gYmUgZmFpciZuYnNwO2VhY2ggcHJvdG9jb2wgc2hvdWxkIGhhdmUgYSByZWFz b25hYmxlJm5ic3A7cmVwcmVzZW50YXRpdmUvY2hhbXBpb24gdGhhdCBhdCBsZWFzdCB2YWxpZGF0 ZXMgdGhhdCB0aGUgdGVzdGluZyBwcm90b2NvbCBjaG9zZW4gaXMgYWRlcXVhdGUsIGFuZCBnYXJh bnRlZXMmbmJzcDt0aGUgYWNjdXJhY3kgYW5kIHRoZSBmYWlybmVzcyBvZiB0aGUgcmVzdWx0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Ig d2VicnRjLCBpdCB3YXMgcHJvYmxlbWF0aWMgYXMgd2VsbCwgYXMgZWFjaCBicm93c2VyIHZlbmRv ciBkaWQgbm90IHdhbnQgc29tZW9uZSBlbHNlIHRvIGJlbmNobWFyayB0aGVpciZuYnNwO2ltcGxl bWVudGF0aW9uLCBzbyB3ZSBlbmRlZCB1cCB3aXRoIG9uZSByZXByZXNlbnRhbnQmbmJzcDtvZiBl YWNoIGJyb3dzZXIgdmVuZG9yIGF0IDEwNCBJIGJlbGlldmUmbmJzcDsocHJhZ3VlcyksIHRvIHZh bGlkYXRlIGl0cyByZXN1bHQsDQogYW5kIGRpZCBpdCBhZ2FpbiBpbiBtb250cmVhbDo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0 dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lldGYvbWVldGluZy93aWtpLzEwNWhhY2thdGhvbi93 ZWJydGMiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lldGYvbWVldGluZy93aWtpLzEwNWhh Y2thdGhvbi93ZWJydGM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5pZiB3ZSBtYW5hZ2UgdG8gZ2V0IHRoZSBzYW1lIHNldHRpbmcsIEkgdGhp bmsgaXQgY291bGQmbmJzcDtiZSB2ZXJ5IHN1Y2Nlc3NmdWwgaW4mbmJzcDtnZXR0aW5nJm5ic3A7 ZmFpciBhbmQgYWNjdXJhdGUgcmVzdWx0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB3ZSBjb3VsZCBoYW5kbGUgdGhlIHdlYnJ0 YyB0ZXN0aW5nIChhcyBpbiB3cml0aW5nIG9wZW4gc291cmNlIHRlc3RzIGFuZCBwcm92aWRpbmcg cmVzdWx0cyB0aGF0IHdvdWxkIGJlIGRldGVybWluaXN0aWMgYW5kIGluZGVwZW5kZW50bHkmbmJz cDt2ZXJpZmlhYmxlJm5ic3A7YnkgYW55IGFuZCBhbGwpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBNYXliZSBWZXJpc2tvcGUsIHdoaWNoIGlz IHRyeWluZyB0byBwdXNoIGFuIFJUTVAgMi4wLCBjb3VsZCBiZSBpbnRlcmVzdGVkIGluIGpvaW5p bmcmbmJzcDtmb3IgUlRNUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0gTWFnbnVzIFcgZm9yIFJUU1AgMi4wID88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVGhlbiB3ZSB3b3VsZCBuZWVkIG9u ZSB2b2x1bnRlZXIgZm9yIFNSVCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0gYW5kIGFub3RoZXIgb25lIGZvciBRVUlDIChtYXliZSBtYXJ0aW4g dGhvbXBzb24gY2FuIHBvaW50IHVzIGluIHRoZSByaWdodCBkaXJlY3Rpb24pLiBRVUlDIGlzIGFs d2F5cyB0aGUgYmlnZ2VzdCB0YWJsZSBzbyBpdCBzaG91bGQgbm90IGJlIHRvbyBkaWZmaWN1bHQu DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g Sm9uYXRoYW4gTGVubm94LCBjaGFpcm1hbiBvZiBBVlRDT1JFIGlzIGFsd2F5cyBhcm91bmQgYW5k IGNvdWxkIGhlbHAsIGVzcGVjaWFsbHkgb24gdGhlIGNvbmdlc3Rpb24gY29udHJvbCwgRXJyb3Ig Y29uY2VhbG1lbnQsIGFuZCBiYW5kd2lkdGggYWRhcHRhdGlvbiBwYXJ0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFdlIGNvdWxkIG1vdGl2YXRl IEVLUiB0byBjb21tZW50IG9uIHRoZSBzZWN1cml0eSBhc3BlY3RzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJJ20gbm90IHN1cmUgaWYgd2Ug d2FudCB0byBhc3NlcyBJUHY2IGFuZCBOQVQgdHJhdmVyc2FsIHJlYWRpbmVzcyAoSUNFKTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGRv IHlvdSB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmVnYXJkcywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RHIuIEFsZXg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBT dW4sIEp1biAxNCwgMjAyMCBhdCAxOjA1IEFNIERlZW4sIEdsZW5uIChOQkNVbml2ZXJzYWwpICZs dDs8YSBocmVmPSJtYWlsdG86R2xlbm4uRGVlbkBuYmN1bmkuY29tIj5HbGVubi5EZWVuQG5iY3Vu aS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlllcywgaXTigJlzIGEgYml0IG1hcmtldGluZywgYnV0IGl04oCZcyBh bHNvIG9uZSBvZiB0aGUgZmV3IHdyaXRlIHVwcyB0aGF0IGF0dGVtcHRzIHRvIHB1dCB0aGUgcG9w dWxhciBtZWRpYSB0cmFuc3BvcnRzIHNpZGUgYnkgc2lkZSBmb3IgcGVvcGxlIHRvIHVuZGVyc3Rh bmQgdGhlaXIgc3RyZW5ndGhzIGFuZCBhYmlsaXRpZXMuICZuYnNwOyBUaGUgbWFya2V0aW5nIGJs b2dzIGFsc28gZ2l2ZSB1cywgdGhlIElFVEYsIGluc2lnaHQNCiBpbnRvIGhvdyB0aGUgb3V0c2lk ZSB3b3JsZCBvZiBhZG9wdGVycyBhbmQgc2VsbGVycyBvZiBvdXIgd29yayBzZWUgdGhpbmdzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkkgcmVhbGx5IHdpc2ggdGhhdCBhbGwgd2ViIGRvY3VtZW50 cyBhbmQgcGFnZXMgY29udGFpbmVkIGEgcG9zdGluZyBkYXRlLiAmbmJzcDsgVGhpcyBvbmUgZG9l c27igJl0IGdhdmUgaXQgYSBkYXRlLiZuYnNwOyBIb3dldmVyLCB0aGUmbmJzcDs8L3NwYW4+cGFn ZSBtdXN0IGJlIGZyb20gYXQgbGVhc3QgbWlkIDIwMTkgYXMgaXQgbWVudGlvbnMgdGhpbmdzIHRo YXQgd2VyZSByZWxlYXNlZCB0aGVuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGxpa2UgeW91ciB3cml0ZSB1cCBvZiB0aGUgV2ViUlRDIGlu YWNjdXJhY2llcy4mbmJzcDsgSXQgd291bGQgYmUgZ3JlYXQgaWYgYW55IFNSVCBmb2xrcyBvbiB0 aGlzIGxpc3QgY291bGQgZG8gc29tZXRoaW5nIHNpbWlsYXIsICZuYnNwO3RvIHRvIG1lbnRpb24g dGhvc2Ugd29ya2luZyB3aXRoIENNQUYgYW5kIExMIEhMUy4mbmJzcDsgVGhlcmUgYSBsb3Qgb2Yg YWRvcHRlcnMgb3V0IHRoZXJlIHdobyBhcmUgd29ya2luZyB0aHJvdWdoDQogd2hhdCBwcm90b2Nv bCBiZXN0IGZpdHMgdGhlaXIgcGFydGljdWxhciBuZWVkcyAtIHdlYlJUQz8gJm5ic3A7IFNSVD8m bmJzcDsgU29tZXRoaW5nIHRoYXQgYnJpZ2h0IHN1bW1lciBpbnRlcm4gd3JvdGUgd2hpbGUgc2hl IHdhcyBoZXJlIGxhc3Qgc3VtbWVyPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtDYXB0dXJpbmcgc29tZXRoaW5nIGxpa2Ug dGhpcywgYW5kIGV2ZW4gYmV0dGVyIHNvbWUgc29ydCBvZiBiYWtlIG9mZiBhcyB5b3Ugc3VnZ2Vz dCB3b3VsZCBiZSB2YWx1YWJsZSB0byBhIGxvdCBvZiBwZW9wbGUuJm5ic3A7IFRob3VnaCBpdCBt YXkgaGF2ZSB0byB3YWl0IHRvIGdldCBjcml0aWNhbCBtYXNzIG9mIHBhcnRpY2lwYW50cyB1bnRp bCBuZXh0IHllYXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkdsZW5uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBKdW4g MTMsIDIwMjAsIGF0IDM6MzQgUE0sIEFsZXhhbmRyZSBHT1VBSUxMQVJEICZsdDs8YSBocmVmPSJt YWlsdG86YWdvdWFpbGxhcmRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWdvdWFpbGxhcmRA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIG11bHRpcGxlIGlu YWNjdXJhdGUgc3RhdGVtZW50cyBpbiB0aGUgbGlua2VkIGRvY3VtZW50cy4gTW9zdCBvZiB0aGVt IHRoYXQgaGF2ZSBiZWVuIGNhcnJpZWQgYXJvdW5kIGZvciBtYW55IHllYXJzIGJ5IG90aGVyIFNS VCB2ZW5kb3JzIGxpa2UgV293emEgYW5kIGFscmVhZHkgY2FsbGVkIG91dCAoPGEgaHJlZj0iaHR0 cDovL3dlYnJ0Y2J5ZHJhbGV4LmNvbS9pbmRleC5waHAvMjAxOS8wNS8xOC93b3d6YXMtbWFya2V0 aW5nLWF0LXdvcmstYWdhaW4td2VicnRjLyIgdGFyZ2V0PSJfYmxhbmsiPmhlcmU8L2E+DQogZm9y IGV4YW1wbGUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JJ20ganVzdCBnb2luZyB0byBwb2ludCZuYnNwO3RvIHRocmVlIG9mIHRoZSBtb3N0 IGVncmVnaW91cyZuYnNwOyhyZWFkICZxdW90O3ZlcmlmaWFibHkgd3JvbmcmcXVvdDspIHN0YXRl bWVudHMsIHRoYXQgYnkgdGhlbXNlbHZlcyB1bmRlcm1pbmUgdGhlIGNyZWRpYmlsaXR5IG9mIHRo ZSBlbnRpcmUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LSAmcXVvdDtNYXhpbXVtIHN1cHBvcnRlZCByZXNvbHV0aW9uOiA3MjBwLCAzMCBm cmFtZXMgcGVyIHNlY29uZCB3aXRoIGEgYml0IHJhdGUgb2YgdXAgdG8gMiBNYnBzLiZxdW90Ozxi cj4NCi0gVGhlcmUgaXMgbm8gbGltaXQgdG8gdGhlIHNwYXRpYWwgYW5kIHRlbXBvcmFsIHJlc29s dXRpb24gaW4gd2VicnRjL3J0Y3dlYiBwcm90b2NvbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0YWRpYSBmb3IgZXhhbXBsZSBzZW5kIHVwIHRv IDRLQDMwZnBzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mcXVvdDtXZWJSVEMgaXMgaW5mZXJpb3IgdG8gaXRzIGNvbGxlYWd1ZXMgaW4gdGVy bXMgb2YgdGhlIGNvZGluZyBxdWFsaXR5IGFuZCBtYXhpbXVtIGFtb3VudCBvZiB0cmFuc21pdHRl ZCBkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBUaGVyZSBpcyBubyBsaW1pdCB0byB0aGUgYmFuZHdpZHRoIHVzZWQgaW4gdGhlIHdlYnJ0 Yy9ydGN3ZWIgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tIFRoZXJlIGlzIGEgbGltaXQgb2YgMk1icHMgcGVyIHBlZXIgY29ubmVj dGlvbiBvbiB0aGUgc2VuZGluZy1zaWRlDQo8Yj5vbmx5IGluIHRoZSBnb29nbGUgY2hyb21lIGlt cGxlbWVudGF0aW9uPC9iPiwgb25seSBieSBkZWZhdWx0ICh3ZWIgYXBwbGljYXRpb24gY2FuIGxp ZnQgdGhpcyBsaW1pdCksIGFuZCBvbmx5IGZvciB3ZWJjYW1zIGRldmljZXMgKHNjcmVlbnNoYXJp bmcgaGFzIG5vIGJhbmR3aWR0aCBsaW1pdCkuIFRoaXMgaXMgYSBjaHJvbWUgaW1wbGVtZW50YXRp b24gZGV0YWlsLCBhbmQgbm90IGEgcHJvdG9jb2wgbGltaXQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tV2hpbGUgVlA4IGFuZCBIMjY0IGFyZSBi b3RoIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgKDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvcnRjd2ViL2p1VnNaS3AtQW1ScFlMQ2d5LXV3YXJ0dU5yWS8iIHRh cmdldD0iX2JsYW5rIj5vcmlnaW5hbCBJRVRGIGRpc2N1c3Npb248L2E+KSBhbnlib2R5IGNhbiBh ZGQgYW55IGNvZGVjIHRvIHdlYnJ0YyBhcyBsb25nIGFzIGFuIFJUUA0KIHBheWxvYWQgc3BlY2lm aWNhdGlvbiBleGlzdHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSBHb29nbGUgY2hyb21lLCBhbmQgZmlyZWZveCwgYm90aCBzdXBwb3J0cyBy ZWFsLXRpbWUgVlA5IG1vZGUgMiAoNDo0OjQsIDEwIGJpdHMsIEhEUik8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vc291 cmNlLmNocm9taXVtLm9yZy9jaHJvbWl1bS9jaHJvbWl1bS9zcmMvJiM0MzsvbWFzdGVyOnRoaXJk X3BhcnR5L3dlYnJ0Yy9tb2R1bGVzL3ZpZGVvX2NvZGluZy9jb2RlY3MvdnA5L3ZwOV9pbXBsLmNj O2w9OTg1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zb3VyY2UuY2hyb21pdW0ub3JnL2Nocm9t aXVtL2Nocm9taXVtL3NyYy8mIzQzOy9tYXN0ZXI6dGhpcmRfcGFydHkvd2VicnRjL21vZHVsZXMv dmlkZW9fY29kaW5nL2NvZGVjcy92cDkvdnA5X2ltcGwuY2M7bD05ODU8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBDaHJvbWUgaGFzIGEg cmVhbC10aW1lIEFWMSBpbXBsZW1lbnRhdGlvbiBpbiB3ZWJydGMsIHdoaWNoIGdvZXMgdXAgdG8g aGlnaCBwcm9maWxlICg0OjQ6NCwgOH4xMGJpdHMsIEhEUikuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3NvdXJjZS5j aHJvbWl1bS5vcmcvY2hyb21pdW0vY2hyb21pdW0vc3JjLyYjNDM7L21hc3Rlcjp0aGlyZF9wYXJ0 eS93ZWJydGMvbW9kdWxlcy92aWRlb19jb2RpbmcvY29kZWNzL2F2MS8iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3NvdXJjZS5jaHJvbWl1bS5vcmcvY2hyb21pdW0vY2hyb21pdW0vc3JjLyYjNDM7 L21hc3Rlcjp0aGlyZF9wYXJ0eS93ZWJydGMvbW9kdWxlcy92aWRlb19jb2RpbmcvY29kZWNzL2F2 MS88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbiB0ZXJtcyBvZiBxdWFsaXR5LCBvbmx5IGNvZGVjcyBhdCBoaWdoIHByb2ZpbGUgKGkuZS4g MTJiaXRzKSBjYW4gZG8gYmV0dGVyLCBhbmQgbm9uZSBvZiB0aG9zZSBoYXZlIGEgJnF1b3Q7cmVh bC10aW1lJnF1b3Q7IHZlcnNpb24gdG9kYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0ZXJtcyBvZiBjb2RpbmcgZWZmaWNpZW5jeSwgQVYx IGlzIHN0aWxsIHRoZSBiZXN0IGNvZGVjIGF2YWlsYWJsZSBpbiBwcm9kdWN0aW9uLjxicj4NCjxi cj4NCiZxdW90O1dlYlJUQyBpcyBub3QgYXZhaWxhYmxlIGluIFNhZmFyaSBhbmQgcGFydGlhbGx5 IHVuYXZhaWxhYmxlIGluIEJvd3NlciBhbmQgRWRnZS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gd2VicnRjIGlzIGZ1bGx5IGF2YWls YWJsZSBpbiBFZGdlLCBhbmQgU2FmYXJpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9jYW5pdXNlLmNvbS8jc2VhcmNo PXdlYnJ0YyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2FuaXVzZS5jb20vI3NlYXJjaD13ZWJy dGM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5vZmZpY2lhbCBkYWlseSBXM0MgcmVzdWx0czombmJzcDs8YSBocmVmPSJodHRwczovL3dwdC5m eWkvcmVzdWx0cy8/bGFiZWw9bWFzdGVyJmFtcDtsYWJlbD1leHBlcmltZW50YWwmYW1wO2FsaWdu ZWQmYW1wO3E9d2VicnRjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93cHQuZnlpL3Jlc3VsdHMv P2xhYmVsPW1hc3RlciZhbXA7bGFiZWw9ZXhwZXJpbWVudGFsJmFtcDthbGlnbmVkJmFtcDtxPXdl YnJ0YzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi0gU2FmYXJpIGhhcyBhZGRlZCBILjI2NSBzdXBwb3J0IGluIGFkZGl0aW9uIHRvIHRoZSBt YW5kYXRvcnkgdG8gaW1wbGVtZW50IFZQOCBhbmQgSC4uMjY0IGluIHRoZSBsYXRlc3Qgc2FmYXJp IHRlY2ggcHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSdtIG5vdCBnb2luZyBpbnRvIHRoZSBEaXNjdXNzaW9uIGFib3V0IHdlYnJ0 YydzIHVuZGVybHlpbmcgUlRDL1JUQ1AgcHJvdG9jb2wgYW5kIGNvcnJlc3BvbmRpbmcgZXh0ZW5z aW9uOiBOQUNLLCBSVFgsIEZFQywgUkVELCBvciBDb25nZXN0aW9uIENvbnRyb2wgKFJFTUIsIEdv b2dsZS1jYywgQkJSLCBOQURBKSwgYXMgSUVURiBtZW1iZXJzIEknbSBzdXJlIHlvdSByZSBhbGwg YXdhcmUgb2YgUkZDMzU1MCBhbmQNCiBhbGwgaXRzIGRlcml2YXRpdmVzLiBNYW55IGF1dGhvcnMg b2YgdGhvc2UgUkZDcyBhcmUgcGFydCBvZiB0aGlzIGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSBtb3JlIG92ZXJsb29rZWQg aXMgdGhlIG1vc3QgcmVjZW50IERyYWZ0IGZvciBlbmQtdG8tZW5kIGVuY3J5cHRpb24gb24gdG9w IG9mIHdlYnJ0YyBjby1hdXRob3JlZCBieSBnb29nbGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtb21hcmEtc2ZyYW1lLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW9tYXJhLXNmcmFtZS0wMDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBzYXlpbmcg dGhhdCBTUlQgaXMgd29yc2UsIG9yIGJldHRlciB0aGFuIFdlYlJUQy4uIEknbSBqdXN0IHNheWlu ZywgdGhpcyBjb21wYXJpc29uIGlzIG5vdCBlZ3JlZ2lvdXNseSBpbmNvcnJlY3QsIGFuZCBJJ20g YSBsaXR0bGUgYml0IHN1cnByaXNlZCB0aGF0IHdlIGFyZSBkaXNjdXNzaW5nIG1hcmtldGluZyBi bG9ncyB0aGF0IGdvIGluIHRoZSBmYWNlIG9mIHNvIG1hbnkgSUVURiBzcGVjcy4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgYW55 Ym9keSBpcyBpbnRlcmVzdGVkIGluIGdvaW5nIGRlZXAgaW50byBhIHJlYWwgJm5ic3A7dGhvcm91 Z2ggY29tcGFyaXNvbiBiZXR3ZWVuIGFsbCB0aG9zZSBwcm90b2NvbHMsIHdoeSBub3QgZG9pbmcg aXQgZHVyaW5nIHRoZSBJRVRGIGhhY2thdGhvbiBpbiBKdWx5LCBvciBpbiBvY3RvYmVyIChob3Bl ZnVsbHkgaW4gQktLKSBqdXN0IGxpa2Ugd2UgZGlkIGdyb3VwIGNvLXRlc3Rpbmcgd2l0aCBJRVRG J3MgQVZUQ09SRS9BVkVYVC9RVUlDL1JUQ1dFQi9STUNBVA0KIGR1cmluZyB0aGUgcHJldmlvdXMg SUVURiBoYWNrYXRob25zPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgSnVuIDEzLCAyMDIwIGF0IDY6NTggUE0gTGVz bGllIERhaWdsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxkYWlnbGVAdGhpbmtpbmdjYXQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bGRhaWdsZUB0aGlua2luZ2NhdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SSB0aG91Z2h0IHRoaXMgd2FzIGEg cHJldHR5IGludGVyZXN0aW5nIGFuYWx5c2lzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Mb3cg YnJvYWRjYXN0IGxhdGVuY3kgYW5kIHByb3RvY29scyBmb3IgaW1wbGVtZW50YXRpb24gdGhlcmVv Zjo8YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZWxlY2FyZC5jb20vcGFnZS9sb3df YnJvYWRjYXN0X2xhdGVuY3lfYW5kX3Byb3RvY29sc19mb3JfaW1wbGVtZW50YXRpb25fdGhlcmVv ZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzOTgzQzQiPmh0dHBzOi8vd3d3LmVsZWNhcmQuY29tL3Bh Z2UvbG93X2Jyb2FkY2FzdF9sYXRlbmN5X2FuZF9wcm90b2NvbHNfZm9yX2ltcGxlbWVudGF0aW9u X3RoZXJlb2Y8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UGFydGljdWxhcmx5IHRl bGxpbmcgaXMgdGhlIGNoYXJ0IGF0IHRoZSBlbmQ6IFdlYlJUQyBhbmQgU1JUIGRvbuKAmXQgbG9v ayB2ZXJ5IHNpbWlsYXIsIGluIHRoaXMgcGFydGljdWxhciByZWdhcmQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPkxlc2xpZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LS0gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIwIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRl ciI+DQo8L3NwYW4+PC9kaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+TGVzbGllIERhaWdsZTxicj4NClByaW5jaXBhbCwgVGhpbmtp bmdDYXQgRW50ZXJwcmlzZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8aDI+PGEgaHJlZj0ibWFp bHRvOmxkYWlnbGVAdGhpbmtpbmdjYXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMzk4M0M0Ij5sZGFpZ2xlQHRoaW5raW5nY2F0LmNvbTwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9oMj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCk1vcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOk1vcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5Nb3BzQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bW9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxleC4gR291YWlsbGFy ZCwgUGhELCBQaEQsIE1CQSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByZXNpZGVudCAtIENvU01vIFNvZnR3YXJlIENv bnN1bHRpbmcsIFNpbmdhcG9yZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vc2cu bGlua2VkaW4uY29tL2Fnb3VhaWxsYXJkIiB0YXJnZXQ9Il9ibGFuayI+c2cubGlua2VkaW4uY29t L2Fnb3VhaWxsYXJkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTt0ZXh0LWluZGVudDotMTguMHB0O2xp bmUtaGVpZ2h0OjE0LjRwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMjt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzMzMzMzMyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPg0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7aW5oZXJpdCZxdW90OyxzZXJpZjtjb2xv cjojMzMzMzMzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi0tIDxicj4NCk1vcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk1vcHNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5Nb3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9wcyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9wczwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFs ZXguIEdvdWFpbGxhcmQsIFBoRCwgUGhELCBNQkE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByZXNpZGVudCAtIENvU01v IFNvZnR3YXJlIENvbnN1bHRpbmcsIFNpbmdhcG9yZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwOi8vc2cubGlua2VkaW4uY29tL2Fnb3VhaWxsYXJkIiB0YXJnZXQ9Il9ibGFuayI+c2cu bGlua2VkaW4uY29tL2Fnb3VhaWxsYXJkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTt0ZXh0LWluZGVu dDotMTguMHB0O2xpbmUtaGVpZ2h0OjE0LjRwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNDt2ZXJ0 aWNhbC1hbGlnbjpiYXNlbGluZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzMzMzMzMyI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7aW5oZXJpdCZxdW90OyxzZXJpZjtj b2xvcjojMzMzMzMzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_7D14F27F591446EC9E279A61D3CEF820haivisioncom_-- From nobody Wed Jun 24 06:41:37 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C2D3A0DDD for ; Wed, 24 Jun 2020 06:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8_Vq8UBWE6V for ; Wed, 24 Jun 2020 06:41:33 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588343A0DC3 for ; Wed, 24 Jun 2020 06:41:33 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id i4so2130801iov.11 for ; Wed, 24 Jun 2020 06:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FF2QqVbOM8kDpAQUaLYNGAwNgSyUXybVeY5kK9fyzjg=; b=NTNBgT9Qv+fV0JB6sUdKEVB1u4EQ2ubn6Z0E1MwgqThjvK7fZbkrkD7xYFXcT4DwGK nu1ZAcGsZpG6OGoj1xnmJjCX80t1rQM3SYW7akk+d42OdwXkd6wRdf6TgysxWsmthl7h FEQ27JblndSktvy8YmX7dPPKsyBWZA0+gml8g6UBk9xHc91elm3bY9Mbowl91ALRyNs1 rVc3vt/Wmm2q5s4Nk99vFkoJ6CGAlUG1+IwA5yCd/viJcTCFc2z+8vlRDMGeKUxiuggv r3fXyH2L26SX+KSZmk6ZbqIvyMhW5/u5I7t2jM5+og+C/E0iWqxu9wDDIJKgtId/M9H8 a8Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FF2QqVbOM8kDpAQUaLYNGAwNgSyUXybVeY5kK9fyzjg=; b=XQLsMnFLBQ2EZsPOO4li5711LUtLIbaBkO7PyS20MOa8GdD9WGQocqmiQrstb0C8Ev IYXmUKxNaZ6fXDX3U020n2q3r3WVhmVVRxvmTLRTjBr5B+8slt++wBNmnCOdyRcAgfqx AiANXAsCSQochCWGbFbfvoGK4NYglOk+tDo3h6fsOiQp5yuDjXjmkX3aA7+wD5wDxDa0 QQgeG9gTU/XVp/K2CaLvpZqa80fu985nhDYicbKvZZV+VjsR0LnMtjJJyIui4Ta+BnMs T8PZPRI+iELkIjyMkypV2u0QqYJiiaxJ7yq0sV9sk6wnQ8pA0vf5a2jZ56pvftBkd9eG 00ZA== X-Gm-Message-State: AOAM533dRKra/mA0ZSPO+3UuWdQ16wPsB3yWYu8i6HhEl7fuMm/osa6U EIEr8dic+60HJioSkrof9fA9VGfEpWgxpmEJZVyVlwRAmHg= X-Google-Smtp-Source: ABdhPJyqDJtXnOs9iaGAIdKyaVWwAVlIgb+r+SWbzHn/q2PT3qO1WIJqM34AnFXO2HkDC4Znm+j1fasjnKHuBCV20mU= X-Received: by 2002:a02:10c1:: with SMTP id 184mr22401569jay.135.1593006092344; Wed, 24 Jun 2020 06:41:32 -0700 (PDT) MIME-Version: 1.0 References: <17635DFD-B536-4B22-8A5D-314BCBEFF19C@nbcuni.com> <7D14F27F-5914-46EC-9E27-9A61D3CEF820@haivision.com> In-Reply-To: <7D14F27F-5914-46EC-9E27-9A61D3CEF820@haivision.com> From: Alexandre GOUAILLARD Date: Wed, 24 Jun 2020 15:41:20 +0200 Message-ID: To: Maxim Sharabayko Cc: "Deen, Glenn (NBCUniversal)" , Leslie Daigle , "mops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000042620a05a8d4a29c" Archived-At: Subject: Re: [Mops] Low latency protocol comparision X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 13:41:36 -0000 --00000000000042620a05a8d4a29c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I went around to the long time Hackathon attending IETF media guys and it looks like it's going to be too short notice to prepare something for Madrid. Between AV1 RTP payload and implementation, the SVC extensions, the QuicTransport / WebTransport , and the End-To-End encryption for real-time media, everybody that would be otherwise interested and capable to contribute is real busy. However, I gathered sufficient interest for BKK (whether it will be virtual or not), given the usual rules those people abide by are followed. Since IETF does not have a set of proper rules nor a formal test suite, those follow the rules that were used at IMTC superop events, previous IETF Hackathon, W3C 's web-platform tests and/or AOMedia 's testing working group. The usual IETF rules about the usage of MUST or SHOULD apply. - Test cases must be discussed and defined early on, to make sure the "everything else being equal" statement applies. The definition of starting point and end point of latency measurement for example varies a lot depending on the study. - Test content (if any) must be defined and made publicly available to be able to independently reproduce results. - Test suite should be written in advance. The same test suite should be used by all. The test code must be made publicly available to be able to independently reproduce results. - If the need for specific test bed appears, e.g. controlled network, programmatic packet loss / jitter / bandwidth variation, we should speak with the IETF network guys, and/or Charles E. to have that set up (in the case of a real meeting), or for a common open source test infrastructure like e.g. KITE to be set up and made available. We usually consider it fair to provide 3 months to everyone after the first comparative results are out, to try to optimize their implementations or address bugs found in the process, so that the results are representative of the capacity of a protocol, and not the deficiency of a given implementation. I don't know if it makes sense to do this here, e.g. to have temporary results in BKK, but give untill IETF 110 in Pragues to freeze the data, since SRT is not an IETF protocol with fixed versions and revisions at this stage. If this sounds reasonable to at least one of the chair, and from maxim or another SRT representative, I'm happy to facilitate for IETF 109 the set up, bring enough IETF people and open source media server people to the table to have critical mass of data and review, and to facilitate the writing of a subsequent ID, in the same spirit we published a comparative study of open-source media webrtc media servers: https://www.semanticscholar.org/paper/Comparative-Study-of-WebRTC-Open-Sour= ce-SFUs-for-Andre-Breton/10b877cc13ffc9a1cabbf415cba73b22a1dd5442 Best regards, Dr. Alex. On Sun, Jun 14, 2020 at 10:05 PM Maxim Sharabayko < maxsharabayko@haivision.com> wrote: > Hi, > > > > The idea of performing the comparison is very exciting! I would be glad t= o > participate as a delegate from SRT. > > > > @Glen > > *It would be great if any SRT folks on this list could do something > similar, to to mention those working with CMAF and LL HLS.* > > > > There are of course some inaccuracies in the description of SRT. > > The receiver buffer latency of 120 ms is the default value, not the > minimum. The minimum is 1 ms. > > There is no limit of the number of packet retransmissions, although the > configurable limit might be added soon. > > HLS and DASH can be transmitted over SRT. And so on. > > > > But in general even with these inaccuracies, the overview of the existing > protocols on the market is quite good. > > > > -- > > Regards, > > Maxim Sharabayko > > Senior Software Developer | Haivision > > > > *From: *Mops on behalf of Alexandre GOUAILLARD < > agouaillard@gmail.com> > *Date: *Sunday, 14. June 2020 at 01:28 > *To: *"Deen, Glenn (NBCUniversal)" > *Cc: *Leslie Daigle , "mops@ietf.org" < > mops@ietf.org> > *Subject: *Re: [Mops] Low latency protocol comparision > > > > @Deen, agreed. I gave it a try though a couple of years back. Let me know > if that would go in the right direction and I can update it with everythi= ng > I learned in the mean time, and taking into account the updates to the > different protocols (e.g. new HLS informational draft by pantos): > > > http://webrtcbydralex.com/index.php/2018/05/15/streaming-protocols-and-ul= tra-low-latency-including-webrtc/ > > > > @Leslie, I volunteer every year, every hackathon :-) > > However, I am more knowledgeable about webrtc than other protocols, so in > that regard, I am biased. > > I think to be fair each protocol should have a > reasonable representative/champion that at least validates that the testi= ng > protocol chosen is adequate, and garantees the accuracy and the fairness = of > the result. > > > > For webrtc, it was problematic as well, as each browser vendor did not > want someone else to benchmark their implementation, so we ended up with > one representant of each browser vendor at 104 I believe (pragues), to > validate its result, and did it again in montreal: > > https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon/webrtc > > if we manage to get the same setting, I think it could be very successful > in getting fair and accurate results. > > > > I think we could handle the webrtc testing (as in writing open source > tests and providing results that would be deterministic and > independently verifiable by any and all). > > - Maybe Veriskope, which is trying to push an RTMP 2.0, could be > interested in joining for RTMP. > > - Magnus W for RTSP 2.0 ? > > - Then we would need one volunteer for SRT, > > - and another one for QUIC (maybe martin thompson can point us in the > right direction). QUIC is always the biggest table so it should not be to= o > difficult. > > - Jonathan Lennox, chairman of AVTCORE is always around and could help, > especially on the congestion control, Error concealment, and bandwidth > adaptation part > > - We could motivate EKR to comment on the security aspects. > > - I'm not sure if we want to asses IPv6 and NAT traversal readiness (ICE) > > > > What do you think? > > > > Regards, > > > > Dr. Alex > > > > > > > > > > > > > > On Sun, Jun 14, 2020 at 1:05 AM Deen, Glenn (NBCUniversal) < > Glenn.Deen@nbcuni.com> wrote: > > Yes, it=E2=80=99s a bit marketing, but it=E2=80=99s also one of the few w= rite ups that > attempts to put the popular media transports side by side for people to > understand their strengths and abilities. The marketing blogs also give > us, the IETF, insight into how the outside world of adopters and sellers = of > our work see things. > > > > I really wish that all web documents and pages contained a posting date. > This one doesn=E2=80=99t gave it a date. However, the page must be from = at least > mid 2019 as it mentions things that were released then. > > > > I like your write up of the WebRTC inaccuracies. It would be great if an= y > SRT folks on this list could do something similar, to to mention those > working with CMAF and LL HLS. There a lot of adopters out there who are > working through what protocol best fits their particular needs - webRTC? > SRT? Something that bright summer intern wrote while she was here last > summer? > > > > Capturing something like this, and even better some sort of bake off as > you suggest would be valuable to a lot of people. Though it may have to > wait to get critical mass of participants until next year. > > > > Glenn > > > > On Jun 13, 2020, at 3:34 PM, Alexandre GOUAILLARD > wrote: > > There are multiple inaccurate statements in the linked documents. Most of > them that have been carried around for many years by other SRT vendors li= ke > Wowza and already called out (here > > for example). > > > > I'm just going to point to three of the most egregious (read "verifiably > wrong") statements, that by themselves undermine the credibility of the > entire document. > > > > - "Maximum supported resolution: 720p, 30 frames per second with a bit > rate of up to 2 Mbps." > - There is no limit to the spatial and temporal resolution in > webrtc/rtcweb protocol. > > Stadia for example send up to 4K@30fps. > > > > "WebRTC is inferior to its colleagues in terms of the coding quality and > maximum amount of transmitted data. > > - There is no limit to the bandwidth used in the webrtc/rtcweb protocol. > > - There is a limit of 2Mbps per peer connection on the sending-side *only > in the google chrome implementation*, only by default (web application > can lift this limit), and only for webcams devices (screensharing has no > bandwidth limit). This is a chrome implementation detail, and not a > protocol limit. > > -While VP8 and H264 are both mandatory to implement (original IETF > discussion > ) > anybody can add any codec to webrtc as long as an RTP payload specificati= on > exists. > > -- Google chrome, and firefox, both supports real-time VP9 mode 2 (4:4:4, > 10 bits, HDR) > > > https://source.chromium.org/chromium/chromium/src/+/master:third_party/we= brtc/modules/video_coding/codecs/vp9/vp9_impl.cc;l=3D985 > > -- Chrome has a real-time AV1 implementation in webrtc, which goes up to > high profile (4:4:4, 8~10bits, HDR). > > > https://source.chromium.org/chromium/chromium/src/+/master:third_party/we= brtc/modules/video_coding/codecs/av1/ > > In terms of quality, only codecs at high profile (i.e. 12bits) can do > better, and none of those have a "real-time" version today. > > In terms of coding efficiency, AV1 is still the best codec available in > production. > > "WebRTC is not available in Safari and partially unavailable in Bowser an= d > Edge." > > - webrtc is fully available in Edge, and Safari. > > https://caniuse.com/#search=3Dwebrtc > > official daily W3C results: > https://wpt.fyi/results/?label=3Dmaster&label=3Dexperimental&aligned&q=3D= webrtc > > - Safari has added H.265 support in addition to the mandatory to implemen= t > VP8 and H..264 in the latest safari tech preview. > > > > I'm not going into the Discussion about webrtc's underlying RTC/RTCP > protocol and corresponding extension: NACK, RTX, FEC, RED, or Congestion > Control (REMB, Google-cc, BBR, NADA), as IETF members I'm sure you re all > aware of RFC3550 and all its derivatives. Many authors of those RFCs are > part of this group. > > > > Maybe more overlooked is the most recent Draft for end-to-end encryption > on top of webrtc co-authored by google: > > https://tools.ietf.org/html/draft-omara-sframe-00 > > > > I'm not saying that SRT is worse, or better than WebRTC.. I'm just saying= , > this comparison is not egregiously incorrect, and I'm a little bit > surprised that we are discussing marketing blogs that go in the face of s= o > many IETF specs. > > > > If anybody is interested in going deep into a real thorough comparison > between all those protocols, why not doing it during the IETF hackathon i= n > July, or in october (hopefully in BKK) just like we did group co-testing > with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF > hackathons? > > > > Regards, > > > > > > > > On Sat, Jun 13, 2020 at 6:58 PM Leslie Daigle > wrote: > > I thought this was a pretty interesting analysis: > > Low broadcast latency and protocols for implementation thereof: > > https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_impl= ementation_thereof > > Particularly telling is the chart at the end: WebRTC and SRT don=E2=80=99= t look > very similar, in this particular regard. > > Leslie. > > -- > ------------------------------ > > Leslie Daigle > Principal, ThinkingCat Enterprises > ldaigle@thinkingcat.com > > -- > Mops mailing list > Mops@ietf.org > https://www.ietf.org/mailman/listinfo/mops > > > > > -- > > Alex. Gouaillard, PhD, PhD, MBA > > > -------------------------------------------------------------------------= ----------- > > President - CoSMo Software Consulting, Singapore > > > -------------------------------------------------------------------------= ----------- > > sg.linkedin.com/agouaillard > > =C2=B7 > > -- > Mops mailing list > Mops@ietf.org > https://www.ietf.org/mailman/listinfo/mops > > > > > -- > > Alex. Gouaillard, PhD, PhD, MBA > > > -------------------------------------------------------------------------= ----------- > > President - CoSMo Software Consulting, Singapore > > > -------------------------------------------------------------------------= ----------- > > sg.linkedin.com/agouaillard > > =C2=B7 > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- President - CoSMo Software Consulting, Singapore ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --00000000000042620a05a8d4a29c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

I went around to the long time Hackatho= n attending IETF media guys and it looks like it's going to be too shor= t notice to prepare something for Madrid.
Between AV1 RTP payload and i= mplementation, the SVC extensions, the QuicTransport=C2=A0/ WebTransport , = and the End-To-End encryption for real-time media, everybody that would be = otherwise interested and capable to contribute is real busy.

=
However, I gathered sufficient interest for BKK (whether it will= be virtual or not), given the usual rules those people abide by are follow= ed. Since IETF does not have a set of proper rules nor a formal test suite,= those follow=C2=A0the rules that=C2=A0were used at IMTC superop events, pr= evious IETF Hackathon, W3C 's web-platform tests and/or AOMedia 's = testing working group. The usual IETF rules about the usage of MUST or SHOU= LD apply.
- Test cases must be discussed and defined early on, to= make sure the "everything else being equal" statement applies. T= he definition of starting point=C2=A0and end point of latency measurement f= or example varies a lot depending on the study.
- Test content (i= f any) must be defined and made publicly available to be able to independen= tly reproduce results.
- Test suite should be written in advance.= The same test suite should be used by all. The test code must be made publ= icly available to be able to independently reproduce results.
- I= f the need for specific test bed appears, e.g. controlled network, programm= atic packet loss / jitter / bandwidth variation, we should speak with the I= ETF network guys, and/or Charles E. to have that set up (in the case of a r= eal meeting), or for a common open source test infrastructure like e.g. KIT= E to be set up and made available.

We usually cons= ider it fair to provide 3 months to everyone after the first comparative re= sults are out, to try to optimize their implementations or address bugs fou= nd in the process, so that the results are representative of the capacity o= f a protocol, and not the deficiency of a given implementation. I don't= know if it makes sense to do this here, e.g. to have temporary results in = BKK, but give untill=C2=A0IETF 110 in Pragues to freeze the data, since SRT= is not an IETF protocol with fixed versions and revisions at this stage.

If this sounds reasonable to at least one of the ch= air, and from maxim or another SRT representative,=C2=A0I'm happy to fa= cilitate for IETF 109 the set up, bring enough IETF people and open source = media server people to the table to have critical mass of data and review, = and to facilitate the writing of a subsequent ID, in the same spirit we pub= lished a comparative study of open-source media webrtc media servers:
=



On Sun, Jun 14, 2020 at 10:05 PM Maxim Sharabayko &l= t;maxsharabayko@haivision.co= m> wrote:

Hi,

=C2=A0

The idea of performing the comparis= on is very exciting! I would be glad to participate as a delegate from SRT.=

=C2=A0

@Glen

It would be great if any SRT folks on this list= could do something similar,=C2=A0 to to mention those working with CMAF an= d LL HLS.

=C2=A0

There are of course some inaccuraci= es in the description of SRT.

The receiver buffer latency of 120 = ms is the default value, not the minimum. The minimum is 1 ms.

There is no limit of the number of = packet retransmissions, although the configurable limit might be added soon= .

HLS and DASH can be transmitted ove= r SRT. And so on.

=C2=A0

But in general even with these inac= curacies, the overview of the existing protocols on the market is quite goo= d.

=C2=A0

--=C2=A0

Regards,

Maxim Sharabayko<= /span>

Senior Software Developer | Hai= vision

=C2=A0

From: = Mops <mops-bounces@ietf.org>= ; on behalf of Alexandre GOUAILLARD <agouaillard@gmail.com>
Date: Sunday, 14. June 2020 at 01:28
To: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
Cc: Leslie Daigle <ldaigle@thinkingcat.com>, "mops@ietf.org" <mops@ietf.org>
Subject: Re: [Mops] Low latency protocol comparision

=C2=A0

@Deen, agreed.=C2=A0I gave it a try though a couple = of years back. Let me=C2=A0know if that would=C2=A0go in the right directio= n=C2=A0and I can update it with everything I learned in the mean time, and = taking into account the updates to the different protocols (e.g. new HLS informational draft by pantos):

=C2=A0

@Leslie, I volunteer every year, every hackathon :-)=

However, I am more knowledgeable about webrtc than o= ther protocols,=C2=A0so in that regard, I am biased.

I think to be fair=C2=A0each protocol should have a = reasonable=C2=A0representative/champion that at least validates that the te= sting protocol chosen is adequate, and garantees=C2=A0the accuracy and the = fairness of the result.

=C2=A0

For webrtc, it was problematic as well, as each brow= ser vendor did not want someone else to benchmark their=C2=A0implementation= , so we ended up with one representant=C2=A0of each browser vendor at 104 I= believe=C2=A0(pragues), to validate its result, and did it again in montreal:

if we manage to get the same setting, I think it cou= ld=C2=A0be very successful in=C2=A0getting=C2=A0fair and accurate results.<= u>

=C2=A0

I think we could handle the webrtc testing (as in wr= iting open source tests and providing results that would be deterministic a= nd independently=C2=A0verifiable=C2=A0by any and all).

- Maybe Veriskope, which is trying to push an RTMP 2= .0, could be interested in joining=C2=A0for RTMP.

- Magnus W for RTSP 2.0 ?

- Then we would need one volunteer for SRT,

- and another one for QUIC (maybe martin thompson ca= n point us in the right direction). QUIC is always the biggest table so it = should not be too difficult.

- Jonathan Lennox, chairman of AVTCORE is always aro= und and could help, especially on the congestion control, Error concealment= , and bandwidth adaptation part

- We could motivate EKR to comment on the security a= spects.

- I'm not sure if we want to asses IPv6 and NAT = traversal readiness (ICE)

=C2=A0

What do you think?

=C2=A0

Regards,=C2=A0

=C2=A0

Dr. Alex

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Jun 14, 2020 at 1:05 AM Deen, Glenn (NBCUniv= ersal) <Glenn= .Deen@nbcuni.com> wrote:

Yes, it=E2=80=99s a bit marketing, but it=E2=80=99s = also one of the few write ups that attempts to put the popular media transp= orts side by side for people to understand their strengths and abilities. = =C2=A0 The marketing blogs also give us, the IETF, insight into how the outside world of adopters and sellers of our work see things.=

=C2=A0

I really wish that all w= eb documents and pages contained a posting date. =C2=A0 This one doesn=E2= =80=99t gave it a date.=C2=A0 However, the=C2=A0page must be from at= least mid 2019 as it mentions things that were released then.

=C2=A0

I like your write up of the WebRTC inaccuracies.=C2= =A0 It would be great if any SRT folks on this list could do something simi= lar, =C2=A0to to mention those working with CMAF and LL HLS.=C2=A0 There a = lot of adopters out there who are working through what protocol best fits their particular needs - webRTC? =C2=A0 SRT?=C2=A0= Something that bright summer intern wrote while she was here last summer?= =C2=A0

=C2=A0

=C2=A0Capturing something like this, and even better= some sort of bake off as you suggest would be valuable to a lot of people.= =C2=A0 Though it may have to wait to get critical mass of participants unti= l next year.

=C2=A0

Glenn=C2=A0

=C2=A0

On Jun 13, 2020, at 3:3= 4 PM, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:

There are multiple inaccurate statements in the link= ed documents. Most of them that have been carried around for many years by = other SRT vendors like Wowza and already called out (here for example).

=C2=A0

I'm just going to point=C2=A0to three of the mos= t egregious=C2=A0(read "verifiably wrong") statements, that by th= emselves undermine the credibility of the entire document.

=C2=A0

- "Maximum supported resolution: 720p, 30 frame= s per second with a bit rate of up to 2 Mbps."
- There is no limit to the spatial and temporal resolution in webrtc/rtcweb= protocol.

Stadia for example send up to 4K@30fps.

=C2=A0

"WebRTC is inferior to its colleagues in terms = of the coding quality and maximum amount of transmitted data.=

- There is no limit to the bandwidth used in the web= rtc/rtcweb protocol.

- There is a limit of 2Mbps per peer connection on t= he sending-side only in the google chrome implementation, only by default (web appli= cation can lift this limit), and only for webcams devices (screensharing ha= s no bandwidth limit). This is a chrome implementation detail, and not a pr= otocol limit.

-While VP8 and H264 are both mandatory to implement = (original IETF discussion) anybody can add= any codec to webrtc as long as an RTP payload specification exists.

-- Google chrome, and firefox, both supports real-ti= me VP9 mode 2 (4:4:4, 10 bits, HDR)

-- Chrome has a real-time AV1 implementation in webr= tc, which goes up to high profile (4:4:4, 8~10bits, HDR).

In terms of quality, only codecs at high profile (i.= e. 12bits) can do better, and none of those have a "real-time" ve= rsion today.

In terms of coding efficiency, AV1 is still the best= codec available in production.

"WebRTC is not available in Safari and partially unavailable in Bowser= and Edge."

- webrtc is fully available in Edge, and Safari.<= /u>

- Safari has added H.265 support in addition to the = mandatory to implement VP8 and H..264 in the latest safari tech preview.=

=C2=A0

I'm not going into the Discussion about webrtc&#= 39;s underlying RTC/RTCP protocol and corresponding extension: NACK, RTX, F= EC, RED, or Congestion Control (REMB, Google-cc, BBR, NADA), as IETF member= s I'm sure you re all aware of RFC3550 and all its derivatives. Many authors of those RFCs are part of this group.=

=C2=A0

Maybe more overlooked is the most recent Draft for e= nd-to-end encryption on top of webrtc co-authored by google:<= /p>

=C2=A0

I'm not saying that SRT is worse, or better than= WebRTC.. I'm just saying, this comparison is not egregiously incorrect= , and I'm a little bit surprised that we are discussing marketing blogs= that go in the face of so many IETF specs.=C2=A0

=C2=A0

If anybody is interested in going deep into a real = =C2=A0thorough comparison between all those protocols, why not doing it dur= ing the IETF hackathon in July, or in october (hopefully in BKK) just like = we did group co-testing with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF hackathons?

=C2=A0

Regards,

=C2=A0

=C2=A0

=C2=A0

On Sat, Jun 13, 2020 at 6:58 PM Leslie Daigle <ldaigle@thinking= cat.com> wrote:

I thought this was a pretty= interesting analysis:

Low broadcast latency and p= rotocols for implementation thereof:
https://www.elecard.com/page/= low_broadcast_latency_and_protocols_for_implementation_thereof

Particularly telling is the= chart at the end: WebRTC and SRT don=E2=80=99t look very similar, in this = particular regard.

Leslie.

--

Leslie Daigle
Principal, ThinkingCat Enterprises

lda= igle@thinkingcat.com

--
Mops mailing list
Mops@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mops


=C2=A0

--

Alex. Gouaillard, PhD, PhD, MBA

----------------------------------------------------= --------------------------------

President - CoSMo Software Consulting, Singapore<= /u>

----------------------------------------------------= --------------------------------

=C2=B7 =C2=A0

--
Mops mailing list
Mops@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mops


=C2=A0

--

Alex. Gouaillard, PhD, PhD, MBA

----------------------------------------------------= --------------------------------

President - CoSMo Software Consulting, Singapore<= /u>

----------------------------------------------------= --------------------------------

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0



--
Alex. Gouaillard, PhD, PhD, MBA
-------------= -----------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
---------= ---------------------------------------------------------------------------=

--00000000000042620a05a8d4a29c-- From nobody Wed Jun 24 15:16:48 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0173A11B1 for ; Wed, 24 Jun 2020 15:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.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 wWnnaDra7WAe for ; Wed, 24 Jun 2020 15:16:43 -0700 (PDT) Received: from blue.elm.relay.mailchannels.net (blue.elm.relay.mailchannels.net [23.83.212.20]) (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 EE43D3A11B0 for ; Wed, 24 Jun 2020 15:16:42 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A7B581E04F7; Wed, 24 Jun 2020 22:16:41 +0000 (UTC) Received: from pdx1-sub0-mail-a41.g.dreamhost.com (100-96-27-16.trex.outbound.svc.cluster.local [100.96.27.16]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BABAF1E18B1; Wed, 24 Jun 2020 22:16:39 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from pdx1-sub0-mail-a41.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Wed, 24 Jun 2020 22:16:41 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|ldaigle@thinkingcat.com X-MailChannels-Auth-Id: dreamhost X-Society-Eight: 4b20dd7974e8269c_1593037001425_1502287063 X-MC-Loop-Signature: 1593037001425:1954891260 X-MC-Ingress-Time: 1593037001425 Received: from pdx1-sub0-mail-a41.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a41.g.dreamhost.com (Postfix) with ESMTP id 604E4B3812; Wed, 24 Jun 2020 15:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type; s=thinkingcat.com; bh=nRaED+QxjvUQB3mS5rAorVZzcY8 =; b=rgRv3VeAthJVk18qJFEQI3pJKcbMMS9J9mSlfZpxTq0HfDg2/7MQuM9NFFX hBdGfswjc1ZKXyUB/fYcPg7ngZy3+TyfsNw2D7ajCRkEdGToNSPFQNLhhzVv5lZp eT2li0o/fYZFwovof7x74ncv4+JL1rwVMWUik/30+Srw/RzM= Received: from [192.168.1.57] (vtelinet-216-66-102-83.vermontel.net [216.66.102.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ldaigle@thinkingcat.com) by pdx1-sub0-mail-a41.g.dreamhost.com (Postfix) with ESMTPSA id 5FFD9B3811; Wed, 24 Jun 2020 15:16:36 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a41 From: "Leslie Daigle" To: "Alexandre GOUAILLARD" Cc: "Maxim Sharabayko" , mops@ietf.org, "Deen, Glenn" Date: Wed, 24 Jun 2020 18:16:14 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <17635DFD-B536-4B22-8A5D-314BCBEFF19C@nbcuni.com> <7D14F27F-5914-46EC-9E27-9A61D3CEF820@haivision.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_A611659D-184A-447F-B367-095EE5AD2D8F_=" Embedded-HTML: [{"HTML":[824, 27040], "plain":[396, 13453], "uuid":"AE6BAA2A-F2AE-433A-8C46-20BD50B7A943"}] X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudekkedgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffoffkjghfgggtsegrtdhmreertdejnecuhfhrohhmpedfnfgvshhlihgvucffrghighhlvgdfuceolhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudeviedvffejiedvuedvtedtieeuueeuffdvuedvfedtueeiudfhuddugfefnecuffhomhgrihhnpehsvghmrghnthhitghstghhohhlrghrrdhorhhgpdifvggsrhhttggshigurhgrlhgvgidrtghomhdpihgvthhfrdhorhhgpdgthhhrohhmihhumhdrohhrghdptggrnhhiuhhsvgdrtghomhdpfihpthdrfhihihdpvghlvggtrghrugdrtghomhdplhhinhhkvgguihhnrdgtohhmnecukfhppedvudeirdeiiedruddtvddrkeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurdehjegnpdhinhgvthepvdduiedrieeirddutddvrdekfedprhgvthhurhhnqdhprghthhepfdfnvghslhhivgcuffgrihhglhgvfdcuoehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmqedpmhgrihhlfhhrohhmpehlug grihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmpdhnrhgtphhtthhopehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhm Archived-At: Subject: Re: [Mops] Low latency protocol comparision X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 22:16:46 -0000 --=_MailMate_A611659D-184A-447F-B367-095EE5AD2D8F_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Speaking as only one of the chairs of this group, I have to say I like = how this is shaping up. My only question is whether there is work to be done even at the IETF = 108 hackathon, in order to establish the test cases and test suite? Happy to hear from the other co-chair of this group :^) and any other = group participants. Leslie. On 24 Jun 2020, at 9:41, Alexandre GOUAILLARD wrote: > Dear all, > > I went around to the long time Hackathon attending IETF media guys and = > it > looks like it's going to be too short notice to prepare something for > Madrid. > Between AV1 RTP payload and implementation, the SVC extensions, the > QuicTransport / WebTransport , and the End-To-End encryption for = > real-time > media, everybody that would be otherwise interested and capable to > contribute is real busy. > > However, I gathered sufficient interest for BKK (whether it will be = > virtual > or not), given the usual rules those people abide by are followed. = > Since > IETF does not have a set of proper rules nor a formal test suite, = > those > follow the rules that were used at IMTC superop events, previous IETF > Hackathon, W3C 's web-platform tests and/or AOMedia 's testing working > group. The usual IETF rules about the usage of MUST or SHOULD apply. > - Test cases must be discussed and defined early on, to make sure the > "everything else being equal" statement applies. The definition of = > starting > point and end point of latency measurement for example varies a lot > depending on the study. > - Test content (if any) must be defined and made publicly available to = > be > able to independently reproduce results. > - Test suite should be written in advance. The same test suite should = > be > used by all. The test code must be made publicly available to be able = > to > independently reproduce results. > - If the need for specific test bed appears, e.g. controlled network, > programmatic packet loss / jitter / bandwidth variation, we should = > speak > with the IETF network guys, and/or Charles E. to have that set up (in = > the > case of a real meeting), or for a common open source test = > infrastructure > like e.g. KITE to be set up and made available. > > We usually consider it fair to provide 3 months to everyone after the = > first > comparative results are out, to try to optimize their implementations = > or > address bugs found in the process, so that the results are = > representative > of the capacity of a protocol, and not the deficiency of a given > implementation. I don't know if it makes sense to do this here, e.g. = > to > have temporary results in BKK, but give untill IETF 110 in Pragues to > freeze the data, since SRT is not an IETF protocol with fixed versions = > and > revisions at this stage. > > If this sounds reasonable to at least one of the chair, and from maxim = > or > another SRT representative, I'm happy to facilitate for IETF 109 the = > set > up, bring enough IETF people and open source media server people to = > the > table to have critical mass of data and review, and to facilitate the > writing of a subsequent ID, in the same spirit we published a = > comparative > study of open-source media webrtc media servers: > https://www.semanticscholar.org/paper/Comparative-Study-of-WebRTC-Open-= Source-SFUs-for-Andre-Breton/10b877cc13ffc9a1cabbf415cba73b22a1dd5442 > > Best regards, > > Dr. Alex. > > On Sun, Jun 14, 2020 at 10:05 PM Maxim Sharabayko < > maxsharabayko@haivision.com> wrote: > >> Hi, >> >> >> >> The idea of performing the comparison is very exciting! I would be = >> glad to >> participate as a delegate from SRT. >> >> >> >> @Glen >> >> *It would be great if any SRT folks on this list could do something >> similar, to to mention those working with CMAF and LL HLS.* >> >> >> >> There are of course some inaccuracies in the description of SRT. >> >> The receiver buffer latency of 120 ms is the default value, not the >> minimum. The minimum is 1 ms. >> >> There is no limit of the number of packet retransmissions, although = >> the >> configurable limit might be added soon. >> >> HLS and DASH can be transmitted over SRT. And so on. >> >> >> >> But in general even with these inaccuracies, the overview of the = >> existing >> protocols on the market is quite good. >> >> >> >> -- >> >> Regards, >> >> Maxim Sharabayko >> >> Senior Software Developer | Haivision >> >> >> >> *From: *Mops on behalf of Alexandre = >> GOUAILLARD < >> agouaillard@gmail.com> >> *Date: *Sunday, 14. June 2020 at 01:28 >> *To: *"Deen, Glenn (NBCUniversal)" >> *Cc: *Leslie Daigle , "mops@ietf.org" < >> mops@ietf.org> >> *Subject: *Re: [Mops] Low latency protocol comparision >> >> >> >> @Deen, agreed. I gave it a try though a couple of years back. Let me = >> know >> if that would go in the right direction and I can update it with = >> everything >> I learned in the mean time, and taking into account the updates to = >> the >> different protocols (e.g. new HLS informational draft by pantos): >> >> >> http://webrtcbydralex.com/index.php/2018/05/15/streaming-protocols-and= -ultra-low-latency-including-webrtc/ >> >> >> >> @Leslie, I volunteer every year, every hackathon :-) >> >> However, I am more knowledgeable about webrtc than other protocols, = >> so in >> that regard, I am biased. >> >> I think to be fair each protocol should have a >> reasonable representative/champion that at least validates that the = >> testing >> protocol chosen is adequate, and garantees the accuracy and the = >> fairness of >> the result. >> >> >> >> For webrtc, it was problematic as well, as each browser vendor did = >> not >> want someone else to benchmark their implementation, so we ended up = >> with >> one representant of each browser vendor at 104 I believe (pragues), = >> to >> validate its result, and did it again in montreal: >> >> https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon/webrtc >> >> if we manage to get the same setting, I think it could be very = >> successful >> in getting fair and accurate results. >> >> >> >> I think we could handle the webrtc testing (as in writing open source >> tests and providing results that would be deterministic and >> independently verifiable by any and all). >> >> - Maybe Veriskope, which is trying to push an RTMP 2.0, could be >> interested in joining for RTMP. >> >> - Magnus W for RTSP 2.0 ? >> >> - Then we would need one volunteer for SRT, >> >> - and another one for QUIC (maybe martin thompson can point us in the >> right direction). QUIC is always the biggest table so it should not = >> be too >> difficult. >> >> - Jonathan Lennox, chairman of AVTCORE is always around and could = >> help, >> especially on the congestion control, Error concealment, and = >> bandwidth >> adaptation part >> >> - We could motivate EKR to comment on the security aspects. >> >> - I'm not sure if we want to asses IPv6 and NAT traversal readiness = >> (ICE) >> >> >> >> What do you think? >> >> >> >> Regards, >> >> >> >> Dr. Alex >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Sun, Jun 14, 2020 at 1:05 AM Deen, Glenn (NBCUniversal) < >> Glenn.Deen@nbcuni.com> wrote: >> >> Yes, it=E2=80=99s a bit marketing, but it=E2=80=99s also one of the fe= w write ups = >> that >> attempts to put the popular media transports side by side for people = >> to >> understand their strengths and abilities. The marketing blogs also = >> give >> us, the IETF, insight into how the outside world of adopters and = >> sellers of >> our work see things. >> >> >> >> I really wish that all web documents and pages contained a posting = >> date. >> This one doesn=E2=80=99t gave it a date. However, the page must be fr= om at = >> least >> mid 2019 as it mentions things that were released then. >> >> >> >> I like your write up of the WebRTC inaccuracies. It would be great = >> if any >> SRT folks on this list could do something similar, to to mention = >> those >> working with CMAF and LL HLS. There a lot of adopters out there who = >> are >> working through what protocol best fits their particular needs - = >> webRTC? >> SRT? Something that bright summer intern wrote while she was here = >> last >> summer? >> >> >> >> Capturing something like this, and even better some sort of bake off = >> as >> you suggest would be valuable to a lot of people. Though it may have = >> to >> wait to get critical mass of participants until next year. >> >> >> >> Glenn >> >> >> >> On Jun 13, 2020, at 3:34 PM, Alexandre GOUAILLARD = >> >> wrote: >> >> There are multiple inaccurate statements in the linked documents. = >> Most of >> them that have been carried around for many years by other SRT = >> vendors like >> Wowza and already called out (here >> >> for example). >> >> >> >> I'm just going to point to three of the most egregious (read = >> "verifiably >> wrong") statements, that by themselves undermine the credibility of = >> the >> entire document. >> >> >> >> - "Maximum supported resolution: 720p, 30 frames per second with a = >> bit >> rate of up to 2 Mbps." >> - There is no limit to the spatial and temporal resolution in >> webrtc/rtcweb protocol. >> >> Stadia for example send up to 4K@30fps. >> >> >> >> "WebRTC is inferior to its colleagues in terms of the coding quality = >> and >> maximum amount of transmitted data. >> >> - There is no limit to the bandwidth used in the webrtc/rtcweb = >> protocol. >> >> - There is a limit of 2Mbps per peer connection on the sending-side = >> *only >> in the google chrome implementation*, only by default (web = >> application >> can lift this limit), and only for webcams devices (screensharing has = >> no >> bandwidth limit). This is a chrome implementation detail, and not a >> protocol limit. >> >> -While VP8 and H264 are both mandatory to implement (original IETF >> discussion >> ) >> anybody can add any codec to webrtc as long as an RTP payload = >> specification >> exists. >> >> -- Google chrome, and firefox, both supports real-time VP9 mode 2 = >> (4:4:4, >> 10 bits, HDR) >> >> >> https://source.chromium.org/chromium/chromium/src/+/master:third_party= /webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc;l=3D985 >> >> -- Chrome has a real-time AV1 implementation in webrtc, which goes up = >> to >> high profile (4:4:4, 8~10bits, HDR). >> >> >> https://source.chromium.org/chromium/chromium/src/+/master:third_party= /webrtc/modules/video_coding/codecs/av1/ >> >> In terms of quality, only codecs at high profile (i.e. 12bits) can do >> better, and none of those have a "real-time" version today. >> >> In terms of coding efficiency, AV1 is still the best codec available = >> in >> production. >> >> "WebRTC is not available in Safari and partially unavailable in = >> Bowser and >> Edge." >> >> - webrtc is fully available in Edge, and Safari. >> >> https://caniuse.com/#search=3Dwebrtc >> >> official daily W3C results: >> https://wpt.fyi/results/?label=3Dmaster&label=3Dexperimental&aligned&q= =3Dwebrtc >> >> - Safari has added H.265 support in addition to the mandatory to = >> implement >> VP8 and H..264 in the latest safari tech preview. >> >> >> >> I'm not going into the Discussion about webrtc's underlying RTC/RTCP >> protocol and corresponding extension: NACK, RTX, FEC, RED, or = >> Congestion >> Control (REMB, Google-cc, BBR, NADA), as IETF members I'm sure you re = >> all >> aware of RFC3550 and all its derivatives. Many authors of those RFCs = >> are >> part of this group. >> >> >> >> Maybe more overlooked is the most recent Draft for end-to-end = >> encryption >> on top of webrtc co-authored by google: >> >> https://tools.ietf.org/html/draft-omara-sframe-00 >> >> >> >> I'm not saying that SRT is worse, or better than WebRTC.. I'm just = >> saying, >> this comparison is not egregiously incorrect, and I'm a little bit >> surprised that we are discussing marketing blogs that go in the face = >> of so >> many IETF specs. >> >> >> >> If anybody is interested in going deep into a real thorough = >> comparison >> between all those protocols, why not doing it during the IETF = >> hackathon in >> July, or in october (hopefully in BKK) just like we did group = >> co-testing >> with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RMCAT during the previous IETF >> hackathons? >> >> >> >> Regards, >> >> >> >> >> >> >> >> On Sat, Jun 13, 2020 at 6:58 PM Leslie Daigle = >> >> wrote: >> >> I thought this was a pretty interesting analysis: >> >> Low broadcast latency and protocols for implementation thereof: >> >> https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_i= mplementation_thereof >> >> Particularly telling is the chart at the end: WebRTC and SRT don=E2=80= =99t = >> look >> very similar, in this particular regard. >> >> Leslie. >> >> -- >> ------------------------------ >> >> Leslie Daigle >> Principal, ThinkingCat Enterprises >> ldaigle@thinkingcat.com >> >> -- >> Mops mailing list >> Mops@ietf.org >> https://www.ietf.org/mailman/listinfo/mops >> >> >> >> >> -- >> >> Alex. Gouaillard, PhD, PhD, MBA >> >> >> ----------------------------------------------------------------------= -------------- >> >> President - CoSMo Software Consulting, Singapore >> >> >> ----------------------------------------------------------------------= -------------- >> >> sg.linkedin.com/agouaillard >> >> =C2=B7 >> >> -- >> Mops mailing list >> Mops@ietf.org >> https://www.ietf.org/mailman/listinfo/mops >> >> >> >> >> -- >> >> Alex. Gouaillard, PhD, PhD, MBA >> >> >> ----------------------------------------------------------------------= -------------- >> >> President - CoSMo Software Consulting, Singapore >> >> >> ----------------------------------------------------------------------= -------------- >> >> sg.linkedin.com/agouaillard >> >> =C2=B7 >> > > > -- = > Alex. Gouaillard, PhD, PhD, MBA > -----------------------------------------------------------------------= ------------- > President - CoSMo Software Consulting, Singapore > -----------------------------------------------------------------------= ------------- > sg.linkedin.com/agouaillard > > - > -- = > Mops mailing list > Mops@ietf.org > https://www.ietf.org/mailman/listinfo/mops -- = ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- --=_MailMate_A611659D-184A-447F-B367-095EE5AD2D8F_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

Speaking as only one of the chairs of this group, I have = to say I like how this is shaping up.

My only question is whether there is work to be done even= at the IETF 108 hackathon, in order to establish the test cases and test= suite?

Happy to hear from the other co-chair of this group :^) a= nd any other group participants.

Leslie.

On 24 Jun 2020, at 9:41, Alexandre GOUAILLARD wrote:

Dear all,

I went around to the long time Hackathon= attending IETF media guys and it looks like it's going to be too sho= rt notice to prepare something for Madrid.
Between AV1 RTP payload an= d implementation, the SVC extensions, the QuicTransport=C2=A0/ WebTranspo= rt , and the End-To-End encryption for real-time media, everybody that wo= uld be otherwise interested and capable to contribute is real busy.
=

However, I gathered sufficient interest for BKK (whet= her it will be virtual or not), given the usual rules those people abide = by are followed. Since IETF does not have a set of proper rules nor a for= mal test suite, those follow=C2=A0the rules that=C2=A0were used at IMTC s= uperop events, previous IETF Hackathon, W3C 's web-platform tests and= /or AOMedia 's testing working group. The usual IETF rules about the = usage of MUST or SHOULD apply.
- Test cases must be discussed a= nd defined early on, to make sure the "everything else being equal&q= uot; statement applies. The definition of starting point=C2=A0and end poi= nt of latency measurement for example varies a lot depending on the study= =2E
- Test content (if any) must be defined and made publicly a= vailable to be able to independently reproduce results.
- Test = suite should be written in advance. The same test suite should be used by= all. The test code must be made publicly available to be able to indepen= dently reproduce results.
- If the need for specific test bed a= ppears, e.g. controlled network, programmatic packet loss / jitter / band= width variation, we should speak with the IETF network guys, and/or Charl= es E. to have that set up (in the case of a real meeting), or for a commo= n open source test infrastructure like e.g. KITE to be set up and made av= ailable.

We usually consider it fair to provide = 3 months to everyone after the first comparative results are out, to try = to optimize their implementations or address bugs found in the process, s= o that the results are representative of the capacity of a protocol, and = not the deficiency of a given implementation. I don't know if it make= s sense to do this here, e.g. to have temporary results in BKK, but give = untill=C2=A0IETF 110 in Pragues to freeze the data, since SRT is not an I= ETF protocol with fixed versions and revisions at this stage.
<= br>
If this sounds reasonable to at least one of the chair, and= from maxim or another SRT representative,=C2=A0I'm happy to facilita= te for IETF 109 the set up, bring enough IETF people and open source medi= a server people to the table to have critical mass of data and review, an= d to facilitate the writing of a subsequent ID, in the same spirit we pub= lished a comparative study of open-source media webrtc media servers:

Best regards,

Dr. Alex.

<= div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 14, 2020 at 10:05 PM Max= im Sharabayko <maxshara= bayko@haivision.com> wrote:

Hi,

=C2=A0

=

The idea of performing the comp= arison is very exciting! I would be glad to participate as a delegate fro= m SRT.

=C2=A0

=

@Glen

It would be great if any SRT folks on this = list could do something similar,=C2=A0 to to mention those working with C= MAF and LL HLS.

=C2=A0

There are of course some inaccu= racies in the description of SRT.

The receiver buffer latency of = 120 ms is the default value, not the minimum. The minimum is 1 ms.=

There is no limit of the number= of packet retransmissions, although the configurable limit might be adde= d soon..

HLS and DASH can be transmitted= over SRT. And so on.

=C2=A0

=

But in general even with these = inaccuracies, the overview of the existing protocols on the market is qui= te good.

=C2=A0

=

--=C2=A0

Regards,=

Maxim Sharabayko

Senior Software Developer | H= aivision

=C2=A0

From= : Mops <mops-bounces@ietf.org> on behalf of Alexandre GOUAILLARD <agouaillard@gmail.com>
Date: Sunday, 14. June 2020 at 01:28
To: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
= Cc: Leslie Daigle <ldaigle@thinkingcat.com>, "mops@ietf.org" <mops@ietf.org>
Subject: Re: [Mops] Low latency protocol comparision=

=C2=A0

@Deen, agreed.=C2=A0I gave it a try though a coupl= e of years back. Let me=C2=A0know if that would=C2=A0go in the right dire= ction=C2=A0and I can update it with everything I learned in the mean time= , and taking into account the updates to the different protocols (e.g. new HLS informational draft by pantos):

=C2=A0

@Leslie, I volunteer every year, every hackathon := -)

However, I am more knowledgeable about webrtc than= other protocols,=C2=A0so in that regard, I am biased.

I think to be fair=C2=A0each protocol should have = a reasonable=C2=A0representative/champion that at least validates that th= e testing protocol chosen is adequate, and garantees=C2=A0the accuracy an= d the fairness of the result.

=C2=A0

For webrtc, it was problematic as well, as each br= owser vendor did not want someone else to benchmark their=C2=A0implementa= tion, so we ended up with one representant=C2=A0of each browser vendor at= 104 I believe=C2=A0(pragues), to validate its result, and did it again in montreal:

if we manage to get the same setting, I think it c= ould=C2=A0be very successful in=C2=A0getting=C2=A0fair and accurate resul= ts.

=C2=A0

I think we could handle the webrtc testing (as in = writing open source tests and providing results that would be determinist= ic and independently=C2=A0verifiable=C2=A0by any and all).<= /p>

- Maybe Veriskope, which is trying to push an RTMP= 2..0, could be interested in joining=C2=A0for RTMP.

- Magnus W for RTSP 2.0 ?

- Then we would need one volunteer for SRT,=

- and another one for QUIC (maybe martin thompson = can point us in the right direction). QUIC is always the biggest table so= it should not be too difficult.

- Jonathan Lennox, chairman of AVTCORE is always a= round and could help, especially on the congestion control, Error conceal= ment, and bandwidth adaptation part

- We could motivate EKR to comment on the security= aspects.

- I'm not sure if we want to asses IPv6 and NA= T traversal readiness (ICE)

=C2=A0

What do you think?

=C2=A0

Regards,=C2=A0

=C2=A0

Dr. Alex

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Jun 14, 2020 at 1:05 AM Deen, Glenn (NBCUn= iversal) <G= lenn..Deen@nbcuni.com> wrote:

Yes, it=E2=80=99s a bit marketing, but it=E2=80=99= s also one of the few write ups that attempts to put the popular media tr= ansports side by side for people to understand their strengths and abilit= ies. =C2=A0 The marketing blogs also give us, the IETF, insight into how the outside world of adopters and sellers of our work see thing= s.

=C2=A0

I really wish that all= web documents and pages contained a posting date. =C2=A0 This one doesn=E2= =80=99t gave it a date.=C2=A0 However, the=C2=A0page must be from = at least mid 2019 as it mentions things that were released then.

=C2=A0

I like your write up of the WebRTC inaccuracies.=C2= =A0 It would be great if any SRT folks on this list could do something si= milar, =C2=A0to to mention those working with CMAF and LL HLS.=C2=A0 Ther= e a lot of adopters out there who are working through what protocol best fits their particular needs - webRTC? =C2=A0 SRT?=C2=A0= Something that bright summer intern wrote while she was here last summer= ?=C2=A0

=C2=A0

=C2=A0Capturing something like this, and even bett= er some sort of bake off as you suggest would be valuable to a lot of peo= ple.=C2=A0 Though it may have to wait to get critical mass of participant= s until next year.

=C2=A0

Glenn=C2=A0

=C2=A0

On Jun 13, 2020, at 3= :34 PM, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:

=

There are multiple inaccurate statements in the li= nked documents. Most of them that have been carried around for many years= by other SRT vendors like Wowza and already called out (here for example).

=C2=A0

I'm just going to point=C2=A0to three of the m= ost egregious=C2=A0(read "verifiably wrong") statements, that b= y themselves undermine the credibility of the entire document.<= /u>

=C2=A0

- "Maximum supported resolution: 720p, 30 fra= mes per second with a bit rate of up to 2 Mbps."
- There is no limit to the spatial and temporal resolution in webrtc/rtcw= eb protocol.

Stadia for example send up to 4K@30fps.<= /u>

=C2=A0

"WebRTC is inferior to its colleagues in term= s of the coding quality and maximum amount of transmitted data.=

- There is no limit to the bandwidth used in the w= ebrtc/rtcweb protocol.

- There is a limit of 2Mbps per peer connection on= the sending-side only in the google chrome implementation, only by default (web app= lication can lift this limit), and only for webcams devices (screensharin= g has no bandwidth limit). This is a chrome implementation detail, and no= t a protocol limit.

-While VP8 and H264 are both mandatory to implemen= t (original IETF discussion) anybody c= an add any codec to webrtc as long as an RTP payload specification exists.

-- Google chrome, and firefox, both supports real-= time VP9 mode 2 (4:4:4, 10 bits, HDR)

-- Chrome has a real-time AV1 implementation in we= brtc, which goes up to high profile (4:4:4, 8~10bits, HDR).=

In terms of quality, only codecs at high profile (= i.e. 12bits) can do better, and none of those have a "real-time"= ; version today.

In terms of coding efficiency, AV1 is still the be= st codec available in production.

"WebRTC is not available in Safari and partially unavailable in Bows= er and Edge."

- webrtc is fully available in Edge, and Safari.

- Safari has added H.265 support in addition to th= e mandatory to implement VP8 and H..264 in the latest safari tech preview= =2E

=C2=A0

I'm not going into the Discussion about webrtc= 's underlying RTC/RTCP protocol and corresponding extension: NACK, RT= X, FEC, RED, or Congestion Control (REMB, Google-cc, BBR, NADA), as IETF = members I'm sure you re all aware of RFC3550 and all its derivatives. Many authors of those RFCs are part of this group.<= u>

=C2=A0

Maybe more overlooked is the most recent Draft for= end-to-end encryption on top of webrtc co-authored by google:<= /u>

=C2=A0

I'm not saying that SRT is worse, or better th= an WebRTC.. I'm just saying, this comparison is not egregiously incor= rect, and I'm a little bit surprised that we are discussing marketing= blogs that go in the face of so many IETF specs.=C2=A0

=

=C2=A0

If anybody is interested in going deep into a real= =C2=A0thorough comparison between all those protocols, why not doing it = during the IETF hackathon in July, or in october (hopefully in BKK) just = like we did group co-testing with IETF's AVTCORE/AVEXT/QUIC/RTCWEB/RM= CAT during the previous IETF hackathons?

=C2=A0

Regards,

=C2=A0

=C2=A0

=C2=A0

On Sat, Jun 13, 2020 at 6:58 PM Leslie Daigle <= ldaigle@thin= kingcat.com> wrote:

I thought this was a pret= ty interesting analysis:

Low broadcast latency and= protocols for implementation thereof:
https://www.elecard.com= /page/low_broadcast_latency_and_protocols_for_implementation_thereof<= /p>

Particularly telling is t= he chart at the end: WebRTC and SRT don=E2=80=99t look very similar, in t= his particular regard.

Leslie.

-- <= /p>

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com

--
Mops mailing list
Mops@ietf.org
= https://www.ietf.org/mailman/listinfo/mops


=C2=A0

--

Alex. Gouaillard, PhD, PhD, MBA

=

--------------------------------------------------= ----------------------------------

President - CoSMo Software Consulting, Singapore

--------------------------------------------------= ----------------------------------

=C2=B7 =C2=A0

--
Mops mailing list
Mops@ietf.org
= https://www.ietf.org/mailman/listinfo/mops


=C2=A0

--

Alex. Gouaillard, PhD, PhD, MBA

--------------------------------------------------= ----------------------------------

President - CoSMo Software Consulting, Singapore

--------------------------------------------------= ----------------------------------

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0



--
Alex. Gouaillard, PhD, PhD, MBA
--------= -------------------------------------------------------------------------= ---
President - CoSMo Software Consulting, Singapore
= -------------------------------------------------------------------------= -----------

--
Mops mailing list
Mops@ietf.org
https://www.ietf.org/mailman/listinfo/mops

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com

--=_MailMate_A611659D-184A-447F-B367-095EE5AD2D8F_=-- From nobody Wed Jun 24 15:37:55 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146963A11BD for ; Wed, 24 Jun 2020 15:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 4te7zzJQP7qQ for ; Wed, 24 Jun 2020 15:37:52 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7190C3A11BC for ; Wed, 24 Jun 2020 15:37:52 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id d64so938755vke.4 for ; Wed, 24 Jun 2020 15:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ybtcujhPqgm8zHPKv9xrcQeggPJMuhczP99wJQW9sU=; b=dh1Q6MTo3XdHuL8UVHsiIADe5Yn08VMSpa7E25vse+i7UORTTSO1pJNuUbr74hvf72 6EL2adB7Sua9lJ4WbtHWLu+JsNF5DlX7d8royNkd4DPI1Q6KW+U23yZJVBNvSrQMrBoY rj65JB6wMwWWkPlSkX+y0O5NN3/QDaXOHMiIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ybtcujhPqgm8zHPKv9xrcQeggPJMuhczP99wJQW9sU=; b=Su/2OnR4uDpTAbxcd+2YtFGrEhQinBA3FktbuI3DgYq/c3dLRCJWH8NCUhDmPmRE0E 7820jVMdP1banvIocFYKybc0uDcqzyvTiQrriqJHDdE3c4Glqz0kh2anWaqAAR/J1QNz GZJM6V0I7yAQrwyThrj4+gJQzGrtO6yCvFu+wXSFBQllbIIXDfSlr6eP2dr1BCYtmlUE 5+8dWbs7O+XYEimUAk7kCvZJ8SLZa0o+T5h7YAY64Nnl9zmwJ3n5vfK340jMia5kUMT7 On6fVutQ/iuqAWOfGmELtcgVQD41Mpyll0fgMitnrj0Hk5WRfQFU302GGJIPW/tsc8/U chyA== X-Gm-Message-State: AOAM5333H/1tFblF+0eFSHCnzjkXwG8dxWgX4OjMg3gDzmpWZ22vmHzq 3JlrSMgTLiKBYysCMPDx9+NeTVX4j0APRCoYjCbcog== X-Google-Smtp-Source: ABdhPJyf3lxDzEJiiB7PwWVJFciZoNPniuFuNfnZeERpUQd/V0qiQ5Q5FyOKyX3S8IlqWrkGVCRJfQnrBlDdCUSiaWM= X-Received: by 2002:a1f:4185:: with SMTP id o127mr24489553vka.45.1593038271268; Wed, 24 Jun 2020 15:37:51 -0700 (PDT) MIME-Version: 1.0 References: <17635DFD-B536-4B22-8A5D-314BCBEFF19C@nbcuni.com> <7D14F27F-5914-46EC-9E27-9A61D3CEF820@haivision.com> In-Reply-To: From: Kyle Rose Date: Wed, 24 Jun 2020 18:37:40 -0400 Message-ID: To: Leslie Daigle Cc: Alexandre GOUAILLARD , "Deen, Glenn" , mops@ietf.org, Maxim Sharabayko Content-Type: multipart/alternative; boundary="00000000000045db9c05a8dc2009" Archived-At: Subject: Re: [Mops] Low latency protocol comparision X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 22:37:54 -0000 --00000000000045db9c05a8dc2009 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 24, 2020 at 6:16 PM Leslie Daigle wrote: > Hi, > > Speaking as only one of the chairs of this group, I have to say I like how > this is shaping up. > > My only question is whether there is work to be done even at the IETF 108 > hackathon, in order to establish the test cases and test suite? > > Happy to hear from the other co-chair of this group :^) and any other > group participants. > Heh... As the other co-chair, Leslie and I are in alignment on this. If there's prep work to be done at the 108 hackathon, great! If not, BKK (or, likely, the virtual replacement for it) sounds like a plan. Even if we don't do anything at the 108 hackathon, there's probably a bit of prep we'll want to do prior to the 109 hackathon, including coordinating with Charles on any special network setup we might need should the meeting be held in person. Kyle --00000000000045db9c05a8dc2009 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 24, 2020 at 6:16 PM Leslie Daigle <ldaigle@thinkingcat.com> wrote:
<= /div>

Hi,

Speaking as only one of the chairs of this group, I have to= say I like how this is shaping up.

My only question is whether there is work to be done even a= t the IETF 108 hackathon, in order to establish the test cases and test sui= te?

Happy to hear from the other co-chair of this group :^) and= any other group participants.


Heh... =C2=A0<= span class=3D"gmail_default" style=3D"font-size:small">As the other co-chai= r, Leslie and I are in alignment on this. If there's prep work to be do= ne at the 108 hackathon, great! If not, BKK (or, likely, the virtual replac= ement for it) sounds like a plan. Even if we don't do anything at the 1= 08 hackathon, there's probably a bit of prep we'll want to do prior= to the 109 hackathon, including coordinating with Charles on any special n= etwork setup we might need should the meeting be held in person.
=

Kyle<= /span>
--00000000000045db9c05a8dc2009-- From nobody Thu Jun 25 15:44:08 2020 Return-Path: X-Original-To: mops@ietfa.amsl.com Delivered-To: mops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C193A104E for ; Thu, 25 Jun 2020 15:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.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 0KlsWpuF6KZS for ; Thu, 25 Jun 2020 15:44:05 -0700 (PDT) Received: from dog.birch.relay.mailchannels.net (dog.birch.relay.mailchannels.net [23.83.209.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD093A104D for ; Thu, 25 Jun 2020 15:44:04 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6669F360407; Thu, 25 Jun 2020 22:44:03 +0000 (UTC) Received: from pdx1-sub0-mail-a14.g.dreamhost.com (100-96-1-7.trex.outbound.svc.cluster.local [100.96.1.7]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BF70D36153B; Thu, 25 Jun 2020 22:44:02 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com Received: from pdx1-sub0-mail-a14.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Thu, 25 Jun 2020 22:44:03 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|ldaigle@thinkingcat.com X-MailChannels-Auth-Id: dreamhost X-Bottle-Reaction: 4989b5514fcd7602_1593125043210_1588628321 X-MC-Loop-Signature: 1593125043210:202364987 X-MC-Ingress-Time: 1593125043210 Received: from pdx1-sub0-mail-a14.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a14.g.dreamhost.com (Postfix) with ESMTP id 4B227A3B4B; Thu, 25 Jun 2020 15:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=thinkingcat.com; bh=U90WsQ1q4LHen0 egjpAYvPQQ8aA=; b=pttKWbcFCTVHw680pxfY9V+QG9T0L7a8Ix/ujpBPal2YQA 2BdkEyM43G3jQq+OUcisbsshRXfeCm0tygqNEIF65qBRFpCyJgPg73vrWB9x7o/E qzm724Khf62fgWFYRhMx4/Dl2pv4VcWmqoB39G/l1JCkT83bKjbAwAT50hw+A= Received: from [192.168.1.57] (vtelinet-216-66-102-83.vermontel.net [216.66.102.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ldaigle@thinkingcat.com) by pdx1-sub0-mail-a14.g.dreamhost.com (Postfix) with ESMTPSA id ABE2F863F8; Thu, 25 Jun 2020 15:44:01 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a14 From: "Leslie Daigle" To: mops@ietf.org Date: Thu, 25 Jun 2020 18:43:38 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <4D417610-EEEF-4920-8440-930CD3D3EDDD@thinkingcat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_3E7F18E9-05C6-44D9-B0DB-A5B9B81AAFAC_=" X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeltddguddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffokfggtgfgsegrkehmreertdejnecuhfhrohhmpedfnfgvshhlihgvucffrghighhlvgdfuceolhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomheqnecuggftrfgrthhtvghrnhepudeuleekuedugeelieduvdfggffgjeekteeiteetveevffekjeeuudfhuefguddvnecukfhppedvudeirdeiiedruddtvddrkeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurdehjegnpdhinhgvthepvdduiedrieeirddutddvrdekfedprhgvthhurhhnqdhprghthhepfdfnvghslhhivgcuffgrihhglhgvfdcuoehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmqedpmhgrihhlfhhrohhmpehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmpdhnrhgtphhtthhopehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhm Content-Transfer-Encoding: 7bit Archived-At: Subject: [Mops] DRAFT agenda for our IETF 108 session X-BeenThere: mops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Media OPerationS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 22:44:07 -0000 --=_MailMate_3E7F18E9-05C6-44D9-B0DB-A5B9B81AAFAC_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Hi, This is what we have so far by way of agenda =E2=80=94 thoughts/additions= ? It=20 will be just a 50min session. DRAFT Media OPerationS (MOPS) WG IETF 108 (Virtual) DRAFT Agenda Intro Agenda Bashing, Blue Sheets, etc, [5min] chair(s) Review of concrete work items: [10min] Draft of edge network operational considerations for streaming=20 media Jake Holland draft-ietf-mops-streaming-opcons Updates from other work [20min] =E2=80=9CBest Practices for the End-to-End Workflow Monitoring=E2= =80=9D from=20 SVA QoE WG Chris Kulbakas General discussion of issues Operational Issues Observed [10min] Update on/for/from Hackathon comparative study of media=20 transport protocols Dr. Alex Gouaillard AOB Leslie. --=20 ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- --=_MailMate_3E7F18E9-05C6-44D9-B0DB-A5B9B81AAFAC_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

This is what we have so far by way of agenda =E2=80=94 th= oughts/additions? It will be just a 50min session.

DRAFT

Media OPerationS (MOPS) WG

IETF 108 (Virtual)
<Date =E2=80=94 TBD>
<Location =E2=80=94 TBD>
DRAFT Agenda

Intro

Agenda Bashing, Blue Sheets, etc,
[5min] chair(s)

Review of concrete work items:

[10min] Draft of edge network operational considerations = for streaming media
Jake Holland
draft-ietf-mops-streaming-opcons

Updates from other work
[20min] =E2=80=9CBest Practices for the End-to-End Workflow Monitoring=E2= =80=9D from SVA QoE WG
Chris Kulbakas

General discussion of issues
<tbd>

Operational Issues Observed
<tbd>

[10min] Update on/for/from Hackathon comparative study of= media transport protocols
Dr. Alex Gouaillard

AOB

Leslie.

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com

--=_MailMate_3E7F18E9-05C6-44D9-B0DB-A5B9B81AAFAC_=--