Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE4112D66F for ; Wed, 20 Jul 2016 13:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sv0QqpHxb1Y for ; Wed, 20 Jul 2016 13:51:26 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC5712D98A for ; Wed, 20 Jul 2016 13:51:25 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-cc-578fe44b9de5 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1D.62.12926.B44EF875; Wed, 20 Jul 2016 22:51:23 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.30) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 20 Jul 2016 22:51:23 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y5sL4OD8RCySAG2h9vUswLO2tL+vYH2BZUrtyX36GGE=; b=li0e98ADc2O9iONMkGoeNSm6k+501G3CjvjeiP/YA7VrewS0j7Jt1gPrnKn++tn40v1T+O2XC5rVeG0bwfTmaLh9r/sbr+BzIyBTQ8HCsZSsrK6Vd5QRTQm/jIK8SfkWCEBZ9M9ut5oavWyd28v0GMer+3zsOQjlik8512HxU7E= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Wed, 20 Jul 2016 20:51:20 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0544.014; Wed, 20 Jul 2016 20:51:20 +0000 From: Ingemar Johansson S To: "csp@csperkins.org" , "ietf@bobbriscoe.net" Thread-Topic: [tcpPrague] Impact of an L4S experiment on non-TCP transports using ECT(1) Thread-Index: AQHR4rkm2jbcykViakufN1v67Etb56AhyrmA Date: Wed, 20 Jul 2016 20:51:20 +0000 Message-ID: References: <578E61CE.4090404@bobbriscoe.net> <959F4E4E-1C8D-431B-9A11-80D3D69E7F92@csperkins.org> In-Reply-To: <959F4E4E-1C8D-431B-9A11-80D3D69E7F92@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [46.189.28.225] x-ms-office365-filtering-correlation-id: 7cef396f-47c9-40e8-1fb4-08d3b0df9a63 x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 6:/Lxi0Jtb+B0j+Bj8KFd1vxMYkGCQAoIJT885D5cOIaV5LemgDOCTKBwO53ka8nxMoa/rUGFZTvXnkycq8Nliap3OtqwQtcimR2h22fLW/SMzZTdQ/NJQGXzorfITp40Og5IFGRvEzt0lRC+6xrAtrx7on/9UyZD+6xzH/IOpCB+kOblayD7LY3uT2qAjbUMY7ph39lsOXpSZcd3tDe2avxDiPSr721481LOQ4ZWuQg5lkh7hdJS/3qeSD2UHwP4Wkzt7v31MIZkbe2aiXpUPYFDRM7LoJ7s+6UbiL5gHufQ=; 5:n3AUcePGTQJubXxoDiQ2+da5VbaFU31aN3hR2sbRgFO2dvsHwz4H9LLSRg7TNpjOsrINtA814f5OwqZpia4LODaaGHiEkvI7M14R+jPfscM3GysZWqZaAxuotNwXgn/lEx5pyhuBL3bVBZH97UHvaQ==; 24:+9GgjM8xvpqgKhKmZ0xva93b+CnB+m8p/Bshm5HDybSFL99IDEOmbmyj9wgJ+LaVLXlPXt0iEePE6SlmAYFNwkPl8+pDTNnGoMv0I8f9R4E=; 7:H4vsqnB8DmCpHFM0FZ+zSzoJAaDToiAbGw/wszl+WJUMsDxPbHc+xV+Qmg+mpLKb33E/vDJcX+IdDbZ8ScTtiPDVP9aCv35xvIQ07xOcBsBApplYKlAmFQZU32uFFXb+4jyt1Jv4milQ5ue3qhCRcmL9WKjW9bqggzPq4xHvIOeTipOLoo4gJxP290IuuIXjKmQyxqfuHhZbOpU6QAkz/v/9aCnsXs/tnRVux4IGT6WHfU9vBiDh1dIQJKgL/PkU x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(20558992708506)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(85664002)(199003)(189002)(24454002)(69234005)(105586002)(99936001)(8936002)(77096005)(3280700002)(107886002)(122556002)(2906002)(561944003)(2501003)(15975445007)(54356999)(19300405004)(76176999)(19580395003)(19580405001)(50986999)(66066001)(81166006)(4001430100002)(33656002)(86362001)(3660700001)(7736002)(7696003)(586003)(4326007)(9326002)(81156014)(6116002)(102836003)(19625215002)(3846002)(790700001)(2950100001)(2900100001)(5002640100001)(7906003)(5003600100003)(7846002)(106116001)(92566002)(76576001)(16236675004)(106356001)(97736004)(101416001)(5001770100001)(74316002)(189998001)(68736007)(11100500001)(15395725005)(9686002)(10400500002)(19617315012)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_013B_01D1E2D9.39A17C00" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2016 20:51:20.1032 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUhTYRTGeXfvrtt0cF2ah2mhQ0M0rTTDSEQD0Qg/iMBUIpfedEyn7Jpl CZmmpcPUSs0FZmhJuki0dIoaDl2aEWpBaOhyTWh+hQ01kz7udifUf7/znOc95znw8jDRKlfM kynyKKVCmiUhBHjDmZ69ASdNVYkHb2/4hraaR1HoyHwTN7S2aAiPwGIWDRPcmDqDgYhpadni JGDJgrB0KkuWTykPhKcKMs31Gk6upZVzubR8lShCxjJOBeLzgDwMk721GMu7YWLuOVGBBDwR OYxAt1WGs8UoguaGVdsLnKzEYLEcYxt1HHjQ+MFe6BH0qadsswgyDJ7qNpGVXchk+LjRbtMx MgNKjGOElXeRSdBimHfY8dwsG2T8PIaD4G2XP7vMBzZKBm12IWN5N/3LFkJEpoN5ZJ1rtfPJ SNgscbTKiLlg842Gw25ygxnTQ/uVLjA/OU6w7ArmL7+5rD8Nvk9XclndC6pWum0JgIyF3g2Z 9SogVwjQDty1e6LAsrKMWJaBvtxi1+VgMfXhLGsRaD4dZ9kDepa7CXaQgYCSpZcYm5+C1mel qBr5qf/JqmZ8GFmJ4EZ3NVLbbnaGsQYTzppSQGsqdmDZHxamF/AdfvJoCVMzwTHSD5rVJ/6X rXwM7v8cIlj2gnuqefuYEFgaWUNNyLENudIUfT47Iyg4kFLK0mg6RxGooPI6EfPzhl5s+2jR ++VIHSJ5SOIk9OyvShRxpfl0QbYOeTNzjB3tE0iMK3IUlMRFGPeZaQvTpQVXKGXOOeXFLIrW IXceLnETxpu9EkVkhjSPklNULqXc6XJ4fHERUnl2uq+dXR0W7Y9IbatZLx6bm5RzzPIjvj+8 v54KjvszOz6lmn1NhMdrllRpA8Ks+kH3oJSKO69Oq6e6auIK90T5h4anhvCbLN9i+x2u3kos dNVzH9ddMqKZa9ed9L1NHdFBFwSjqYQuQeyYlLAdvRmQto9w9nAOkzZWy48WtEtwOlN6yA9T 0tK/bbusDIEDAAA= Archived-At: Cc: Ingemar Johansson S , "tcpPrague@ietf.org" Subject: Re: [tcpPrague] Impact of an L4S experiment on non-TCP transports using ECT(1) X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 20:51:30 -0000 ------=_NextPart_000_013B_01D1E2D9.39A17C00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_013C_01D1E2D9.39A17C00" ------=_NextPart_001_013C_01D1E2D9.39A17C00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi =20 FYI, I am trying to get some info if there are any implementations = (pending or existing) of ECN support for 3GPP MSTI according to = TS26.114. I am almost certain that there are no but it needs to be = checked out, given vacation period and all it may take a while to get a = clear answer. =20 /Ingeamr=20 =20 From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: den 20 juli 2016 10:34 To: Bob Briscoe Cc: TCP Prague List Subject: Re: [tcpPrague] Impact of an L4S experiment on non-TCP = transports using ECT(1) =20 Bob, =20 On 19 Jul 2016, at 19:22, Bob Briscoe > wrote: =20 Colin, For the writing about the proposed effect of L4S on RFC6679, see the L4S = problem statement section 1.4, item 3B) https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-proble= m-02#section-1.4 It there are any other RFCs beyond the list there that use ECT(1) that = we're not aware of, pls let me know. Can you explain the impact on circuit breaker? =20 The ongoing experiments with AQM and ECN, of which L4S is a part, have = made it very unclear how a transport should respond to ECN-CE marks, for = either ECT(0) or ECT(1). The circuit breaker got caught in that = discussion.=20 =20 Colin =20 =20 =20 Prior to the problem statement, text about 6679 was written in the L4S = identifier draft that I've presented in tsvwg, and mentioned the effect = on other transports including RTP-ECN. We wrote what we thought the process would be in = https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-01#section-1.3= However, the tsv management have now clarified how they want this done = (I'm expecting discussion in tsvwg tomorrow now we've had the BoF). I can send you the draft text we're proposing to use to update 3168, = 6679 etc, if you want (or you can wait until it's actually submitted as = a draft, perhaps tonight. Essentially the idea is 2-stage: 1) a PS to obsolete RFC3540 (experimental) and to update RFC3168 RFC4960 = RFC6679 RFC4340 to reserve ECT(1) for future experiments again 2) the L4S identifier draft (draft-briscoe-tsvwg-ecn-l4s-id) to use the = newly reserved ECT(1) codepoint experimentally I appreciate that there might be implementations in progress that use = ECT(1), but as 6679 did not say what ECT(1) is for, I doubt it. If an RTP implementation is using a field in the IP header for something = that hasn't been standardised by the IETF and is not the current = experimental use (the ECN nonce), then I think it has no right to = complain if it gets stamped on by a new IETF-sanctioned experiment. You will recall I checked the intent of the ECT(1) text in 6679 on the = avtcore list some time ago. See your response then, pasted below. Bob -------- Forwarded Message --------=20 Subject:=20 Re: [AVTCORE] RFC6679 ECN in RTP: intent of ect =3D 0, 1, or random? Date:=20 Mon, 9 Nov 2015 10:55:14 +0000 From:=20 Colin Perkins To:=20 Bob Briscoe CC:=20 Ingemar Johansson S = , Magnus Westerlund = = , Ken Carlberg = =20 Bob, =20 This sounds interesting, and would be a good fit for the RMCAT working = group, but doesn=E2=80=99t sound like it would be an update to the = ECN-for-RTP RFC (which specifies ECN negotiation, marking, and feedback, = but no congestion control algorithms). =20 Colin =20 =20 =20 =20 > On 5 Nov 2015, at 10:04, Bob Briscoe = wrote: >=20 > Colin, >=20 > OK. In the fullness of time, if our proposal continues to get = traction, I'll draft a little experimental bis to ECN in RTP to specify = scalable congestion control. It will be v simple: >=20 > If using scalable cc: > * sender only uses scalable cc if (all) receiver(s) report ECN support > * sender rate equation is like TFRC equation, but with 1/p instead of = 1/sqrt(p) > * fall back to TFRC equation on loss rather than ECN (and also = possibly on ECN accompanied by high variable delay) for 'a few' 1RTT = (TBD) > * sender sets ECT(1) not ECT(0) > * no changes on receiver > * I think it would work deployed one RTP hop at a time, but that would = have to be tested >=20 > But I'd want to implement and test it first, of course. >=20 >=20 >=20 > Bob >=20 > On 05/11/15 07:34, Colin Perkins wrote: >> Bob, >>=20 >>> On 4 Nov 2015, at 17:50, Bob Briscoe = wrote: >>>=20 >>> Piers, >>>=20 >>> I realised I didn't send the mail thanking you for your response. = Thank you - v useful, and confirmation of my vague memory of events. >>>=20 >>> 1. Would the authors (and wider community) be happy to allow ECT(1) = not to be set-aside for future anti-cheating use, as long as there was = another way, in principle, for the sender to check for cheating? >> I have no objection. You might check with the RMCAT chairs, since = some of their proposals make use of ECN with RTP, but I doubt this will = be a problem. >>=20 >>> For TCP, we worked out a way for the sender to check for cheating = without burning a codepoint - by the sender introducing one or two CE = codepoints of its own, and checking the receiver reports them. Would = this be harder for RTP? Are the receiver reports deterministic enough = for the sender to determine whether codepoints it injected are correctly = counted in the next report? >> The sender could easily set a CE mark on a small number of packets = it=E2=80=99s sending. For unicast cases, where there=E2=80=99s an = explicit control loop, it should be able to correlate this with the = returned RTCP feedback. Where it might be difficult is with open loop = layered multicast congestion control, where some receivers might see the = CE mark and drop a layer since they don=E2=80=99t know it=E2=80=99s a = synthetic mark. >>=20 >> Colin >>=20 >>=20 >>=20 >>=20 >>> 2. A couple of days after I posted the original question, we posted = the -00 individual draft aiming to start the process of repurposing = ECT(1). You will see the sentence in the scope section = = >>>=20 >>> See security considerations for discussion on feedback integrity = checking. >>>=20 >>>=20 >>> Bob >>>=20 >>> On 19/10/15 10:15, Piers O'Hanlon wrote: >>>> Hi Bob, >>>>=20 >>>> I think the reasoning was that ECT(1)/random could potentially be = used to detect cheating/failures as mentioned in section 7.4, but I = can't see that it's going to make a lot of difference if ECT(1) is not = used. >>>>=20 >>>> Piers >>>>=20 >>>> On 17 Oct 2015, at 22:59, Bob Briscoe wrote: >>>>=20 >>>>> Guys, >>>>> [Ignore last identical email - I left the list off the distr in = error] >>>>>=20 >>>>> I'm writing a draft to propose a new use for ECT(1). >>>>>=20 >>>>> In reading RFC6679, It says that the there is no intent to use an = ECN nonce. >>>>> Also it says the receiver might want to advise the sender not to = use ect=3Drandom, if its behind a header compression link. And that = ect=3D0 is recommended and the default. >>>>>=20 >>>>> But it doesn't seem to actually say why a sender might send ECT(1) = instead of ECT(0). Or why a sender might use the two randomly. Or why a = receiver might ask for ect=3D1, or ect=3Drandom. >>>>>=20 >>>>> I'm trying to work out whether there would be any detriment to = RFC6679 if it couldn't use ECT(1). It looks like not. >>>>>=20 >>>>>=20 >>>>> Bob >>>>>=20 >>>>> --=20 >>>>> ________________________________________________________________ >>>>> Bob Briscoehttp://bobbriscoe.net/ >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>>=20 >>=20 >>=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org =20 > https://www.ietf.org/mailman/listinfo/avt =20 --=20 ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ =20 =20 --=20 Colin Perkins https://csperkins.org/ =20 =20 =20 ------=_NextPart_001_013C_01D1E2D9.39A17C00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi=

 

