From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Sebastian Moeller <moeller0@gmx.de>
CC: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>,
 "tsvwg@ietf.org" <tsvwg@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>,
 "iccrg@irtf.org" <iccrg@irtf.org>, "koen.de_schepper@nokia.com"
 <koen.de_schepper@nokia.com>, "Bob Briscoe (ietf@bobbriscoe.net)"
 <ietf@bobbriscoe.net>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] L4S related activity in 3GPP
Thread-Index: AdWXFU/rHJiyQelDTIOgP97lGH/97gAC6dQAAAPywbAAAzRNAAAcmkTA
Date: Sun, 10 Nov 2019 10:20:11 +0000
Message-ID: <HE1PR07MB4425ECE1C3883C6D200AE3A3C2750@HE1PR07MB4425.eurprd07.prod.outlook.com>
References: <HE1PR07MB4425A148B5BB1E6FD8E5A3FBC27A0@HE1PR07MB4425.eurprd07.prod.outlook.com>
 <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>
 <HE1PR07MB4425DD6FE15DB130B24BCEA1C27A0@HE1PR07MB4425.eurprd07.prod.outlook.com>
 <DBE43199-0BFB-464B-8045-919C975397AC@gmx.de>
In-Reply-To: <DBE43199-0BFB-464B-8045-919C975397AC@gmx.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: ericsson.com does not designate
 permitted sender hosts)
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
 micalg=SHA1; boundary="----=_NextPart_000_011A_01D597B8.D0AFB390"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8aa7e8b6-4eab-4247-91a1-08d765c79226
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2019 10:20:12.0083 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nMDEkez/G5XSLVZHMpY/zZqfY76s2a08ZLKIco/MBQRAn6I9ky8hira+M7wzfPaUZ+DCyRPVTdVtDgUgrWwQtuMQUTo8pAKLkErVzrhFztQzIrHsV20pEZ4/gZwvCq+P
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3083
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/kQ-vrJzcn9DoCSvIdSDHNeslDAg>
Subject: Re: [tsvwg] L4S related activity in 3GPP
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>,
 <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>,
 <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Nov 2019 10:20:20 -0000

------=_NextPart_000_011A_01D597B8.D0AFB390
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Sebastian
Please see inline

/Ingemar

> -----Original Message-----
> From: Sebastian Moeller <moeller0@gmx.de>
> Sent: den 9 november 2019 21:38
> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> Cc: Ingemar Johansson S
> <ingemar.s.johansson=3D40ericsson.com@dmarc.ietf.org>; tsvwg@ietf.org;
> tcpm@ietf.org; iccrg@irtf.org; koen.de_schepper@nokia.com; Bob Briscoe
> (ietf@bobbriscoe.net) <ietf@bobbriscoe.net>
> Subject: Re: [tsvwg] L4S related activity in 3GPP
>=20
> Dear Ingemar,
>=20
> more in-line below.
>=20
> > On Nov 9, 2019, at 20:24, Ingemar Johansson S
> <ingemar.s.johansson@ericsson.com> wrote:
> >
> > Hi Sebastian
> >
> > Please see inline below
> > /Ingemar
> >
> >> -----Original Message-----
> >> From: Sebastian Moeller <moeller0@gmx.de>
> >> Sent: den 9 november 2019 18:13
> >> To: Ingemar Johansson S
> >> <ingemar.s.johansson=3D40ericsson.com@dmarc.ietf.org>
> >> Cc: tsvwg@ietf.org; tcpm@ietf.org; iccrg@irtf.org; Ingemar =
Johansson
> >> S <ingemar.s.johansson@ericsson.com>; koen.de_schepper@nokia.com
> >> Subject: Re: [tsvwg] L4S related activity in 3GPP
> >>
> >> Dear Ingemar,
> >>
> >> thanks for posting this. I read "This document describes an Active
> >> Queue Management mechanism, =E2=80=98L4S=E2=80=99, that can support =
low-latency
> >> services in a way that does not degrade the performance of other
> >> traffic." and I wonder whether 3GPP has run any experiments to
> >> confirm/support this claim, that you are willing to share?
> >
> > [IJ] We have done simulation studies with our proprietary 4G/5G =
system
> simulation tools but I can not disclose the results from these.
>=20
> 	[SM] Ah, I see, not posting internal data is fine, but by all means, =
go and
> perform real-world measurements as well with all the parts you =
actually want to
> roll-out (in other words testing with dctcp for example is =
scientifically
> interesting, unless you expect your users to actually use dctcp on =
your links).

[IJ] I hope to have data to show later on

>=20
>=20
> >>
> >> Sidenote: in the powerpoint file it says about L4s " Standardized =
in
> >> IETF [1]", which seems premature, in the process of being
> >> standardized seems a better description of the status quo...
> >
> > [IJ] Yes, you are right about this, it should have been "Subject to
> standardization..."
>=20
> 	[SM] Fair enough, as much as I regret to say it, standardization is =
quite
> likely.
>=20
> >
> >>
> >>
> >> I ask about test data from your side as the recent test data is =
quite
> >> sobering from a number of angles, including quality of isolation:
> >
> > [IJ] First of all the outline of the proposal for L4S in 5G is to =
use separate radio
> bearers for L4S and classic (or normal or non-L4S) traffic. This means =
that it is
> the 5G QoS framework and the scheduling in the RAN (Radio Access =
Network)
> that dictates the fairness.
>=20
> 	[SM] Sounds like a workable approach, that side steps the dualQ
> implementation/theory issues.

[IJ] The proposed approach for 5G is for practical reasons, we believe =
that it is more implementation and standardization friendly as it will =
utilize the existing QoS framework as much as possible.=20

>=20
>=20
> > But of course there are wireline transport link in the core network =
that may be
> using DualQ when that becomes commercially available. The bitrates =
over these
> links are however likely to be considerably higher than 50Mbps.
>=20
> 	That does not matter, the issue is not the limit of 50 Mbps, but the =
fact
> that dualQ, at last the current implementation in conjunction with the =
current
> TCP prague implementation, simply do not reliably and robustly do what =
the rfc
> draft claims. My fear is that dualQ, with its weak coupling vie =
marking
> probabilities, simply is a design, that only guarantees approximate =
fairness. In
> other words I doubt that dualQ works as a naive reading of the RFC =
implies. But
> if I  understood Bob correct, the only gurantee he is willing to give =
is L4S does
> not starve non-L4S traffic. Which IMHO is not sufficient to merit =
inflicting the
> L4S experiment on the wider internet. Now, that is not my call to =
make, but the
> IETF process allows me t voice my concerns, and I just use this =
opportunity in an
> attempt to minimize undesired side-effects on the "normal" internet.
>=20
> >
> >>
> >> 	Looking at the current L4S tests from the various testbeds I see
> >> severe breakdown of the promised isolation between bulk and the
> >> "low-latency" queue, apparently making the current implementation, =
if
> >> not the concept itself IMHO unfit for release into the wider
> >> internet, before these issues have been sufficiently addressed.
> >> Especially the observation that the weighted scheduler built in as =
a
> >> safety mechanism in the dualQ aqm seems to trigger considerably =
more
> >> often than expected/predicted from reading the dualQ draft (giving
> >> 1/16 of the bandwidth to on of two classes _might_ be justified as =
a
> >> temporary stop- gap measure in extremely unlikely cases, but this
> >> already triggers in a simple one-flow-per queue scenario at low =
RTTs). In
> short it currently looks like the "does not degrade performance of =
other traffic"
> part is not yet finished.
> >>
> >> 	To illustrate my criticism, here is a link to a test comparing the
> >> simplest functionality test imaginable, running one L4S-style and =
one
> >> non-L4S-style TCP connection through the L4S dual queue AQM at a
> >> intranet like RTT (nomnally 0ms, but in reality):
> >> https://protect2.fireeye.com/v1/url?k=3Dfcd5c73d-a05c68f4-fcd587a6-
> >> 0cc47ad93e1c-6acfac650abe7f09&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> >> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
> >> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.p
> >> ng As can be seen the L4S flow (labeled prague) ends up very =
quickly
> >> taking ~90% of the available bandwidth, leaving only 10% to the
> >> non-L4S flow (labeled cubic), wit increasing RTT this bias gets =
less
> >> extreme, but even at 80ms the prague flow still gets around 1.5 =
times
> >> the bandwidth of the cubic flow
> >> =
(https://protect2.fireeye.com/v1/url?k=3D77272802-2bae87cb-77276899-
> >> 0cc47ad93e1c-56d0590db27309ef&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> >> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
> >> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-80ms_var.
> >> png), indicating an RTT dependent performance degradation for =
"other
> >> traffic". Test from another testbed confirm the break-down of
> >> fairness between L4S and non- L4S traffic at short RTTs
> >> (https://protect2.fireeye.com/v1/url?k=3D5710f0ef-
> >> 0b995f26-5710b074-0cc47ad93e1c-418920d155a62bf0&q=3D1&e=3D6cd6c372-
> >> b712-46be-8b10-
> >> 22955dec7b38&u=3Dhttps%3A%2F%2Fwww.heistp.net%2Fdownloads%2Fsce-
> l4s-
> >> bakeoff%2Fbakeoff-2019-09-13T045427-r1%2Fl4s-s1-2%2Fbatch-l4s-s1-2-
> >> cubic-vs-prague-50Mbit-0ms_fixed.png).
> >
> > [IJ] I understand that the 0 RTT results can be because the =
congestion window
> is only a few segments large (my guess is ~3 to 4 segments ?). I know =
that this is
> a problem with e.g. DCTCP.  The question is whether this is a =
permanent
> problem or something that will be solved over time?.
>=20
> 	[SM] With DualQ, I assume it is a structural problem, instead of
> designing this as a robust system with two fair sharing queues it does =
its clever
> "indirect coupling" via marking/dropping probabilities. Have a look at
> https://protect2.fireeye.com/v1/url?k=3D53bd001b-0f37caa5-53bd4080-
> 869a17b5b21b-e4edb2934547a534&q=3D1&e=3D314d9ef9-5cc0-4c98-a599-
> 59f030e6cb2f&u=3Dhttps%3A%2F%2Fwww.heistp.net%2Fdownloads%2Fsce-l4s-
> bakeoff%2Fbakeoff-2019-09-13T045427-r1%2Fl4s-s2-2%2Fbatch-l4s-s2-2-
> cubic-vs-prague-50Mbit-10ms_fixed.png for how sharing in a FQ system =
looks.
> Even with the leaky ECT(1) as classifier abuse it shoukd be simple to =
fair queue
> between EXT(1) and not ECH(1) flows and have robust separation. This =
is not
> rocket science, and mostly, as far as I can tell a solved problem.
>=20
> > What is more interesting to me and what makes L4S attractive for the =
use
> cases outlined in the 3GPP contributions, is the very low queue delay =
with L4S.
>=20
> 	[SM] Well, I believe low queueing delay can be achieved without dualQ
> and without abusing the ECT(1) codepoint as a classifier (the desired =
classifier
> requires one complete independent bit, ECT(1) is just 1/2 of a bit, =
and hence has
> failure modes in separating L4S-style flows and non-L4S flows). The =
idea of using
> the finer-grained congestion signaling of DCTCP over the wider =
internet seems
> sane see the SCE draft proposal as an alternative that would/will =
allow dctcp-
> style ECN signaling over the internet in a truly backward compatible =
fashion...
>=20
>=20
> > There are other promising features with L4S. One being that it can =
enable
> congestion control algorithms to quickly grab free capacity.
>=20
> 	[SM] When you say L4S, do you mean the congestion signaling? Then
> https://tools.ietf.org/html/draft-morton-taht-sce-00 should have you =
covered,
> without the nasty side-effects of the current L4S proposal. Or do you =
mean the
> actual congestion controller as implemented in TCP prague?
>=20
>=20
> > 5G access can have large variations in link throughput for example =
related to
> dual connectivity and L4S can be helpful here as well.
>=20
> 	[SM] Dealing better with variable rate links is certainly desirable, =
but I
> am not sure that DualQ/TCP Prague really are the best or only tools =
for that
> purpose. At least not until all of the kinks are ironed out. Again, =
none of this is
> my call to make, so all I am voicing is my educated subjective =
assessments.
>=20
>=20
> Best Regards
> 	Sebastian
>=20
> >
> >>
> >> 	Personally, I can not help thinking that it might be better to =
first
> >> make sure there is a complete, real-world tested implementation =
that
> >> reliably demonstrates that dualQ delivers the required isolation
> >> between the two traffic classes and that the L4S approach actually
> >> delivers the reported reliable low latency performance under =
adverse
> >> real-world conditions while not degrading the performance of other =
traffic,
> before trying to codify L4S into RFCs.
> >>
> >>
> >> Best Regards
> >> 	Sebastian
> >>
> >>
> >>> On Nov 9, 2019, at 17:00, Ingemar Johansson S
> >> <ingemar.s.johansson=3D40ericsson.com@dmarc.ietf.org> wrote:
> >>>
> >>> Gentlepeople!
> >>>
> >>> This 3GPP SA2 contribution is recently submitted
> >>> =
https://protect2.fireeye.com/v1/url?k=3D803d870e-dcb428c7-803dc795-0cc
> >>> 47
> >>> ad93e1c-77a60175f8460bc6&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> >> 22955dec7b38&u=3D
> >>>
> >>
> https%3A%2F%2Fwww.3gpp.org%2Fftp%2Ftsg_sa%2FWG2_Arch%2FTSGS2_136
> >> _Reno%
> >>> 2FDocs%2FS2-1911250.zip Title =E2=80=9C5QI values for efficient =
handling of
> >>> congestion control marked IP packets=E2=80=9D
> >>> The contribution introduces L4S to the SA2 audience and explains
> >>> where the
> >> technology is useful. The contribution also proposes a method to =
bake
> >> L4S into the 5G QoS framework.
> >>> If agenda time permits, it will be discussed at the SA WG2 meeting
> >>> in Reno on
> >> Nov 18-22, hopefully with good results.
> >>>
> >>> Also a RAN2 contribution was submitted and discussed at an earlier
> >>> RAN2
> >> meeting.
> >>> =
https://protect2.fireeye.com/v1/url?k=3D06eb4ef7-5a62e13e-06eb0e6c-0cc
> >>> 47
> >>> ad93e1c-f387514c9f633599&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> >> 22955dec7b38&u=3D
> >>>
> >>
> https%3A%2F%2Fwww.3gpp.org%2Fftp%2FTSG_RAN%2FWG2_RL2%2FTSGR2_1
> >> 07bis%2F
> >>> Docs%2FR2-1913888.zip
> >>>
> >>> Enjoy
> >>> /Ingemar
> >>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
> >>> Ingemar Johansson  M.Sc.
> >>> Master Researcher
> >>>
> >>> Ericsson Research
> >>> Network Protocols & E2E Performance
> >>> Labratoriegr=C3=A4nd 11
> >>> 971 28, Lule=C3=A5, Sweden
> >>> Phone +46-1071 43042
> >>> SMS/MMS +46-73 078 3289
> >>> ingemar.s.johansson@ericsson.com
> >>> www.ericsson.com
> >>>
> >>>      The best way to find out if you  can trust somebody is to =
trust
> >>> them
> >>>              Ernest Hemingway
> >>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> >