FYI, I am = trying to get some info if there are any implementations (pending or = existing) of ECN support for 3GPP MSTI according to TS26.114. I am = almost certain that there are no but it needs to be checked out, given = vacation period and all it may take a while to get a clear = answer.

 

/Ingeamr =

 

From:<= /b> = Colin Perkins [mailto:csp@csperkins.org]
Sent: den 20 juli = 2016 10:34
To: Bob Briscoe = <ietf@bobbriscoe.net>
Cc: TCP Prague List = <tcpPrague@ietf.org>
Subject: Re: [tcpPrague] Impact of = an L4S experiment on non-TCP transports using = ECT(1)

 

Bob,

 

On 19 Jul 2016, at 19:22, Bob Briscoe <ietf@bobbriscoe.net> = wrote:

 

Colin,

For the writing about the proposed = effect of L4S on RFC6679, see the L4S problem statement section 1.4, = item 3B)
https://tools.ietf.org/html/draft-briscoe-tsvwg= -aqm-tcpm-rmcat-l4s-problem-02#section-1.4

It there are any = other RFCs beyond the list there that use ECT(1) that we're not aware = of, pls let me know.
Can you explain the impact on circuit = breaker?

 

The ongoing experiments with AQM and ECN, of which L4S = is a part, have made it very unclear how a transport should respond to = ECN-CE marks, for either ECT(0) or ECT(1). The circuit breaker got = caught in that discussion. 

 

Colin

 

 

 



Prior to the problem statement, text about 6679 was = written in the L4S identifier draft that I've presented in tsvwg, and = mentioned the effect on other transports including RTP-ECN.
We wrote = what we thought the process would be in https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-01#s= ection-1.3
However, the tsv management have now clarified how = they want this done (I'm expecting discussion in tsvwg tomorrow now = we've had the BoF).


I can send you the draft text we're = proposing to use to update 3168, 6679 etc, if you want (or you can wait = until it's actually submitted as a draft, perhaps = tonight.
Essentially the idea is 2-stage:
1) a PS to obsolete = RFC3540 (experimental) and to update RFC3168 RFC4960 RFC6679 RFC4340 to = reserve ECT(1) for future experiments again
2) the L4S identifier = draft (draft-briscoe-tsvwg-ecn-l4s-id) to use the newly reserved ECT(1) = codepoint experimentally

I appreciate that there might be = implementations in progress that use ECT(1), but as 6679 did not say = what ECT(1) is for, I doubt it.
If an RTP implementation is using a = field in the IP header for something that hasn't been standardised by = the IETF and is not the current experimental use (the ECN nonce), then I = think it has no right to complain if it gets stamped on by a new = IETF-sanctioned experiment.

You will recall I checked the intent = of the ECT(1) text in 6679 on the avtcore list some time ago.
See = your response then, pasted below.