------=_NextPart_000_011A_01D597B8.D0AFB390
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ
Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3
MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n
ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD
kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J
0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA
gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9
7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g
O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu
Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp
YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy
aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA
uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP
9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6
Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon
vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k
fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8
TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3
OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO
30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z
elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw
ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM
C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy
MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw
IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3
0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5
S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT
05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV
tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs
bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO
xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT
9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx
5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0
dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs
aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA
oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj
YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq
F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto
FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR
xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d
rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg
vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+
i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI
Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m
dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC
aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xOTExMTAxMDIwMTBaMCMGCSqGSIb3DQEJBDEWBBQGiRuN/d7VXVOWUxWl
Bcr+rORrczBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM
CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz
IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAB6BoUaoETklirC9b6zQEDNPBVxkQfIqJUBbnVbQ
JE13USfkLv9r4IX/v1AoSOAYuv79zpP0eQrfDB+aoWUtmggaOiDzIq9nA4yZ0dyn3+lbKIqbZaHd
+GAcsUTFAhoEIsEmlxCw/EJqdHXxfcg3KKQe9fpuzmKGM28WktNDp1xYRHEVvN5oZSZCppkhSaYE
WOLvT0dF36KYQjNXcyxLDlcKRJyg2ZUlivXi5uo/46s0aS2xlzYcf25g1apwtGXIwsVTAA6eUX8v
H4AV+zeEw7t5XF9dcgF+WB0yPg3nJOatp90RnECmTQ2KwL8qNc9FNxVfM7gE1nb89gxaSURCZvIA
AAAAAAA=

------=_NextPart_000_011A_01D597B8.D0AFB390--