Bob


-------- = Forwarded Message --------

Subject:

Re: [AVTCORE] = RFC6679 ECN in RTP: intent of ect =3D 0, 1, or = random?

Date:

Mon, 9 Nov 2015 = 10:55:14 +0000

From:

Colin Perkins <csp@csperkins.org>

To:

Bob Briscoe <ietf@bobbriscoe.net><= /o:p>

CC:

Ingemar Johansson = S <ingemar.s.johansson@= ericsson.com>, Magnus Westerlund <magnus.westerlund@eric= sson.com>, Ken Carlberg <carlberg@g11.org.uk><= /o:p>

 

Bob,<=
/pre>
 
This sounds interesting, and would =
be a good fit for the RMCAT working group, but doesn=E2=80=99t sound =
like it would be an update to the ECN-for-RTP RFC (which specifies ECN =
negotiation, marking, and feedback, but no congestion control =
algorithms).
 
Colin<=
/o:p>
 
 
<=
o:p> 
 
> On 5 Nov =
2015, at 10:04, Bob Briscoe <ietf@bobbriscoe.net> =
wrote:
> 
> =
Colin,
> 
> OK. In the =
fullness of time, if our proposal continues to get traction, I'll draft =
a little experimental bis to ECN in RTP to specify scalable congestion =
control. It will be v simple:
> =

> If using scalable =
cc:
> * sender only uses scalable cc if (all) =
receiver(s) report ECN support
> * sender rate =
equation is like TFRC equation, but with 1/p instead of =
1/sqrt(p)
> * fall back to TFRC equation on loss =
rather than ECN (and also possibly on ECN accompanied by high variable =
delay) for 'a few' 1RTT (TBD)
> * sender sets =
ECT(1) not ECT(0)
> * no changes on =
receiver
> * I think it would work deployed one =
RTP hop at a time, but that would have to be =
tested
> 
> But I'd want =
to implement and test it first, of course.
> =

> 
> =

> Bob
> =

> On 05/11/15 07:34, Colin Perkins =
wrote:
>> Bob,
>> =

>>> On 4 Nov 2015, at 17:50, Bob Briscoe =
<ietf@bobbriscoe.net> =
wrote:
>>> =

>>> =
Piers,
>>> =

>>> I realised I didn't send the mail =
thanking you for your response. Thank you - v useful, and confirmation =
of my vague memory of events.
>>> =

>>> 1. Would the authors (and wider =
community) be happy to allow ECT(1) not to be set-aside for future =
anti-cheating use, as long as there was another way, in principle, for =
the sender to check for cheating?
>> I have =
no objection. You might check with the RMCAT chairs, since some of their =
proposals make use of ECN with RTP, but I doubt this will be a =
problem.
>> =

>>> For TCP, we worked out a way for the =
sender to check for cheating without burning a codepoint - by the sender =
introducing one or two CE codepoints of its own, and checking the =
receiver reports them. Would this be harder for RTP? Are the receiver =
reports deterministic enough for the sender to determine whether =
codepoints it injected are correctly counted in the next =
report?
>> The sender could easily set a CE =
mark on a small number of packets it=E2=80=99s sending. For unicast =
cases, where there=E2=80=99s an explicit control loop, it should be able =
to correlate this with the returned RTCP feedback. Where it might be =
difficult is with open loop layered multicast congestion control, where =
some receivers might see the CE mark and drop a layer since they =
don=E2=80=99t know it=E2=80=99s a synthetic =
mark.
>> 
>> =
Colin
>> 
>> =

>> 
>> =

>>> 2. A couple of days after I posted =
the original question, we posted the -00 individual draft aiming to =
start the process of repurposing ECT(1). You will see the sentence in =
the scope section <https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-=
00#section-1.3>
>>> =

>>> See security considerations for =
discussion on feedback integrity =
checking.
>>> =

>>> 
>>> =
Bob
>>> 
>>> =
On 19/10/15 10:15, Piers O'Hanlon =
wrote:
>>>> Hi =
Bob,
>>>> =

>>>> I think the reasoning was that =
ECT(1)/random could potentially be used to detect cheating/failures as =
mentioned in section 7.4, but I can't see that it's going to make a lot =
of difference if ECT(1) is not =
used.
>>>> =

>>>> =
Piers
>>>> =

>>>> On 17 Oct 2015, at 22:59, Bob =
Briscoe wrote:
>>>> =

>>>>> =
Guys,
>>>>> [Ignore last identical =
email - I left the list off the distr in =
error]
>>>>> =

>>>>> I'm writing a draft to =
propose a new use for ECT(1).
>>>>> =

>>>>> In reading RFC6679, It says =
that the there is no intent to use an ECN =
nonce.
>>>>> Also it says the =
receiver might want to advise the sender not to use ect=3Drandom, if its =
behind a header compression link. And that ect=3D0 is recommended and =
the default.
>>>>> =

>>>>> But it doesn't seem to =
actually say why a sender might send ECT(1) instead of ECT(0). Or why a =
sender might use the two randomly. Or why a receiver might ask for =
ect=3D1, or ect=3Drandom.
>>>>> =

>>>>> I'm trying to work out =
whether there would be any detriment to RFC6679 if it couldn't use =
ECT(1). It looks like not.
>>>>> =

>>>>> =

>>>>> =
Bob
>>>>> =

>>>>> -- =

>>>>> =
________________________________________________________________
>>>>> Bob Briscoehttp://bobbriscoe.net/<=
o:p>
>>> -- 
>>> =
________________________________________________________________
>>> Bob Briscoehttp://bobbriscoe.net/<=
o:p>
>>> 
>> =

>> 
> =

> -- 
> =
________________________________________________________________
> Bob =
Briscoe=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://bobbriscoe.net/
> 
> =
_______________________________________________
>=
 Audio/Video Transport Core Maintenance
> avt@ietf.org
> =
https://www.ietf.org/m=
ailman/listinfo/avt
 


-- =

___________________________________________________=
_____________
Bob =
Briscoe=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://bobbriscoe.net/

 

 

-- 

Colin = Perkins

 

 

 

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