From nobody Fri Mar 1 05:05:26 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97999128CF3 for ; Fri, 1 Mar 2019 05:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKHF3yWZ71Jr for ; Fri, 1 Mar 2019 05:05:23 -0800 (PST) Received: from mail.mera.ru (mail.mera.ru [188.130.168.162]) (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 D65FB130E73 for ; Fri, 1 Mar 2019 05:05:21 -0800 (PST) Received: from e16srv02.merann.ru ([192.168.50.32]) by mail.mera.ru with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (envelope-from ) id 1gzhq0-0008Jo-33; Fri, 01 Mar 2019 16:04:28 +0300 Received: from e16srv03.merann.ru (2001:67c:2344:50::33) by e16srv02.merann.ru (2001:67c:2344:50::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1591.10; Fri, 1 Mar 2019 16:05:12 +0300 Received: from e16srv03.merann.ru ([fe80::2cb7:1925:fc4a:82dc]) by e16srv03.merann.ru ([fe80::2cb7:1925:fc4a:82dc%12]) with mapi id 15.01.1591.012; Fri, 1 Mar 2019 16:05:12 +0300 From: "Proshin, Maksim" To: "tuexen@fh-muenster.de" , "tsvwg@ietf.org" Thread-Topic: SCTP RANDOM parameter in case of INIT collision Thread-Index: AdTQLVHtlActtV+uQSOp8/Lo4JDYOg== Date: Fri, 1 Mar 2019 13:05:03 +0000 Deferred-Delivery: Fri, 1 Mar 2019 13:04:25 +0000 Message-ID: <2b50678935f34e25aff2f6b21eca9374@mera.ru> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.201.113] x-inside-org: True Content-Type: multipart/alternative; boundary="_000_2b50678935f34e25aff2f6b21eca9374meraru_" MIME-Version: 1.0 X-Src-IF-Name: mail.mera.ru Archived-At: Subject: [tsvwg] SCTP RANDOM parameter in case of INIT collision X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:05:26 -0000 --_000_2b50678935f34e25aff2f6b21eca9374meraru_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi Michael, tsvwg, I have a doubt about the RANDOM parameter from RFC 4895 which was caused by= interoperability tests with different SCTP implementations. RFC 4895 has the following text in Section 6.1: In case of INIT collision, the rules governing the handling of this Random Number follow the same pattern as those for the Verification Tag, as explained in Section 5.2.4 of RFC 2960 [5]. Therefor= e, each endpoint knows its own Random Number and the peer's Random Number after the association has been established. and RFC 4960 which obsoletes RFC 2960 has the following statement in Sectio= n 5.2.1: Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged). Based on those 2 statements I assume that SCTP must always respond with the= same Random Number when it sends INIT ACK in response to INIT received in = the COOKIE-WAIT state. Is my understanding correct? BR, Maxim --_000_2b50678935f34e25aff2f6b21eca9374meraru_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hi Michael, tsvwg,

 

I have a doubt about t= he RANDOM parameter from RFC 4895 which was caused by interoperability test= s with different SCTP implementations.

RFC 4895 has the follo= wing text in Section 6.1:

   In case
   of INIT collision, the rules =
governing the handling of this Random
   Number follow the same patter=
n as those for the Verification Tag, as
   explained in Section 5.2.4 of RFC 296=
0 [5].  Therefore, each =
endpoint
   knows its own Random Number a=
nd the peer's Random Number after the
   association has been establis=
hed.

 

and RFC 4960 which obs= oletes RFC 2960 has the following statement in Section 5.2.1:

 

   Upon receipt of an INIT in th=
e COOKIE-WAIT state, an endpoint MUST
   respond with an INIT ACK usin=
g the same parameters it sent in its
   original INIT chunk (includin=
g its Initiate Tag, unchanged).

 

Based on those 2 state= ments I assume that SCTP must always respond with the same Random Number wh= en it sends INIT ACK in response to INIT received in the COOKIE-WAIT state.= Is my understanding correct?    

 

BR, Maxim

--_000_2b50678935f34e25aff2f6b21eca9374meraru_-- From nobody Fri Mar 1 05:29:23 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F48124BAA for ; Fri, 1 Mar 2019 05:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKU7BrB8Pgf9 for ; Fri, 1 Mar 2019 05:29:19 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048D1124D68 for ; Fri, 1 Mar 2019 05:29:18 -0800 (PST) Received: from [192.168.1.9] (p57BB42E6.dip0.t-ipconnect.de [87.187.66.230]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id CB330721E281E; Fri, 1 Mar 2019 14:29:12 +0100 (CET) From: Michael Tuexen Message-Id: <997A9DE0-5AD2-4991-8D09-7F1C00072929@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_B0937EA4-746C-4388-AEA0-46D3D135CE6E"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Mar 2019 14:29:11 +0100 In-Reply-To: <2b50678935f34e25aff2f6b21eca9374@mera.ru> Cc: "tsvwg@ietf.org" To: "Proshin, Maksim" References: <2b50678935f34e25aff2f6b21eca9374@mera.ru> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:29:22 -0000 --Apple-Mail=_B0937EA4-746C-4388-AEA0-46D3D135CE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 1. Mar 2019, at 14:05, Proshin, Maksim wrote: >=20 > Hi Michael, tsvwg, > =20 > I have a doubt about the RANDOM parameter from RFC 4895 which was = caused by interoperability tests with different SCTP implementations. > RFC 4895 has the following text in Section 6.1: > In case > of INIT collision, the rules governing the handling of this Random > Number follow the same pattern as those for the Verification Tag, = as > explained in Section 5.2.4 of RFC 2960 [5]. Therefore, each = endpoint > knows its own Random Number and the peer's Random Number after the > association has been established. > =20 > and RFC 4960 which obsoletes RFC 2960 has the following statement in = Section 5.2.1: > =20 > Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST > respond with an INIT ACK using the same parameters it sent in its > original INIT chunk (including its Initiate Tag, unchanged). > =20 > Based on those 2 statements I assume that SCTP must always respond = with the same Random Number when it sends INIT ACK in response to INIT = received in the COOKIE-WAIT state. Is my understanding correct? =20 Yes, I would say so. Is an open source implementation not following these rules? Best regards Michael > =20 > BR, Maxim --Apple-Mail=_B0937EA4-746C-4388-AEA0-46D3D135CE6E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEJAw ggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJERTEcMBoG A1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRl cjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQwNzIyMTIwODI2WhcN MTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UE CxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcAW5UidNQg6zSP 1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7 DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycw DQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO7 2uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQAB o4IBhjCCAYIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAf BgNVHSMEGDAWgBQxw3kbuvVT1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1Ud IARbMFkwEQYPKwYBBAGBrSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIs AQEEAwEwDwYNKwYBBAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1o dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEE bDBqMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEF BQcwAoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhthJxb/ w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvNTVx07iHy dQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEsjmpttzUCGc/1 OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6hL5Kp2AvGhB8Exuse 6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtUFzCCBaIwggSKoAMCAQIC BxekJKEJSDMwDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJl aW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcw MTAeFw0xNDA1MjcxNDU0MDlaFw0xOTA3MDkyMzU5MDBaMIHGMQswCQYDVQQGEwJERTEcMBoGA1UE CBMTTm9yZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2ho b2Noc2NodWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEd MBsGA1UEAxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5z dGVyLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuHlsrvBs7CL9IqMH9r//QU9E pghTV/3skHuQZ3DpNY+lyJWOW5zbtUubgXt7lYHpIE4d4CclTZWqCHwoAI6gqzSSGjUKuX6/0ui/ LhXmlDvCBfwuER+T+3/R59hlLnhI5iYYPQiNywQIa3wJhBLTZrlXw8nDdjI54MAzcVDUX7l21sbo ZIA6idM7SXmshxoRQ6xsfPHskrceNMcvtHNDhVnVscwRUJQUR55fs0X7Y93PasugWPv3xmgNr1da Cq94eV+nslNU/GJaT9TQ3uG8pagLXl9NbDNkHIrvFAD5zXO0m/d00I4QhUVQyEtwnTegDqcM+WFh JXensgnZhWe6bwIDAQABo4IB/jCCAfowEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMC AQYwEQYDVR0gBAowCDAGBgRVHSAAMB0GA1UdDgQWBBQK81u85DGA1jVCiabTw8833tHf1zAfBgNV HSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAcBgNVHREEFTATgRFjYUBmaC1tdWVuc3Rlci5k ZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3Qt Y2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFs LXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHKMIHHMDMGCCsGAQUFBzAB hidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0 dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEA3kcDNdZKb7kSD7s1ly2qa/2QbQe+ ld3LhZeOcfysdLtN8oweBmgT3MYoZ+D9c+SoUWJAwTKPB15DoGy+fWhelXTpQrqxIGb4ISr1JCjg slnmMUva0xjwZGxojZ9gE1bi18xfKw3+dMpwCLt6LbLTjr/tyH6otacwr2tZzuuJIUAORnefwTcr vmB21n/BEQH/ZXruWu8lSO3L9YAmQB6ViaZFCpn2sMmOLACdoWxmUQb3QAjsa327jHUjsz53k9q5 Zrx/g+zOg5s1Wmy2JOlLQMUIZXXf0/6rB5Fr2llx7dBG/Uk7NhZdNy7OzNzci0C4Wnkd8rDVEWHG hH2gfpcTfjCCBg0wggT1oAMCAQICBxuZiHQ3saMwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNVBAYT AkRFMRwwGgYDVQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4G A1UEChMXRmFjaGhvY2hzY2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5n c3plbnRyYWxlMR0wGwYDVQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYR Y2FAZmgtbXVlbnN0ZXIuZGUwHhcNMTYwNzA0MDcwNjEzWhcNMTkwNzA0MDcwNjEzWjB8MQswCQYD VQQGEwJERTEgMB4GA1UECgwXRmFjaGhvY2hzY2h1bGUgTXVlbnN0ZXIxMjAwBgNVBAsMKUZhY2hi ZXJlaWNoIEVsZWt0cm90ZWNobmlrIHVuZCBJbmZvcm1hdGlrMRcwFQYDVQQDDA5NaWNoYWVsIFR1 ZXhlbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMyaGlBt2ZtuF8QP8zYNrGxXC+es PMajIPl+hu1LGHnN2BJ3J5ZMN44BOZw3n6LO1FaAgO8D4xU4/AELecX6VxJZ2zOOSD8uTYO4OnUu 24hkjFUQAj13tT644AKUQMMBpgj7wC52V5Jij+mZX/t1S38/WFiCGnirt4xTNi5OmN4K+VNZfG4x 0msDqFjJX70rF1y09/Mylu1M/Y0tu/I9DqhwDQT4LBOvyyaAlhSJ8Jb8m8YTt5xlOzrXlBmj4pKs 74y7C2IKRw4tFozGX1cf1LVEs2eBCb5iUwXrlcMipwm62sJ38GD00EOlRNTpAM5rDAcgWxMCffek bRv/01whtOkCAwEAAaOCAkcwggJDMEAGA1UdIAQ5MDcwEQYPKwYBBAGBrSGCLAEBBAMFMBEGDysG AQQBga0hgiwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgXg MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU0B2vaoSoEmYAggD04WZF 2hGif3UwHwYDVR0jBBgwFoAUCvNbvOQxgNY1Qomm08PPN97R39cwIAYDVR0RBBkwF4EVdHVleGVu QGZoLW11ZW5zdGVyLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9maC1tdWVuc3Rlci1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNh LmRmbi5kZS9maC1tdWVuc3Rlci1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcow gccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBH BggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9maC1tdWVuc3Rlci1jYS9wdWIvY2Fj ZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZmgtbXVl bnN0ZXItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBI9v+seJM6 AlSIrmmpopz6zh8QAsqGLJkkY2D0KYFucUY/xZaJTtZxvmWddbKk2903Qhg+vZKOf87PHhip7/4t FSwhxYNSS36WsRJTeUa0f3KkSa28yrIRfWlJATgxfL5X/QQnopjCt34n4221kcsR7LHxBAn37ow+ /2L7WjWDDuOkaM9/ZSCtrN+yFRat1eUVs1Hk7sKT/bfJTsYqzovXitjmCP3YdB40dkuQ6/ZzEdXT bpa4c45RcRnPqKXnxknK0UfRHNHqk15W7dUPVMzSGFUvjhmWPP2wW6a8F1U5sEqfHcoBFC5CGjGy 7Gk2luk3obi/KLrDyZC+dkjhDYEpMYIEOTCCBDUCAQEwgdIwgcYxCzAJBgNVBAYTAkRFMRwwGgYD VQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFj aGhvY2hzY2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxl MR0wGwYDVQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVl bnN0ZXIuZGUCBxuZiHQ3saMwDQYJYIZIAWUDBAIBBQCgggI3MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMwMTEzMjkxMlowLwYJKoZIhvcNAQkEMSIEIAhOvy4P +riV/SdM3ll13jo6cPMURa4Vu4I4LpTG8BjvMIHjBgkrBgEEAYI3EAQxgdUwgdIwgcYxCzAJBgNV BAYTAkRFMRwwGgYDVQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEg MB4GA1UEChMXRmFjaGhvY2hzY2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0 dW5nc3plbnRyYWxlMR0wGwYDVQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJ ARYRY2FAZmgtbXVlbnN0ZXIuZGUCBxuZiHQ3saMwgeUGCyqGSIb3DQEJEAILMYHVoIHSMIHGMQsw CQYDVQQGEwJERTEcMBoGA1UECBMTTm9yZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0 ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2NodWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFy YmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UEAxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG 9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRlAgcbmYh0N7GjMA0GCSqGSIb3DQEBAQUABIIBAKWPtrdy SylAEXyjS2PWLuTN3pafUoQ3ugM7wEeC1oxjn4RXzXU3EkN5Zwt4PubKN3NFxE5Y3xCTKsYzL5FA +ibaLbc4lE/o5H+W7D0t2WB20bD4QZGQFnjXZDTNqJzleD0fNAr+us3LBui6kypAbURhE9yL0F4b hg3JjxT6lTzJ40lg2/NLjp7v/reykjOOjigEda9rZbteLNx8m1Ba/DIrO7QVw8Pn4IinvIo42xel 4ssD6xjN2JL1SlnazHiZ0B/eOikzQf/pRvWbE+/EZPkxDxhcT2Dw0WFNLmVSN4kiD9B61KlNVyle B9SHui1Bbsk9K/yJSNLxfiy9r3vf6YoAAAAAAAA= --Apple-Mail=_B0937EA4-746C-4388-AEA0-46D3D135CE6E-- From nobody Fri Mar 1 05:46:24 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987BF130E58 for ; Fri, 1 Mar 2019 05:46:22 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT4uE8ATuzdW for ; Fri, 1 Mar 2019 05:46:20 -0800 (PST) Received: from mail.mera.ru (mail.mera.ru [188.130.168.162]) (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 714C4130E0A for ; Fri, 1 Mar 2019 05:46:20 -0800 (PST) Received: from e16srv02.merann.ru ([192.168.50.32]) by mail.mera.ru with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (envelope-from ) id 1gziTh-000AM6-0u; Fri, 01 Mar 2019 16:45:29 +0300 Received: from e16srv03.merann.ru (2001:67c:2344:50::33) by e16srv02.merann.ru (2001:67c:2344:50::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1591.10; Fri, 1 Mar 2019 16:46:13 +0300 Received: from e16srv03.merann.ru ([fe80::2cb7:1925:fc4a:82dc]) by e16srv03.merann.ru ([fe80::2cb7:1925:fc4a:82dc%12]) with mapi id 15.01.1591.012; Fri, 1 Mar 2019 16:46:13 +0300 From: "Proshin, Maksim" To: Michael Tuexen CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] SCTP RANDOM parameter in case of INIT collision Thread-Index: AdTQLVHtlActtV+uQSOp8/Lo4JDYOv//2JSA///KAxA= Date: Fri, 1 Mar 2019 13:46:05 +0000 Deferred-Delivery: Fri, 1 Mar 2019 13:45:46 +0000 Message-ID: <588a6ab909d14fd78ca8715aec951954@mera.ru> References: <2b50678935f34e25aff2f6b21eca9374@mera.ru> <997A9DE0-5AD2-4991-8D09-7F1C00072929@fh-muenster.de> In-Reply-To: <997A9DE0-5AD2-4991-8D09-7F1C00072929@fh-muenster.de> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.201.113] x-inside-org: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Src-IF-Name: mail.mera.ru Archived-At: Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:46:23 -0000 Hi Michael, Yes, it seems lksctp always puts a new random number into INIT ACK when it = receives INIT.=20 Thanks for your prompt response! BR, Maxim -----Original Message----- From: Michael Tuexen [mailto:tuexen@fh-muenster.de]=20 Sent: Friday, March 1, 2019 16:29 To: Proshin, Maksim Cc: tsvwg@ietf.org Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision > On 1. Mar 2019, at 14:05, Proshin, Maksim wrote: >=20 > Hi Michael, tsvwg, > =20 > I have a doubt about the RANDOM parameter from RFC 4895 which was caused = by interoperability tests with different SCTP implementations. > RFC 4895 has the following text in Section 6.1: > In case > of INIT collision, the rules governing the handling of this Random > Number follow the same pattern as those for the Verification Tag, as > explained in Section 5.2.4 of RFC 2960 [5]. Therefore, each endpoint > knows its own Random Number and the peer's Random Number after the > association has been established. > =20 > and RFC 4960 which obsoletes RFC 2960 has the following statement in Sect= ion 5.2.1: > =20 > Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST > respond with an INIT ACK using the same parameters it sent in its > original INIT chunk (including its Initiate Tag, unchanged). > =20 > Based on those 2 statements I assume that SCTP must always respond with t= he same Random Number when it sends INIT ACK in response to INIT received i= n the COOKIE-WAIT state. Is my understanding correct? =20 Yes, I would say so. Is an open source implementation not following these rules? Best regards Michael > =20 > BR, Maxim From nobody Fri Mar 1 05:48:45 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659F8124BAA for ; Fri, 1 Mar 2019 05:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6zdWmW75V-X for ; Fri, 1 Mar 2019 05:48:40 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4370E130E73 for ; Fri, 1 Mar 2019 05:48:40 -0800 (PST) Received: from [192.168.1.9] (p57BB42E6.dip0.t-ipconnect.de [87.187.66.230]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6A8D5721E281E; Fri, 1 Mar 2019 14:48:36 +0100 (CET) From: Michael Tuexen Message-Id: <05B1E876-F942-4AF6-8DDF-FF77295A2D49@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_B9B501D7-71F3-42A4-82BF-FD58B4B13F76"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Mar 2019 14:48:35 +0100 In-Reply-To: <588a6ab909d14fd78ca8715aec951954@mera.ru> Cc: "tsvwg@ietf.org" To: "Proshin, Maksim" References: <2b50678935f34e25aff2f6b21eca9374@mera.ru> <997A9DE0-5AD2-4991-8D09-7F1C00072929@fh-muenster.de> <588a6ab909d14fd78ca8715aec951954@mera.ru> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:48:43 -0000 --Apple-Mail=_B9B501D7-71F3-42A4-82BF-FD58B4B13F76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 1. Mar 2019, at 14:46, Proshin, Maksim wrote: >=20 > Hi Michael, >=20 > Yes, it seems lksctp always puts a new random number into INIT ACK = when it receives INIT.=20 I see. Did you also test with FreeBSD? However, it seems to be a = motivation to add SCTP-AUTH support to packetdrill... Best regards Michael > Thanks for your prompt response! >=20 > BR, Maxim >=20 > -----Original Message----- > From: Michael Tuexen [mailto:tuexen@fh-muenster.de]=20 > Sent: Friday, March 1, 2019 16:29 > To: Proshin, Maksim > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision >=20 >=20 >=20 >> On 1. Mar 2019, at 14:05, Proshin, Maksim wrote: >>=20 >> Hi Michael, tsvwg, >>=20 >> I have a doubt about the RANDOM parameter from RFC 4895 which was = caused by interoperability tests with different SCTP implementations. >> RFC 4895 has the following text in Section 6.1: >> In case >> of INIT collision, the rules governing the handling of this Random >> Number follow the same pattern as those for the Verification Tag, = as >> explained in Section 5.2.4 of RFC 2960 [5]. Therefore, each = endpoint >> knows its own Random Number and the peer's Random Number after the >> association has been established. >>=20 >> and RFC 4960 which obsoletes RFC 2960 has the following statement in = Section 5.2.1: >>=20 >> Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST >> respond with an INIT ACK using the same parameters it sent in its >> original INIT chunk (including its Initiate Tag, unchanged). >>=20 >> Based on those 2 statements I assume that SCTP must always respond = with the same Random Number when it sends INIT ACK in response to INIT = received in the COOKIE-WAIT state. Is my understanding correct? =20 > Yes, I would say so. >=20 > Is an open source implementation not following these rules? >=20 > Best regards > Michael >>=20 >> BR, Maxim >=20 --Apple-Mail=_B9B501D7-71F3-42A4-82BF-FD58B4B13F76 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEJAw ggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJERTEcMBoG A1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRl cjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQwNzIyMTIwODI2WhcN MTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UE CxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcAW5UidNQg6zSP 1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7 DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycw DQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO7 2uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQAB o4IBhjCCAYIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAf BgNVHSMEGDAWgBQxw3kbuvVT1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1Ud IARbMFkwEQYPKwYBBAGBrSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIs AQEEAwEwDwYNKwYBBAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1o dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEE bDBqMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEF BQcwAoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhthJxb/ w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvNTVx07iHy dQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEsjmpttzUCGc/1 OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6hL5Kp2AvGhB8Exuse 6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtUFzCCBaIwggSKoAMCAQIC BxekJKEJSDMwDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJl aW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcw MTAeFw0xNDA1MjcxNDU0MDlaFw0xOTA3MDkyMzU5MDBaMIHGMQswCQYDVQQGEwJERTEcMBoGA1UE CBMTTm9yZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2ho b2Noc2NodWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEd MBsGA1UEAxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5z dGVyLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuHlsrvBs7CL9IqMH9r//QU9E pghTV/3skHuQZ3DpNY+lyJWOW5zbtUubgXt7lYHpIE4d4CclTZWqCHwoAI6gqzSSGjUKuX6/0ui/ LhXmlDvCBfwuER+T+3/R59hlLnhI5iYYPQiNywQIa3wJhBLTZrlXw8nDdjI54MAzcVDUX7l21sbo ZIA6idM7SXmshxoRQ6xsfPHskrceNMcvtHNDhVnVscwRUJQUR55fs0X7Y93PasugWPv3xmgNr1da Cq94eV+nslNU/GJaT9TQ3uG8pagLXl9NbDNkHIrvFAD5zXO0m/d00I4QhUVQyEtwnTegDqcM+WFh JXensgnZhWe6bwIDAQABo4IB/jCCAfowEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMC AQYwEQYDVR0gBAowCDAGBgRVHSAAMB0GA1UdDgQWBBQK81u85DGA1jVCiabTw8833tHf1zAfBgNV HSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAcBgNVHREEFTATgRFjYUBmaC1tdWVuc3Rlci5k ZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3Qt Y2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFs LXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHKMIHHMDMGCCsGAQUFBzAB hidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0 dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEA3kcDNdZKb7kSD7s1ly2qa/2QbQe+ ld3LhZeOcfysdLtN8oweBmgT3MYoZ+D9c+SoUWJAwTKPB15DoGy+fWhelXTpQrqxIGb4ISr1JCjg slnmMUva0xjwZGxojZ9gE1bi18xfKw3+dMpwCLt6LbLTjr/tyH6otacwr2tZzuuJIUAORnefwTcr vmB21n/BEQH/ZXruWu8lSO3L9YAmQB6ViaZFCpn2sMmOLACdoWxmUQb3QAjsa327jHUjsz53k9q5 Zrx/g+zOg5s1Wmy2JOlLQMUIZXXf0/6rB5Fr2llx7dBG/Uk7NhZdNy7OzNzci0C4Wnkd8rDVEWHG hH2gfpcTfjCCBg0wggT1oAMCAQICBxuZiHQ3saMwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNVBAYT AkRFMRwwGgYDVQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4G A1UEChMXRmFjaGhvY2hzY2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5n c3plbnRyYWxlMR0wGwYDVQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYR Y2FAZmgtbXVlbnN0ZXIuZGUwHhcNMTYwNzA0MDcwNjEzWhcNMTkwNzA0MDcwNjEzWjB8MQswCQYD VQQGEwJERTEgMB4GA1UECgwXRmFjaGhvY2hzY2h1bGUgTXVlbnN0ZXIxMjAwBgNVBAsMKUZhY2hi ZXJlaWNoIEVsZWt0cm90ZWNobmlrIHVuZCBJbmZvcm1hdGlrMRcwFQYDVQQDDA5NaWNoYWVsIFR1 ZXhlbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMyaGlBt2ZtuF8QP8zYNrGxXC+es PMajIPl+hu1LGHnN2BJ3J5ZMN44BOZw3n6LO1FaAgO8D4xU4/AELecX6VxJZ2zOOSD8uTYO4OnUu 24hkjFUQAj13tT644AKUQMMBpgj7wC52V5Jij+mZX/t1S38/WFiCGnirt4xTNi5OmN4K+VNZfG4x 0msDqFjJX70rF1y09/Mylu1M/Y0tu/I9DqhwDQT4LBOvyyaAlhSJ8Jb8m8YTt5xlOzrXlBmj4pKs 74y7C2IKRw4tFozGX1cf1LVEs2eBCb5iUwXrlcMipwm62sJ38GD00EOlRNTpAM5rDAcgWxMCffek bRv/01whtOkCAwEAAaOCAkcwggJDMEAGA1UdIAQ5MDcwEQYPKwYBBAGBrSGCLAEBBAMFMBEGDysG AQQBga0hgiwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgXg MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU0B2vaoSoEmYAggD04WZF 2hGif3UwHwYDVR0jBBgwFoAUCvNbvOQxgNY1Qomm08PPN97R39cwIAYDVR0RBBkwF4EVdHVleGVu QGZoLW11ZW5zdGVyLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9maC1tdWVuc3Rlci1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNh LmRmbi5kZS9maC1tdWVuc3Rlci1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcow gccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBH BggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9maC1tdWVuc3Rlci1jYS9wdWIvY2Fj ZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZmgtbXVl bnN0ZXItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBI9v+seJM6 AlSIrmmpopz6zh8QAsqGLJkkY2D0KYFucUY/xZaJTtZxvmWddbKk2903Qhg+vZKOf87PHhip7/4t FSwhxYNSS36WsRJTeUa0f3KkSa28yrIRfWlJATgxfL5X/QQnopjCt34n4221kcsR7LHxBAn37ow+ /2L7WjWDDuOkaM9/ZSCtrN+yFRat1eUVs1Hk7sKT/bfJTsYqzovXitjmCP3YdB40dkuQ6/ZzEdXT bpa4c45RcRnPqKXnxknK0UfRHNHqk15W7dUPVMzSGFUvjhmWPP2wW6a8F1U5sEqfHcoBFC5CGjGy 7Gk2luk3obi/KLrDyZC+dkjhDYEpMYIEOTCCBDUCAQEwgdIwgcYxCzAJBgNVBAYTAkRFMRwwGgYD VQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFj aGhvY2hzY2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxl MR0wGwYDVQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVl bnN0ZXIuZGUCBxuZiHQ3saMwDQYJYIZIAWUDBAIBBQCgggI3MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMwMTEzNDgzNVowLwYJKoZIhvcNAQkEMSIEII3ii0/D NmVJ+O0ZFWXFIaX+rLrScq7vFfhoHrdI/npIMIHjBgkrBgEEAYI3EAQxgdUwgdIwgcYxCzAJBgNV BAYTAkRFMRwwGgYDVQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEg MB4GA1UEChMXRmFjaGhvY2hzY2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0 dW5nc3plbnRyYWxlMR0wGwYDVQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJ ARYRY2FAZmgtbXVlbnN0ZXIuZGUCBxuZiHQ3saMwgeUGCyqGSIb3DQEJEAILMYHVoIHSMIHGMQsw CQYDVQQGEwJERTEcMBoGA1UECBMTTm9yZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0 ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2NodWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFy YmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UEAxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG 9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRlAgcbmYh0N7GjMA0GCSqGSIb3DQEBAQUABIIBAMrOZa/F eE7oSS8XYd0V0vWKXrHOmXQjkhXMT9JxajLoH/VN5pxEwzxmHIn8CbClKH9XkrpUV2FYWWXsWWPw 8drfjQ8kjNwIslvVP4mXMJxCHpBxxtgtOEOs0tMk9yZBlV5bECmlfvd7w2A/FvaVJzXPjtdMSLEb i4QCY3Y/GxsvxO/OslpJLbKFJlulKa5U0XV2Tdg0RFJkFUZe6vIwy81aL4Fjl7EO+vXcZ4i9yI1g OLOVSmJbhddogZEYSpKW7OOsv97Erb4OZ8DojEeeHWABctyI7wrSKFeqOjStfZdIrM2JYWKaVUF+ jWkFZ3FxRHYboldfYHjnn2KScMlFA7QAAAAAAAA= --Apple-Mail=_B9B501D7-71F3-42A4-82BF-FD58B4B13F76-- From nobody Fri Mar 1 05:56:21 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87412130E81 for ; Fri, 1 Mar 2019 05:56:19 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bIFiwjyWXcA for ; Fri, 1 Mar 2019 05:56:17 -0800 (PST) Received: from mail.mera.ru (mail.mera.ru [188.130.168.162]) (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 9103D130E79 for ; Fri, 1 Mar 2019 05:56:17 -0800 (PST) Received: from e16srv01.merann.ru ([192.168.50.31]) by mail.mera.ru with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (envelope-from ) id 1gzidN-000Ar7-9L; Fri, 01 Mar 2019 16:55:29 +0300 Received: from e16srv03.merann.ru (2001:67c:2344:50::33) by e16srv01.merann.ru (2001:67c:2344:50::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1591.10; Fri, 1 Mar 2019 16:56:14 +0300 Received: from e16srv03.merann.ru ([fe80::2cb7:1925:fc4a:82dc]) by e16srv03.merann.ru ([fe80::2cb7:1925:fc4a:82dc%12]) with mapi id 15.01.1591.012; Fri, 1 Mar 2019 16:56:14 +0300 From: "Proshin, Maksim" To: Michael Tuexen CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] SCTP RANDOM parameter in case of INIT collision Thread-Index: AdTQLVHtlActtV+uQSOp8/Lo4JDYOv//2JSA///KAxCAADtogP//zKIw Date: Fri, 1 Mar 2019 13:56:04 +0000 Deferred-Delivery: Fri, 1 Mar 2019 13:55:36 +0000 Message-ID: References: <2b50678935f34e25aff2f6b21eca9374@mera.ru> <997A9DE0-5AD2-4991-8D09-7F1C00072929@fh-muenster.de> <588a6ab909d14fd78ca8715aec951954@mera.ru> <05B1E876-F942-4AF6-8DDF-FF77295A2D49@fh-muenster.de> In-Reply-To: <05B1E876-F942-4AF6-8DDF-FF77295A2D49@fh-muenster.de> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.201.113] x-inside-org: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Src-IF-Name: mail.mera.ru Archived-At: Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:56:20 -0000 No, FreeBSD is not tested yet. BR, Maxim -----Original Message----- From: Michael Tuexen [mailto:tuexen@fh-muenster.de]=20 Sent: Friday, March 1, 2019 16:49 To: Proshin, Maksim Cc: tsvwg@ietf.org Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision > On 1. Mar 2019, at 14:46, Proshin, Maksim wrote: >=20 > Hi Michael, >=20 > Yes, it seems lksctp always puts a new random number into INIT ACK when i= t receives INIT.=20 I see. Did you also test with FreeBSD? However, it seems to be a motivation= to add SCTP-AUTH support to packetdrill... Best regards Michael > Thanks for your prompt response! >=20 > BR, Maxim >=20 > -----Original Message----- > From: Michael Tuexen [mailto:tuexen@fh-muenster.de]=20 > Sent: Friday, March 1, 2019 16:29 > To: Proshin, Maksim > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision >=20 >=20 >=20 >> On 1. Mar 2019, at 14:05, Proshin, Maksim wrote: >>=20 >> Hi Michael, tsvwg, >>=20 >> I have a doubt about the RANDOM parameter from RFC 4895 which was caused= by interoperability tests with different SCTP implementations. >> RFC 4895 has the following text in Section 6.1: >> In case >> of INIT collision, the rules governing the handling of this Random >> Number follow the same pattern as those for the Verification Tag, as >> explained in Section 5.2.4 of RFC 2960 [5]. Therefore, each endpoint >> knows its own Random Number and the peer's Random Number after the >> association has been established. >>=20 >> and RFC 4960 which obsoletes RFC 2960 has the following statement in Sec= tion 5.2.1: >>=20 >> Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST >> respond with an INIT ACK using the same parameters it sent in its >> original INIT chunk (including its Initiate Tag, unchanged). >>=20 >> Based on those 2 statements I assume that SCTP must always respond with = the same Random Number when it sends INIT ACK in response to INIT received = in the COOKIE-WAIT state. Is my understanding correct? =20 > Yes, I would say so. >=20 > Is an open source implementation not following these rules? >=20 > Best regards > Michael >>=20 >> BR, Maxim >=20 From nobody Fri Mar 1 05:57:56 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B90130E7B for ; Fri, 1 Mar 2019 05:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiGiBqr3PH0e for ; Fri, 1 Mar 2019 05:57:52 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEA0130E81 for ; Fri, 1 Mar 2019 05:57:51 -0800 (PST) Received: from [192.168.1.9] (p57BB42E6.dip0.t-ipconnect.de [87.187.66.230]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7185B721E281E; Fri, 1 Mar 2019 14:57:47 +0100 (CET) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4F2A356B-326B-40E6-87CC-CC815314A5BA"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Mar 2019 14:57:46 +0100 In-Reply-To: Cc: "tsvwg@ietf.org" To: "Proshin, Maksim" References: <2b50678935f34e25aff2f6b21eca9374@mera.ru> <997A9DE0-5AD2-4991-8D09-7F1C00072929@fh-muenster.de> <588a6ab909d14fd78ca8715aec951954@mera.ru> <05B1E876-F942-4AF6-8DDF-FF77295A2D49@fh-muenster.de> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:57:55 -0000 --Apple-Mail=_4F2A356B-326B-40E6-87CC-CC815314A5BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 1. Mar 2019, at 14:56, Proshin, Maksim wrote: >=20 > No, FreeBSD is not tested yet. OK. If you test it and find problem, drop me an email. Best regards Michael >=20 > BR, Maxim >=20 > -----Original Message----- > From: Michael Tuexen [mailto:tuexen@fh-muenster.de]=20 > Sent: Friday, March 1, 2019 16:49 > To: Proshin, Maksim > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision >=20 >> On 1. Mar 2019, at 14:46, Proshin, Maksim wrote: >>=20 >> Hi Michael, >>=20 >> Yes, it seems lksctp always puts a new random number into INIT ACK = when it receives INIT.=20 > I see. Did you also test with FreeBSD? However, it seems to be a = motivation to add SCTP-AUTH > support to packetdrill... >=20 > Best regards > Michael >> Thanks for your prompt response! >>=20 >> BR, Maxim >>=20 >> -----Original Message----- >> From: Michael Tuexen [mailto:tuexen@fh-muenster.de]=20 >> Sent: Friday, March 1, 2019 16:29 >> To: Proshin, Maksim >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision >>=20 >>=20 >>=20 >>> On 1. Mar 2019, at 14:05, Proshin, Maksim wrote: >>>=20 >>> Hi Michael, tsvwg, >>>=20 >>> I have a doubt about the RANDOM parameter from RFC 4895 which was = caused by interoperability tests with different SCTP implementations. >>> RFC 4895 has the following text in Section 6.1: >>> In case >>> of INIT collision, the rules governing the handling of this Random >>> Number follow the same pattern as those for the Verification Tag, = as >>> explained in Section 5.2.4 of RFC 2960 [5]. Therefore, each = endpoint >>> knows its own Random Number and the peer's Random Number after the >>> association has been established. >>>=20 >>> and RFC 4960 which obsoletes RFC 2960 has the following statement in = Section 5.2.1: >>>=20 >>> Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST >>> respond with an INIT ACK using the same parameters it sent in its >>> original INIT chunk (including its Initiate Tag, unchanged). >>>=20 >>> Based on those 2 statements I assume that SCTP must always respond = with the same Random Number when it sends INIT ACK in response to INIT = received in the COOKIE-WAIT state. Is my understanding correct? =20 >> Yes, I would say so. >>=20 >> Is an open source implementation not following these rules? >>=20 >> Best regards >> Michael >>>=20 >>> BR, Maxim >>=20 >=20 --Apple-Mail=_4F2A356B-326B-40E6-87CC-CC815314A5BA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEJAw ggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJERTEcMBoG A1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRl cjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQwNzIyMTIwODI2WhcN MTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UE CxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcAW5UidNQg6zSP 1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7 DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycw DQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO7 2uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQAB o4IBhjCCAYIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAf BgNVHSMEGDAWgBQxw3kbuvVT1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1Ud IARbMFkwEQYPKwYBBAGBrSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIs AQEEAwEwDwYNKwYBBAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1o dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEE bDBqMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEF BQcwAoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhthJxb/ w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvNTVx07iHy dQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEsjmpttzUCGc/1 OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6hL5Kp2AvGhB8Exuse 6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtUFzCCBaIwggSKoAMCAQIC BxekJKEJSDMwDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJl aW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcw MTAeFw0xNDA1MjcxNDU0MDlaFw0xOTA3MDkyMzU5MDBaMIHGMQswCQYDVQQGEwJERTEcMBoGA1UE CBMTTm9yZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2ho b2Noc2NodWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEd MBsGA1UEAxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5z dGVyLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuHlsrvBs7CL9IqMH9r//QU9E pghTV/3skHuQZ3DpNY+lyJWOW5zbtUubgXt7lYHpIE4d4CclTZWqCHwoAI6gqzSSGjUKuX6/0ui/ LhXmlDvCBfwuER+T+3/R59hlLnhI5iYYPQiNywQIa3wJhBLTZrlXw8nDdjI54MAzcVDUX7l21sbo ZIA6idM7SXmshxoRQ6xsfPHskrceNMcvtHNDhVnVscwRUJQUR55fs0X7Y93PasugWPv3xmgNr1da Cq94eV+nslNU/GJaT9TQ3uG8pagLXl9NbDNkHIrvFAD5zXO0m/d00I4QhUVQyEtwnTegDqcM+WFh JXensgnZhWe6bwIDAQABo4IB/jCCAfowEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMC AQYwEQYDVR0gBAowCDAGBgRVHSAAMB0GA1UdDgQWBBQK81u85DGA1jVCiabTw8833tHf1zAfBgNV HSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAcBgNVHREEFTATgRFjYUBmaC1tdWVuc3Rlci5k ZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3Qt Y2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFs LXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHKMIHHMDMGCCsGAQUFBzAB hidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0 dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEA3kcDNdZKb7kSD7s1ly2qa/2QbQe+ ld3LhZeOcfysdLtN8oweBmgT3MYoZ+D9c+SoUWJAwTKPB15DoGy+fWhelXTpQrqxIGb4ISr1JCjg slnmMUva0xjwZGxojZ9gE1bi18xfKw3+dMpwCLt6LbLTjr/tyH6otacwr2tZzuuJIUAORnefwTcr vmB21n/BEQH/ZXruWu8lSO3L9YAmQB6ViaZFCpn2sMmOLACdoWxmUQb3QAjsa327jHUjsz53k9q5 Zrx/g+zOg5s1Wmy2JOlLQMUIZXXf0/6rB5Fr2llx7dBG/Uk7NhZdNy7OzNzci0C4Wnkd8rDVEWHG hH2gfpcTfjCCBg0wggT1oAMCAQICBxuZiHQ3saMwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNVBAYT AkRFMRwwGgYDVQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4G A1UEChMXRmFjaGhvY2hzY2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5n c3plbnRyYWxlMR0wGwYDVQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYR Y2FAZmgtbXVlbnN0ZXIuZGUwHhcNMTYwNzA0MDcwNjEzWhcNMTkwNzA0MDcwNjEzWjB8MQswCQYD VQQGEwJERTEgMB4GA1UECgwXRmFjaGhvY2hzY2h1bGUgTXVlbnN0ZXIxMjAwBgNVBAsMKUZhY2hi ZXJlaWNoIEVsZWt0cm90ZWNobmlrIHVuZCBJbmZvcm1hdGlrMRcwFQYDVQQDDA5NaWNoYWVsIFR1 ZXhlbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMyaGlBt2ZtuF8QP8zYNrGxXC+es PMajIPl+hu1LGHnN2BJ3J5ZMN44BOZw3n6LO1FaAgO8D4xU4/AELecX6VxJZ2zOOSD8uTYO4OnUu 24hkjFUQAj13tT644AKUQMMBpgj7wC52V5Jij+mZX/t1S38/WFiCGnirt4xTNi5OmN4K+VNZfG4x 0msDqFjJX70rF1y09/Mylu1M/Y0tu/I9DqhwDQT4LBOvyyaAlhSJ8Jb8m8YTt5xlOzrXlBmj4pKs 74y7C2IKRw4tFozGX1cf1LVEs2eBCb5iUwXrlcMipwm62sJ38GD00EOlRNTpAM5rDAcgWxMCffek bRv/01whtOkCAwEAAaOCAkcwggJDMEAGA1UdIAQ5MDcwEQYPKwYBBAGBrSGCLAEBBAMFMBEGDysG AQQBga0hgiwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgXg MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU0B2vaoSoEmYAggD04WZF 2hGif3UwHwYDVR0jBBgwFoAUCvNbvOQxgNY1Qomm08PPN97R39cwIAYDVR0RBBkwF4EVdHVleGVu QGZoLW11ZW5zdGVyLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9maC1tdWVuc3Rlci1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNh LmRmbi5kZS9maC1tdWVuc3Rlci1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcow gccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBH BggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9maC1tdWVuc3Rlci1jYS9wdWIvY2Fj ZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZmgtbXVl bnN0ZXItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBI9v+seJM6 AlSIrmmpopz6zh8QAsqGLJkkY2D0KYFucUY/xZaJTtZxvmWddbKk2903Qhg+vZKOf87PHhip7/4t FSwhxYNSS36WsRJTeUa0f3KkSa28yrIRfWlJATgxfL5X/QQnopjCt34n4221kcsR7LHxBAn37ow+ /2L7WjWDDuOkaM9/ZSCtrN+yFRat1eUVs1Hk7sKT/bfJTsYqzovXitjmCP3YdB40dkuQ6/ZzEdXT bpa4c45RcRnPqKXnxknK0UfRHNHqk15W7dUPVMzSGFUvjhmWPP2wW6a8F1U5sEqfHcoBFC5CGjGy 7Gk2luk3obi/KLrDyZC+dkjhDYEpMYIEOTCCBDUCAQEwgdIwgcYxCzAJBgNVBAYTAkRFMRwwGgYD VQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFj aGhvY2hzY2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxl MR0wGwYDVQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVl bnN0ZXIuZGUCBxuZiHQ3saMwDQYJYIZIAWUDBAIBBQCgggI3MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMwMTEzNTc0NlowLwYJKoZIhvcNAQkEMSIEIPM/v+Ts kx4AZ3SubHv8evIDTEkPeIraZXeZedt5KyNRMIHjBgkrBgEEAYI3EAQxgdUwgdIwgcYxCzAJBgNV BAYTAkRFMRwwGgYDVQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEg MB4GA1UEChMXRmFjaGhvY2hzY2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0 dW5nc3plbnRyYWxlMR0wGwYDVQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJ ARYRY2FAZmgtbXVlbnN0ZXIuZGUCBxuZiHQ3saMwgeUGCyqGSIb3DQEJEAILMYHVoIHSMIHGMQsw CQYDVQQGEwJERTEcMBoGA1UECBMTTm9yZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0 ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2NodWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFy YmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UEAxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG 9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRlAgcbmYh0N7GjMA0GCSqGSIb3DQEBAQUABIIBAGFwlCUc k8XILhtYPmTdMzzGoAy/IemfiWisRtVyCe/02FYoEjb+8QnWHzd4Qjpui+WreFN/WvJhm1klllvM KtoDpZAfQfwDXjwp1PMp41nkxKFzD/A08udhHL0ii2uAsoeAdS3IneS8psNVl7KJVqitAeYiSSQS zKE4Z0XTiC/1ozCZBCwpnQ5FCzqsD8pBDKJKwvNsP6Z0HKv7c25TXcLLSa/ivPOABxCRjHsubWP2 plpcnn7ONO+gGmdD3KNIawnG4g38lrv2GJDzx/EY+chCIIDcnOmMvgnjVkPn4VzF5eu7OWXQgN4m tt9sDc7jP9UZlYf10dqKnC8ZiYFyhZUAAAAAAAA= --Apple-Mail=_4F2A356B-326B-40E6-87CC-CC815314A5BA-- From nobody Fri Mar 1 13:19:36 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FAA130F20; Fri, 1 Mar 2019 13:10:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tsvwg@ietf.org, spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147461774.6101.3335034080841286022.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:17 -0800 Archived-At: Subject: [tsvwg] tsvwg - Requested sessions have been scheduled for IETF 104 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:35 -0000 Dear Gorry Fairhurst, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tsvwg Session 1 (2:00 requested) Monday, 25 March 2019, Afternoon Session II 1610-1810 Room Name: Congress Hall 1 size: 250 --------------------------------------------- tsvwg Session 2 (1:00 requested) Tuesday, 26 March 2019, Morning Session II 1120-1220 Room Name: Congress Hall 3 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/tsvwg.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Area Working Group Area Name: Transport Area Session Requester: Gorry Fairhurst Number of Sessions: 2 Length of Session(s): 1 Hour, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: opsarea rtgwg tcpinc quic ippm taps mptcp tcpm rmcat iccrg tsvarea intarea saag detnet 6man Second Priority: dtn rtcweb v6ops tram dispatch Third Priority: artarea ccamp People who must be present: David L. Black Gorry Fairhurst Spencer Dawkins Wesley Eddy Mirja Kuehlewind Resources Requested: Special Requests: Must not conflict with Transport Area BoFs. Either the 1 hour or 2 hour session may be timetabled first. --------------------------------------------------------- From nobody Sun Mar 3 06:27:10 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C74A12870E for ; Sun, 3 Mar 2019 06:27:09 -0800 (PST) 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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRkQ-wFi-h-e for ; Sun, 3 Mar 2019 06:27:07 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 37D76126D00 for ; Sun, 3 Mar 2019 06:27:06 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8B2011B00243 for ; Sun, 3 Mar 2019 14:27:03 +0000 (GMT) Message-ID: <5C7BE437.8000700@erg.abdn.ac.uk> Date: Sun, 03 Mar 2019 14:27:03 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "tsvwg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] TSVWG has been allocated agenda slots at the next IETF. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 14:27:10 -0000 Hi TSVWG'ers, This is a request for people with topics they think it would be useful to be presented to the TSVWG working group at the Prague IETF. If you edit a WG draft, we expect an update. Please do let us know how much time you think is needed, and the key points to be addressed. If you wish to present on another topic, or another non-WG draft please contact and let us know what you would like to present. Please also be sure to discuss the topic on the tsvwg prior to this meeting. As ever, priority, as ever will be given to drafts that have been discussed on the list and that are expected to benefit from WG discussion time. The session(s) are: tsvwg Session 1 Monday, 25 March 2019, Afternoon Session II 1610-1810 Room Name: Congress Hall 1 --------------------------------------------- tsvwg Session 2 Tuesday, 26 March 2019, Morning Session II 1120-1220 Room Name: Congress Hall 3 --------------------------------------------- iCalendar:https://datatracker.ietf.org/meeting/104/sessions/tsvwg.ics Gorry, David and Wes (TSVWG Co-Chairs) From nobody Mon Mar 4 00:05:50 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A21131031; Mon, 4 Mar 2019 00:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IXIbh22kHqb; Mon, 4 Mar 2019 00:05:46 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id BDEA2130FC7; Mon, 4 Mar 2019 00:05:45 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5F8801B00161; Mon, 4 Mar 2019 08:05:35 +0000 (GMT) Message-ID: <5C7CDC4E.3050606@erg.abdn.ac.uk> Date: Mon, 04 Mar 2019 08:05:34 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Spencer Dawkins at IETF CC: "BRUNGARD, DEBORAH A" , "Bless, Roland (TM)" , Brian E Carpenter , Warren Kumari , "tsvwg@ietf.org" , IESG , tsvwg-chairs References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 08:05:49 -0000 I have had a little reflexion on the discussion and I quite agree the following needs pruned/rewritten: “However, non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to L, on a regular basis without consent or knowledge of the user.” And I do agree with pruning this from the normative text: “on a regular basis without consent or knowledge of the user.” However, even though the original had become a little gabled, it was an attempt to capture that there *ARE* implications. We spent time talking about these implications in the WG and a lot of time trying to write text to avoid accidental remarking. I am still somewhat unclear how an operator could safely just map traffic to the LE class, without a priori knowing what the flow expects. Sure, an operator could setup a BA-classifier and understand that application “X” wants this service. If it does that then that traffic will receive the treatment of LE traffic for the rest of the path. If I understood the intention, it was to remind people that this isn’t just another “lower level” in the diffserv hierarchy - traffic mapped to this class needs to be resilient to starvation, and expect that this will happen. I suggest an explanation could be added after the clause to be pruned to avoid this not working out well: “Remarking traffic from another PHB results in that traffic being "downgraded”. This changes the way the network treats this traffic and it is important not to violate the operational objectives of the original PHB.” Gorry P.S. Roland, I also just saw a few clauses saying “In case ....”, I don’t know how I missed that in my review, but these read ambiguously to me: I could it would be better if the phrase was “In the case that”. On 28/02/2019, 18:30, Spencer Dawkins at IETF wrote: > Thanks, Deborah! > > Roland, could you submit an updated version of this draft, so I can approve > it before Wednesday of IETF 104? :-) > > Thanks, > > Spencer > > On Thu, Feb 28, 2019 at 10:18 AM BRUNGARD, DEBORAH A wrote: > >> Yes, I’m ok with the abbreviated sentence as Warren and others suggested >> “"Non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to LE." >> >> >> >> Thanks everyone- >> >> Deborah >> >> >> >> *From:* Spencer Dawkins at IETF >> *Sent:* Thursday, February 28, 2019 9:27 AM >> *To:* Bless, Roland (TM) >> *Cc:* Brian E Carpenter; Warren Kumari< >> warren@kumari.net>; tsvwg@ietf.org; BRUNGARD, DEBORAH A; >> IESG; tsvwg-chairs >> *Subject:* Re: [tsvwg] Warren Kumari's Discuss on >> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) >> >> >> >> So, Warren/Deborah, are we good on SHOULD NOT here? >> >> >> >> Spencer >> >> >> >> On Thu, Feb 28, 2019 at 2:38 AM Bless, Roland (TM) >> wrote: >> >> Hi, >> >> Am 27.02.19 um 22:44 schrieb Brian E Carpenter: >>> On 28-Feb-19 10:18, Spencer Dawkins at IETF wrote: >>>> Hi, Warren, >>>> >>>> On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari >> wrote: >>>>> >>>>> On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IETF< >>>>> spencerdawkins.ietf@gmail.com> wrote: >>>>> >>>>>> So, just to follow up, >>>>>> >>>>>> On Mon, Feb 25, 2019 at 2:48 AM wrote: >>>>>> >>>>>>> Deborah, Warren, >>>>>>> >>>>>>> IETF doesn't specify SLAs or related text, I agree. The LE >> performance >>>>>>> is worse than default forwarding. I'm unhappy if my peer demotes my >> traffic >>>>>>> to LE and points to an IETF standard allowing this. What about: >>>>>>> >>>>>>> DISCUSSED CHANGE so far: >>>>>>> Non-LE traffic (e.g., BE traffic) SHOULD NOT be >>>>>>> remarked to LE on a regular basis. >>>>>>> >>>>>>> SOMEWHAT MORE PRECISELY DEFINED OPTION >>>>>>> Non-LE traffic (e.g., BE traffic) MUST NOT be >>>>>>> remarked to LE by default. >>>>>>> >>>>>>> I'd like to avoid LE to result in a "default below default" and >> prefer >>>>>>> IETF standards not allow fancy interpretations. >>>>>>> >>>>>> This document was approved on the last telechat, but we're having a >>>>>> Discuss-level discussion about it now, which means that I should be >> taking >>>>>> this conversation very seriously (because "new technical objections >> are >>>>>> always in order"). >>>>>> >>>>>> Am I understanding that >>>>>> >>>>>> - Deborah (and, IIRC, Warren) are thinking that MUST is the wrong >>>>>> answer, because we don't tell operators how to mark traffic in >> their >>>>>> networks, but >>>>>> >>>>>> >>>>> Warren is thinking that, if you provide any sort of SHOULD/MUST >> guidance >>>>> regarding when it is appropriate to mark "abnormal" traffic, you have >> to be >>>>> able to define what you mean by normal and abnormal... >>>>> >>>>> Personally I would think that just: "Non-LE traffic (e.g., BE traffic) >>>>> SHOULD NOT be remarked to LE." (or MUST NOT) without any qualifiers >> would >>>>> be best -- we are not the protocol police and don't have an enforcement >>>>> arm, so we cannot really stop it. Where I think we run into trouble is >>>>> saying "It is OK to do this on Thursdays when there is a half moon and >> the >>>>> wind blows from the South-East, but not at other times" (what if these >> is >>>>> only a slight breeze? Thursday where? or a waxing gibbous moon?) - I >> think >>>>> we should just say "You shouldn't remark",with the understanding that >> some >>>>> will and not open the "under these circumstances" can of worms at all From nobody Mon Mar 4 05:15:24 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B12131177 for ; Mon, 4 Mar 2019 05:15:21 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 4TAxb7m3X24a for ; Mon, 4 Mar 2019 05:15:17 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 CAEC2131174 for ; Mon, 4 Mar 2019 05:15:16 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id y15so4664240wma.0 for ; Mon, 04 Mar 2019 05:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P87nArfexxZhLqMQpN1J1G4fDzD2A+GGcuAuQDKqB6A=; b=gn+ANy1LyOaDEkGv/1YVF12IIOft2LLoE7DwlxX/uxhMpxYdD9KqA16Sid5M73aJBl khlXlvavSJyFqDdsWOr3UTa5CID5znYxXYGdcGASHw1mfbEg535+MhL1fD0OFv+6QxJ9 fDuTNBatwaXQHmFxCeXfkxVZJNQxMkvVUIdhiUsLbx5pSdZ6iNTWlMDZjY38j4IZuwR1 tm3rQ5zXoJrAWUpuk6J5ViJqKOKuaE4TPwo1hfEcng+yEs7VWWW5ip5779g4daUK9QN1 hY9g4VyHJvuRAQN4hcst/jR2V1/vmKkC2WVUBRbTk4GLlN8Q7L9W+vA3hkwHuRf98zvU i8Ig== 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=P87nArfexxZhLqMQpN1J1G4fDzD2A+GGcuAuQDKqB6A=; b=Q3/2hXbvFYkocwgd/p78Y4c+h1xXy+/Ri1e0IdshqSE0ydYITv48M4e/ETKFlWdta2 qHMi6hQWH9E4qJoPsoPul0/Ut65gGtRM8csyPWuFxvV3QwxIRLh7dZgsxpasnc8nmIXG adQLqauYUNqv0/dz1jR9Ave2l918QlN3cBsLTDDpwn6mo2Wr2tfFKRcQGDQc6ZOrvjys 1utnIOO12Sn+yZlmIsT1Ud9YKzyufBit6iaYYOGaxNnnl/v2IZOSj8Log5j7nFGuISVL YdwcOU/rcvstK+NGt/sH9Orhgmkhc5YlnzYY7f238S6vVpNUuL9cAFLXsc/AARp1GGrI rjUg== X-Gm-Message-State: AHQUAua+EgCmO5vppIwMMGE2V26lWn745xBfnRJKWSKpoXbi/843ks/u cMhxzwUx1oqSmcr9HvTv0PnWLYoV8+czjFtEsJCtow== X-Google-Smtp-Source: APXvYqznAUivUZdn60FOYBY03hloiOYXZ4Dt67guL/oeozZAebNr8eupIB680WCQX874KVKwbe0reCXR9dZWedyRMbU= X-Received: by 2002:a1c:2283:: with SMTP id i125mr10991384wmi.24.1551705314193; Mon, 04 Mar 2019 05:15:14 -0800 (PST) MIME-Version: 1.0 References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> <5C7CDC4E.3050606@erg.abdn.ac.uk> In-Reply-To: <5C7CDC4E.3050606@erg.abdn.ac.uk> From: Warren Kumari Date: Mon, 4 Mar 2019 08:15:02 -0500 Message-ID: To: gorry@erg.abdn.ac.uk Cc: "BRUNGARD, DEBORAH A" , "Bless, Roland (TM)" , Brian E Carpenter , IESG , Spencer Dawkins at IETF , tsvwg-chairs , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000c92a40583448c97" Archived-At: Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 13:15:22 -0000 --0000000000000c92a40583448c97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 4, 2019 at 3:05 AM Gorry Fairhurst wrote= : > > > I have had a little reflexion on the discussion and I quite agree the > following needs pruned/rewritten: > > =E2=80=9CHowever, non-LE traffic (e.g., BE traffic) SHOULD NOT be > remarked to L, on a regular basis without consent or knowledge of the > user.=E2=80=9D > > And I do agree with pruning this from the normative text: > =E2=80=9Con a regular basis without consent or knowledge of the > user.=E2=80=9D > > However, even though the original had become a little gabled, > it was an attempt to capture that there *ARE* implications. > We spent time talking about these implications in the WG and > a lot of time trying to write text to avoid accidental remarking. > > I am still somewhat unclear how an operator could safely just map > traffic to the LE class, without a priori knowing what the flow > expects. Sure, an operator could setup a BA-classifier and understan= d > that application =E2=80=9CX=E2=80=9D wants this service. If it does = that then that > traffic will receive the treatment of LE traffic for the rest of the > path. If I understood the intention, it was to remind people that > this isn=E2=80=99t just another =E2=80=9Clower level=E2=80=9D in the= diffserv hierarchy - > traffic mapped to this class needs to be resilient to starvation, > and expect that this will happen. > > I suggest an explanation could be added after the clause to be > pruned to avoid this not working out well: > > =E2=80=9CRemarking traffic from another PHB results in that traffic > being "downgraded=E2=80=9D. This changes the way the network treats = this > traffic and it is important not to violate the operational > objectives of the original PHB.=E2=80=9D That sounds reasonable to me.... W > > Gorry > > P.S. Roland, I also just saw a few clauses saying =E2=80=9CIn case ....= =E2=80=9D, I don=E2=80=99t > know how I missed that in my review, but these read ambiguously to me: I > could it would be better if the phrase was =E2=80=9CIn the case that=E2= =80=9D. > > On 28/02/2019, 18:30, Spencer Dawkins at IETF wrote: > > Thanks, Deborah! > > > > Roland, could you submit an updated version of this draft, so I can > approve > > it before Wednesday of IETF 104? :-) > > > > Thanks, > > > > Spencer > > > > On Thu, Feb 28, 2019 at 10:18 AM BRUNGARD, DEBORAH A > wrote: > > > >> Yes, I=E2=80=99m ok with the abbreviated sentence as Warren and others= suggested > >> =E2=80=9C"Non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to = LE." > >> > >> > >> > >> Thanks everyone- > >> > >> Deborah > >> > >> > >> > >> *From:* Spencer Dawkins at IETF > >> *Sent:* Thursday, February 28, 2019 9:27 AM > >> *To:* Bless, Roland (TM) > >> *Cc:* Brian E Carpenter; Warren Kumari< > >> warren@kumari.net>; tsvwg@ietf.org; BRUNGARD, DEBORAH A >; > >> IESG; tsvwg-chairs > >> *Subject:* Re: [tsvwg] Warren Kumari's Discuss on > >> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) > >> > >> > >> > >> So, Warren/Deborah, are we good on SHOULD NOT here? > >> > >> > >> > >> Spencer > >> > >> > >> > >> On Thu, Feb 28, 2019 at 2:38 AM Bless, Roland (TM) > > >> wrote: > >> > >> Hi, > >> > >> Am 27.02.19 um 22:44 schrieb Brian E Carpenter: > >>> On 28-Feb-19 10:18, Spencer Dawkins at IETF wrote: > >>>> Hi, Warren, > >>>> > >>>> On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari > >> wrote: > >>>>> > >>>>> On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IETF< > >>>>> spencerdawkins.ietf@gmail.com> wrote: > >>>>> > >>>>>> So, just to follow up, > >>>>>> > >>>>>> On Mon, Feb 25, 2019 at 2:48 AM wrote: > >>>>>> > >>>>>>> Deborah, Warren, > >>>>>>> > >>>>>>> IETF doesn't specify SLAs or related text, I agree. The LE > >> performance > >>>>>>> is worse than default forwarding. I'm unhappy if my peer demotes = my > >> traffic > >>>>>>> to LE and points to an IETF standard allowing this. What about: > >>>>>>> > >>>>>>> DISCUSSED CHANGE so far: > >>>>>>> Non-LE traffic (e.g., BE traffic) SHOULD NOT be > >>>>>>> remarked to LE on a regular basis. > >>>>>>> > >>>>>>> SOMEWHAT MORE PRECISELY DEFINED OPTION > >>>>>>> Non-LE traffic (e.g., BE traffic) MUST NOT be > >>>>>>> remarked to LE by default. > >>>>>>> > >>>>>>> I'd like to avoid LE to result in a "default below default" and > >> prefer > >>>>>>> IETF standards not allow fancy interpretations. > >>>>>>> > >>>>>> This document was approved on the last telechat, but we're having = a > >>>>>> Discuss-level discussion about it now, which means that I should b= e > >> taking > >>>>>> this conversation very seriously (because "new technical objection= s > >> are > >>>>>> always in order"). > >>>>>> > >>>>>> Am I understanding that > >>>>>> > >>>>>> - Deborah (and, IIRC, Warren) are thinking that MUST is the > wrong > >>>>>> answer, because we don't tell operators how to mark traffic in > >> their > >>>>>> networks, but > >>>>>> > >>>>>> > >>>>> Warren is thinking that, if you provide any sort of SHOULD/MUST > >> guidance > >>>>> regarding when it is appropriate to mark "abnormal" traffic, you ha= ve > >> to be > >>>>> able to define what you mean by normal and abnormal... > >>>>> > >>>>> Personally I would think that just: "Non-LE traffic (e.g., BE > traffic) > >>>>> SHOULD NOT be remarked to LE." (or MUST NOT) without any qualifiers > >> would > >>>>> be best -- we are not the protocol police and don't have an > enforcement > >>>>> arm, so we cannot really stop it. Where I think we run into trouble > is > >>>>> saying "It is OK to do this on Thursdays when there is a half moon > and > >> the > >>>>> wind blows from the South-East, but not at other times" (what if > these > >> is > >>>>> only a slight breeze? Thursday where? or a waxing gibbous moon?) - = I > >> think > >>>>> we should just say "You shouldn't remark",with the understanding th= at > >> some > >>>>> will and not open the "under these circumstances" can of worms at a= ll > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000000c92a40583448c97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 4, 2019 at 3:05 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:


I have had a little reflexion on the discussion and I quite agree the
following needs pruned/rewritten:

=E2=80=9CHowever, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to L, on a regular basis without consent or knowledge of the
user.=E2=80=9D

=C2=A0 =C2=A0 =C2=A0And I do agree with pruning this from the normative tex= t:
=C2=A0 =C2=A0 =C2=A0=E2=80=9Con a regular basis without consent or knowledg= e of the
=C2=A0 =C2=A0 =C2=A0user.=E2=80=9D

=C2=A0 =C2=A0 =C2=A0However, even though the original had become a little g= abled,
=C2=A0 =C2=A0 =C2=A0it was an attempt to capture that there *ARE* implicati= ons.
=C2=A0 =C2=A0 =C2=A0We spent time talking about these implications in the W= G and
=C2=A0 =C2=A0 =C2=A0a lot of time trying to write text to avoid accidental = remarking.

=C2=A0 =C2=A0 =C2=A0I am still somewhat unclear how an operator could safel= y just map
=C2=A0 =C2=A0 =C2=A0traffic to the LE=C2=A0 =C2=A0class, without a priori k= nowing what the flow
=C2=A0 =C2=A0 =C2=A0expects. Sure, an operator could setup a BA-classifier = and understand
=C2=A0 =C2=A0 =C2=A0that application =E2=80=9CX=E2=80=9D wants this service= . If it does that then that
=C2=A0 =C2=A0 =C2=A0traffic will receive the treatment of LE traffic for th= e rest of the
=C2=A0 =C2=A0 =C2=A0path. If I understood the intention, it was to remind p= eople that
=C2=A0 =C2=A0 =C2=A0this isn=E2=80=99t just another =E2=80=9Clower level=E2= =80=9D in the diffserv hierarchy -
=C2=A0 =C2=A0 =C2=A0traffic mapped to this class needs to be resilient to s= tarvation,
=C2=A0 =C2=A0 =C2=A0and expect that this will happen.

=C2=A0 =C2=A0 =C2=A0I suggest an explanation could be added after the claus= e to be
=C2=A0 =C2=A0 =C2=A0pruned to avoid this not working out well:

=C2=A0 =C2=A0 =C2=A0=E2=80=9CRemarking traffic from another PHB results in = that traffic
=C2=A0 =C2=A0 =C2=A0being "downgraded=E2=80=9D. This changes the way t= he network treats this
=C2=A0 =C2=A0 =C2=A0traffic and it is important not to violate the operatio= nal
=C2=A0 =C2=A0 =C2=A0objectives of the original PHB.=E2=80=9D

That sounds reasonable to me...= .

W



Gorry

P.S. Roland, I also just saw a few clauses saying =E2=80=9CIn case ....=E2= =80=9D, I don=E2=80=99t
know how I missed that in my review, but these read ambiguously to me: I could it would be better if the phrase was =E2=80=9CIn the case that=E2=80= =9D.

On 28/02/2019, 18:30, Spencer Dawkins at IETF wrote:
> Thanks, Deborah!
>
> Roland, could you submit an updated version of this draft, so I can ap= prove
> it before Wednesday of IETF 104? :-)
>
> Thanks,
>
> Spencer
>
> On Thu, Feb 28, 2019 at 10:18 AM BRUNGARD, DEBORAH A<db3546@att.com>=C2=A0 wrote: >
>> Yes, I=E2=80=99m ok with the abbreviated sentence as Warren and ot= hers suggested
>> =E2=80=9C"Non-LE traffic (e.g., BE traffic) SHOULD NOT be rem= arked to LE."
>>
>>
>>
>> Thanks everyone-
>>
>> Deborah
>>
>>
>>
>> *From:* Spencer Dawkins at IETF<spencerdawkins.ietf@gmail.com> >> *Sent:* Thursday, February 28, 2019 9:27 AM
>> *To:* Bless, Roland (TM)<roland.bless@kit.edu>
>> *Cc:* Brian E Carpenter<brian.e.carpenter@gmail.com>; Warren Kumar= i<
>> warren@kuma= ri.net>; tsvwg@i= etf.org; BRUNGARD, DEBORAH A<db3546@att.com>;
>> IESG<iesg@ie= tf.org>; tsvwg-chairs<tsvwg-chairs@ietf.org>
>> *Subject:* Re: [tsvwg] Warren Kumari's Discuss on
>> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
>>
>>
>>
>> So, Warren/Deborah, are we good on SHOULD NOT here?
>>
>>
>>
>> Spencer
>>
>>
>>
>> On Thu, Feb 28, 2019 at 2:38 AM Bless, Roland (TM)<roland.bless@kit.edu><= br> >> wrote:
>>
>> Hi,
>>
>> Am 27.02.19 um 22:44 schrieb Brian E Carpenter:
>>> On 28-Feb-19 10:18, Spencer Dawkins at IETF wrote:
>>>> Hi, Warren,
>>>>
>>>> On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari<warren@kumari.net> >> wrote:
>>>>>
>>>>> On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IE= TF<
>>>>> spencerdawkins.ietf@gmail.com>=C2=A0 wrote:
>>>>>
>>>>>> So, just to follow up,
>>>>>>
>>>>>> On Mon, Feb 25, 2019 at 2:48 AM<Ruediger.Geib@telekom.de= >=C2=A0 wrote:
>>>>>>
>>>>>>> Deborah, Warren,
>>>>>>>
>>>>>>> IETF doesn't specify SLAs or related text,= I agree. The LE
>> performance
>>>>>>> is worse than default forwarding. I'm unha= ppy if my peer demotes my
>> traffic
>>>>>>> to LE and points to an IETF standard allowing = this.=C2=A0 What about:
>>>>>>>
>>>>>>> DISCUSSED CHANGE so far:
>>>>>>> Non-LE traffic (e.g., BE traffic) SHOULD NOT b= e
>>>>>>> remarked to LE on a regular basis.
>>>>>>>
>>>>>>> SOMEWHAT MORE PRECISELY DEFINED OPTION
>>>>>>> Non-LE traffic (e.g., BE traffic) MUST NOT be<= br> >>>>>>> remarked to LE by default.
>>>>>>>
>>>>>>> I'd like to avoid LE to result in a "= default below default" and
>> prefer
>>>>>>> IETF standards not allow fancy interpretations= .
>>>>>>>
>>>>>> This document was approved on the last telechat, b= ut we're having a
>>>>>> Discuss-level discussion about it now, which means= that I should be
>> taking
>>>>>> this conversation very seriously (because "ne= w technical objections
>> are
>>>>>> always in order").
>>>>>>
>>>>>> Am I understanding that
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0- Deborah (and, IIRC, Warren) a= re thinking that MUST is the wrong
>>>>>>=C2=A0 =C2=A0 =C2=A0answer, because we don't te= ll operators how to mark traffic in
>> their
>>>>>>=C2=A0 =C2=A0 =C2=A0networks, but
>>>>>>
>>>>>>
>>>>> Warren is thinking that, if you provide any sort of SH= OULD/MUST
>> guidance
>>>>> regarding when it is appropriate to mark "abnorma= l" traffic, you have
>> to be
>>>>> able to define what you mean by normal and abnormal...=
>>>>>
>>>>> Personally I would think that just: "Non-LE traff= ic (e.g., BE traffic)
>>>>> SHOULD NOT be remarked to LE." (or MUST NOT) with= out any qualifiers
>> would
>>>>> be best -- we are not the protocol police and don'= t have an enforcement
>>>>> arm, so we cannot really stop it. Where I think we run= into trouble is
>>>>> saying "It is OK to do this on Thursdays when the= re is a half moon and
>> the
>>>>> wind blows from the South-East, but not at other times= " (what if these
>> is
>>>>> only a slight breeze? Thursday where? or a waxing gibb= ous moon?) - I
>> think
>>>>> we should just say "You shouldn't remark"= ;,with the understanding that
>> some
>>>>> will and not open the "under these circumstances&= quot; can of worms at all

--
I don't think the execution is relev= ant when it was obviously a bad idea in the first place.
This is like pu= tting rabid weasels in your pants, and later expressing regret at having ch= osen those particular rabid weasels and that pair of pants.
=C2=A0 =C2= =A0---maf
--0000000000000c92a40583448c97-- From nobody Mon Mar 4 12:39:26 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEE613104D; Mon, 4 Mar 2019 12:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js2y9ylRTvtb; Mon, 4 Mar 2019 12:39:14 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 D170D131023; Mon, 4 Mar 2019 12:39:13 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x24KT5wv014110; Mon, 4 Mar 2019 15:39:08 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2r19kx2me6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Mar 2019 15:39:05 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x24Kcp2t003841; Mon, 4 Mar 2019 15:38:52 -0500 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x24Kckic003744; Mon, 4 Mar 2019 15:38:46 -0500 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id 3255240397C9; Mon, 4 Mar 2019 20:38:46 +0000 (GMT) Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (unknown [130.9.129.151]) by zlp27129.vci.att.com (Service) with ESMTPS id 17E6640397C3; Mon, 4 Mar 2019 20:38:46 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.168]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0435.000; Mon, 4 Mar 2019 15:38:45 -0500 From: "BRUNGARD, DEBORAH A" To: Warren Kumari , "gorry@erg.abdn.ac.uk" CC: "tsvwg@ietf.org" , tsvwg-chairs , IESG , "Bless, Roland (TM)" , "Brian E Carpenter" , Spencer Dawkins at IETF Thread-Topic: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) Thread-Index: AQHUyUAEdpZJCyHpGU+YgDrombg8eqXqrsuAgAFHxbCAAaD+gP//+xoQgAL8N4CAA+U5gIAADuaAgAACbICAAAc3AIAAtrAAgABhdwD//8ifYIAAe0SAgAWavACAAFZ3AIAAKBOg Date: Mon, 4 Mar 2019 20:38:45 +0000 Message-ID: References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> <5C7CDC4E.3050606@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.244] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C89EF90453MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-04_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903040145 Archived-At: Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 20:39:18 -0000 --_000_F64C10EAA68C8044B33656FA214632C89EF90453MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2sgZm9yIG1lLQ0KRGVib3JhaA0KDQoNCkZyb206IGllc2cgPGllc2ctYm91bmNlc0BpZXRmLm9y Zz4gT24gQmVoYWxmIE9mIFdhcnJlbiBLdW1hcmkNClNlbnQ6IE1vbmRheSwgTWFyY2ggMDQsIDIw MTkgODoxNSBBTQ0KVG86IGdvcnJ5QGVyZy5hYmRuLmFjLnVrDQpDYzogdHN2d2dAaWV0Zi5vcmc7 IEJSVU5HQVJELCBERUJPUkFIIEEgPGRiMzU0NkBhdHQuY29tPjsgdHN2d2ctY2hhaXJzIDx0c3Z3 Zy1jaGFpcnNAaWV0Zi5vcmc+OyBJRVNHIDxpZXNnQGlldGYub3JnPjsgQmxlc3MsIFJvbGFuZCAo VE0pIDxyb2xhbmQuYmxlc3NAa2l0LmVkdT47IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh cnBlbnRlckBnbWFpbC5jb20+OyBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiA8c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBXYXJyZW4gS3VtYXJpJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRzdndnLWxlLXBoYi0wOTogKHdpdGggRElTQ1VTUyBhbmQg Q09NTUVOVCkNCg0KDQoNCk9uIE1vbiwgTWFyIDQsIDIwMTkgYXQgMzowNSBBTSBHb3JyeSBGYWly aHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+ IHdyb3RlOg0KDQoNCkkgaGF2ZSBoYWQgYSBsaXR0bGUgcmVmbGV4aW9uIG9uIHRoZSBkaXNjdXNz aW9uIGFuZCBJIHF1aXRlIGFncmVlIHRoZQ0KZm9sbG93aW5nIG5lZWRzIHBydW5lZC9yZXdyaXR0 ZW46DQoNCuKAnEhvd2V2ZXIsIG5vbi1MRSB0cmFmZmljIChlLmcuLCBCRSB0cmFmZmljKSBTSE9V TEQgTk9UIGJlDQpyZW1hcmtlZCB0byBMLCBvbiBhIHJlZ3VsYXIgYmFzaXMgd2l0aG91dCBjb25z ZW50IG9yIGtub3dsZWRnZSBvZiB0aGUNCnVzZXIu4oCdDQoNCiAgICAgQW5kIEkgZG8gYWdyZWUg d2l0aCBwcnVuaW5nIHRoaXMgZnJvbSB0aGUgbm9ybWF0aXZlIHRleHQ6DQogICAgIOKAnG9uIGEg cmVndWxhciBiYXNpcyB3aXRob3V0IGNvbnNlbnQgb3Iga25vd2xlZGdlIG9mIHRoZQ0KICAgICB1 c2VyLuKAnQ0KDQogICAgIEhvd2V2ZXIsIGV2ZW4gdGhvdWdoIHRoZSBvcmlnaW5hbCBoYWQgYmVj b21lIGEgbGl0dGxlIGdhYmxlZCwNCiAgICAgaXQgd2FzIGFuIGF0dGVtcHQgdG8gY2FwdHVyZSB0 aGF0IHRoZXJlICpBUkUqIGltcGxpY2F0aW9ucy4NCiAgICAgV2Ugc3BlbnQgdGltZSB0YWxraW5n IGFib3V0IHRoZXNlIGltcGxpY2F0aW9ucyBpbiB0aGUgV0cgYW5kDQogICAgIGEgbG90IG9mIHRp bWUgdHJ5aW5nIHRvIHdyaXRlIHRleHQgdG8gYXZvaWQgYWNjaWRlbnRhbCByZW1hcmtpbmcuDQoN CiAgICAgSSBhbSBzdGlsbCBzb21ld2hhdCB1bmNsZWFyIGhvdyBhbiBvcGVyYXRvciBjb3VsZCBz YWZlbHkganVzdCBtYXANCiAgICAgdHJhZmZpYyB0byB0aGUgTEUgICBjbGFzcywgd2l0aG91dCBh IHByaW9yaSBrbm93aW5nIHdoYXQgdGhlIGZsb3cNCiAgICAgZXhwZWN0cy4gU3VyZSwgYW4gb3Bl cmF0b3IgY291bGQgc2V0dXAgYSBCQS1jbGFzc2lmaWVyIGFuZCB1bmRlcnN0YW5kDQogICAgIHRo YXQgYXBwbGljYXRpb24g4oCcWOKAnSB3YW50cyB0aGlzIHNlcnZpY2UuLiBJZiBpdCBkb2VzIHRo YXQgdGhlbiB0aGF0DQogICAgIHRyYWZmaWMgd2lsbCByZWNlaXZlIHRoZSB0cmVhdG1lbnQgb2Yg TEUgdHJhZmZpYyBmb3IgdGhlIHJlc3Qgb2YgdGhlDQogICAgIHBhdGguIElmIEkgdW5kZXJzdG9v ZCB0aGUgaW50ZW50aW9uLCBpdCB3YXMgdG8gcmVtaW5kIHBlb3BsZSB0aGF0DQogICAgIHRoaXMg aXNu4oCZdCBqdXN0IGFub3RoZXIg4oCcbG93ZXIgbGV2ZWzigJ0gaW4gdGhlIGRpZmZzZXJ2IGhp ZXJhcmNoeSAtDQogICAgIHRyYWZmaWMgbWFwcGVkIHRvIHRoaXMgY2xhc3MgbmVlZHMgdG8gYmUg cmVzaWxpZW50IHRvIHN0YXJ2YXRpb24sDQogICAgIGFuZCBleHBlY3QgdGhhdCB0aGlzIHdpbGwg aGFwcGVuLg0KDQogICAgIEkgc3VnZ2VzdCBhbiBleHBsYW5hdGlvbiBjb3VsZCBiZSBhZGRlZCBh ZnRlciB0aGUgY2xhdXNlIHRvIGJlDQogICAgIHBydW5lZCB0byBhdm9pZCB0aGlzIG5vdCB3b3Jr aW5nIG91dCB3ZWxsOg0KDQogICAgIOKAnFJlbWFya2luZyB0cmFmZmljIGZyb20gYW5vdGhlciBQ SEIgcmVzdWx0cyBpbiB0aGF0IHRyYWZmaWMNCiAgICAgYmVpbmcgImRvd25ncmFkZWTigJ0uIFRo aXMgY2hhbmdlcyB0aGUgd2F5IHRoZSBuZXR3b3JrIHRyZWF0cyB0aGlzDQogICAgIHRyYWZmaWMg YW5kIGl0IGlzIGltcG9ydGFudCBub3QgdG8gdmlvbGF0ZSB0aGUgb3BlcmF0aW9uYWwNCiAgICAg b2JqZWN0aXZlcyBvZiB0aGUgb3JpZ2luYWwgUEhCLuKAnQ0KDQpUaGF0IHNvdW5kcyByZWFzb25h YmxlIHRvIG1lLi4uLi4NCg0KVw0KDQoNCg0KR29ycnkNCg0KUC5TLiBSb2xhbmQsIEkgYWxzbyBq dXN0IHNhdyBhIGZldyBjbGF1c2VzIHNheWluZyDigJxJbiBjYXNlIC4uLi7igJ0sIEkgZG9u4oCZ dA0Ka25vdyBob3cgSSBtaXNzZWQgdGhhdCBpbiBteSByZXZpZXcsIGJ1dCB0aGVzZSByZWFkIGFt YmlndW91c2x5IHRvIG1lOiBJDQpjb3VsZCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgdGhlIHBocmFz ZSB3YXMg4oCcSW4gdGhlIGNhc2UgdGhhdOKAnS4NCg0KT24gMjgvMDIvMjAxOSwgMTg6MzAsIFNw ZW5jZXIgRGF3a2lucyBhdCBJRVRGIHdyb3RlOg0KPiBUaGFua3MsIERlYm9yYWghDQo+DQo+IFJv bGFuZCwgY291bGQgeW91IHN1Ym1pdCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdCwg c28gSSBjYW4gYXBwcm92ZQ0KPiBpdCBiZWZvcmUgV2VkbmVzZGF5IG9mIElFVEYgMTA0PyA6LSkN Cj4NCj4gVGhhbmtzLA0KPg0KPiBTcGVuY2VyDQo+DQo+IE9uIFRodSwgRmViIDI4LCAyMDE5IGF0 IDEwOjE4IEFNIEJSVU5HQVJELCBERUJPUkFIIEE8ZGIzNTQ2QGF0dC5jb208bWFpbHRvOmRiMzU0 NkBhdHQuY29tPj4gIHdyb3RlOg0KPg0KPj4gWWVzLCBJ4oCZbSBvayB3aXRoIHRoZSBhYmJyZXZp YXRlZCBzZW50ZW5jZSBhcyBXYXJyZW4gYW5kIG90aGVycyBzdWdnZXN0ZWQNCj4+IOKAnCJOb24t TEUgdHJhZmZpYyAoZS5nLiwgQkUgdHJhZmZpYykgU0hPVUxEIE5PVCBiZSByZW1hcmtlZCB0byBM RS4iDQo+Pg0KPj4NCj4+DQo+PiBUaGFua3MgZXZlcnlvbmUtDQo+Pg0KPj4gRGVib3JhaA0KPj4N Cj4+DQo+Pg0KPj4gKkZyb206KiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURjxzcGVuY2VyZGF3a2lu cy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+Pg0K Pj4gKlNlbnQ6KiBUaHVyc2RheSwgRmVicnVhcnkgMjgsIDIwMTkgOToyNyBBTQ0KPj4gKlRvOiog Qmxlc3MsIFJvbGFuZCAoVE0pPHJvbGFuZC5ibGVzc0BraXQuZWR1PG1haWx0bzpyb2xhbmQuYmxl c3NAa2l0LmVkdT4+DQo+PiAqQ2M6KiBCcmlhbiBFIENhcnBlbnRlcjxicmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb208bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4+OyBXYXJyZW4g S3VtYXJpPA0KPj4gd2FycmVuQGt1bWFyaS5uZXQ8bWFpbHRvOndhcnJlbkBrdW1hcmkubmV0Pj47 IHRzdndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz47IEJSVU5HQVJELCBERUJPUkFI IEE8ZGIzNTQ2QGF0dC5jb208bWFpbHRvOmRiMzU0NkBhdHQuY29tPj47DQo+PiBJRVNHPGllc2dA aWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+PjsgdHN2d2ctY2hhaXJzPHRzdndnLWNoYWly c0BpZXRmLm9yZzxtYWlsdG86dHN2d2ctY2hhaXJzQGlldGYub3JnPj4NCj4+ICpTdWJqZWN0Oiog UmU6IFt0c3Z3Z10gV2FycmVuIEt1bWFyaSdzIERpc2N1c3Mgb24NCj4+IGRyYWZ0LWlldGYtdHN2 d2ctbGUtcGhiLTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPj4NCj4+DQo+Pg0KPj4g U28sIFdhcnJlbi9EZWJvcmFoLCBhcmUgd2UgZ29vZCBvbiBTSE9VTEQgTk9UIGhlcmU/DQo+Pg0K Pj4NCj4+DQo+PiBTcGVuY2VyDQo+Pg0KPj4NCj4+DQo+PiBPbiBUaHUsIEZlYiAyOCwgMjAxOSBh dCAyOjM4IEFNIEJsZXNzLCBSb2xhbmQgKFRNKTxyb2xhbmQuYmxlc3NAa2l0LmVkdTxtYWlsdG86 cm9sYW5kLmJsZXNzQGtpdC5lZHU+Pg0KPj4gd3JvdGU6DQo+Pg0KPj4gSGksDQo+Pg0KPj4gQW0g MjcuMDIuMTkgdW0gMjI6NDQgc2NocmllYiBCcmlhbiBFIENhcnBlbnRlcjoNCj4+PiBPbiAyOC1G ZWItMTkgMTA6MTgsIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIHdyb3RlOg0KPj4+PiBIaSwgV2Fy cmVuLA0KPj4+Pg0KPj4+PiBPbiBXZWQsIEZlYiAyNywgMjAxOSBhdCAzOjEwIFBNIFdhcnJlbiBL dW1hcmk8d2FycmVuQGt1bWFyaS5uZXQ8bWFpbHRvOndhcnJlbkBrdW1hcmkubmV0Pj4NCj4+IHdy b3RlOg0KPj4+Pj4NCj4+Pj4+IE9uIFdlZCwgRmViIDI3LCAyMDE5IGF0IDEyOjE3IFBNIFNwZW5j ZXIgRGF3a2lucyBhdCBJRVRGPA0KPj4+Pj4gc3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208 bWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPj4gIHdyb3RlOg0KPj4+Pj4NCj4+ Pj4+PiBTbywganVzdCB0byBmb2xsb3cgdXAsDQo+Pj4+Pj4NCj4+Pj4+PiBPbiBNb24sIEZlYiAy NSwgMjAxOSBhdCAyOjQ4IEFNPFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTxtYWlsdG86UnVlZGln ZXIuR2VpYkB0ZWxla29tLmRlPj4gIHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IERlYm9yYWgsIFdh cnJlbiwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSUVURiBkb2Vzbid0IHNwZWNpZnkgU0xBcyBvciByZWxh dGVkIHRleHQsIEkgYWdyZWUuIFRoZSBMRQ0KPj4gcGVyZm9ybWFuY2UNCj4+Pj4+Pj4gaXMgd29y c2UgdGhhbiBkZWZhdWx0IGZvcndhcmRpbmcuIEknbSB1bmhhcHB5IGlmIG15IHBlZXIgZGVtb3Rl cyBteQ0KPj4gdHJhZmZpYw0KPj4+Pj4+PiB0byBMRSBhbmQgcG9pbnRzIHRvIGFuIElFVEYgc3Rh bmRhcmQgYWxsb3dpbmcgdGhpcy4gIFdoYXQgYWJvdXQ6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IERJU0NV U1NFRCBDSEFOR0Ugc28gZmFyOg0KPj4+Pj4+PiBOb24tTEUgdHJhZmZpYyAoZS5nLiwgQkUgdHJh ZmZpYykgU0hPVUxEIE5PVCBiZQ0KPj4+Pj4+PiByZW1hcmtlZCB0byBMRSBvbiBhIHJlZ3VsYXIg YmFzaXMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFNPTUVXSEFUIE1PUkUgUFJFQ0lTRUxZIERFRklORUQg T1BUSU9ODQo+Pj4+Pj4+IE5vbi1MRSB0cmFmZmljIChlLmcuLCBCRSB0cmFmZmljKSBNVVNUIE5P VCBiZQ0KPj4+Pj4+PiByZW1hcmtlZCB0byBMRSBieSBkZWZhdWx0Lg0KPj4+Pj4+Pg0KPj4+Pj4+ PiBJJ2QgbGlrZSB0byBhdm9pZCBMRSB0byByZXN1bHQgaW4gYSAiZGVmYXVsdCBiZWxvdyBkZWZh dWx0IiBhbmQNCj4+IHByZWZlcg0KPj4+Pj4+PiBJRVRGIHN0YW5kYXJkcyBub3QgYWxsb3cgZmFu Y3kgaW50ZXJwcmV0YXRpb25zLi4NCj4+Pj4+Pj4NCj4+Pj4+PiBUaGlzIGRvY3VtZW50IHdhcyBh cHByb3ZlZCBvbiB0aGUgbGFzdCB0ZWxlY2hhdCwgYnV0IHdlJ3JlIGhhdmluZyBhDQo+Pj4+Pj4g RGlzY3Vzcy1sZXZlbCBkaXNjdXNzaW9uIGFib3V0IGl0IG5vdywgd2hpY2ggbWVhbnMgdGhhdCBJ IHNob3VsZCBiZQ0KPj4gdGFraW5nDQo+Pj4+Pj4gdGhpcyBjb252ZXJzYXRpb24gdmVyeSBzZXJp b3VzbHkgKGJlY2F1c2UgIm5ldyB0ZWNobmljYWwgb2JqZWN0aW9ucw0KPj4gYXJlDQo+Pj4+Pj4g YWx3YXlzIGluIG9yZGVyIikuDQo+Pj4+Pj4NCj4+Pj4+PiBBbSBJIHVuZGVyc3RhbmRpbmcgdGhh dA0KPj4+Pj4+DQo+Pj4+Pj4gICAgIC0gRGVib3JhaCAoYW5kLCBJSVJDLCBXYXJyZW4pIGFyZSB0 aGlua2luZyB0aGF0IE1VU1QgaXMgdGhlIHdyb25nDQo+Pj4+Pj4gICAgIGFuc3dlciwgYmVjYXVz ZSB3ZSBkb24ndCB0ZWxsIG9wZXJhdG9ycyBob3cgdG8gbWFyayB0cmFmZmljIGluDQo+PiB0aGVp cg0KPj4+Pj4+ICAgICBuZXR3b3JrcywgYnV0DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4gV2FycmVu IGlzIHRoaW5raW5nIHRoYXQsIGlmIHlvdSBwcm92aWRlIGFueSBzb3J0IG9mIFNIT1VMRC9NVVNU DQo+PiBndWlkYW5jZQ0KPj4+Pj4gcmVnYXJkaW5nIHdoZW4gaXQgaXMgYXBwcm9wcmlhdGUgdG8g bWFyayAiYWJub3JtYWwiIHRyYWZmaWMsIHlvdSBoYXZlDQo+PiB0byBiZQ0KPj4+Pj4gYWJsZSB0 byBkZWZpbmUgd2hhdCB5b3UgbWVhbiBieSBub3JtYWwgYW5kIGFibm9ybWFsLi4uDQo+Pj4+Pg0K Pj4+Pj4gUGVyc29uYWxseSBJIHdvdWxkIHRoaW5rIHRoYXQganVzdDogIk5vbi1MRSB0cmFmZmlj IChlLmcuLCBCRSB0cmFmZmljKQ0KPj4+Pj4gU0hPVUxEIE5PVCBiZSByZW1hcmtlZCB0byBMRS4i IChvciBNVVNUIE5PVCkgd2l0aG91dCBhbnkgcXVhbGlmaWVycw0KPj4gd291bGQNCj4+Pj4+IGJl IGJlc3QgLS0gd2UgYXJlIG5vdCB0aGUgcHJvdG9jb2wgcG9saWNlIGFuZCBkb24ndCBoYXZlIGFu IGVuZm9yY2VtZW50DQo+Pj4+PiBhcm0sIHNvIHdlIGNhbm5vdCByZWFsbHkgc3RvcCBpdC4gV2hl cmUgSSB0aGluayB3ZSBydW4gaW50byB0cm91YmxlIGlzDQo+Pj4+PiBzYXlpbmcgIkl0IGlzIE9L IHRvIGRvIHRoaXMgb24gVGh1cnNkYXlzIHdoZW4gdGhlcmUgaXMgYSBoYWxmIG1vb24gYW5kDQo+ PiB0aGUNCj4+Pj4+IHdpbmQgYmxvd3MgZnJvbSB0aGUgU291dGgtRWFzdCwgYnV0IG5vdCBhdCBv dGhlciB0aW1lcyIgKHdoYXQgaWYgdGhlc2UNCj4+IGlzDQo+Pj4+PiBvbmx5IGEgc2xpZ2h0IGJy ZWV6ZT8gVGh1cnNkYXkgd2hlcmU/IG9yIGEgd2F4aW5nIGdpYmJvdXMgbW9vbj8pIC0gSQ0KPj4g dGhpbmsNCj4+Pj4+IHdlIHNob3VsZCBqdXN0IHNheSAiWW91IHNob3VsZG4ndCByZW1hcmsiLHdp dGggdGhlIHVuZGVyc3RhbmRpbmcgdGhhdA0KPj4gc29tZQ0KPj4+Pj4gd2lsbCBhbmQgbm90IG9w ZW4gdGhlICJ1bmRlciB0aGVzZSBjaXJjdW1zdGFuY2VzIiBjYW4gb2Ygd29ybXMgYXQgYWxsDQot LQ0KSSBkb24ndCB0aGluayB0aGUgZXhlY3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9i dmlvdXNseSBhIGJhZCBpZGVhIGluIHRoZSBmaXJzdCBwbGFjZS4NClRoaXMgaXMgbGlrZSBwdXR0 aW5nIHJhYmlkIHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3NpbmcgcmVn cmV0IGF0IGhhdmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFuZCB0 aGF0IHBhaXIgb2YgcGFudHMuDQogICAtLS1tYWYNCg== --_000_F64C10EAA68C8044B33656FA214632C89EF90453MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P ayBmb3IgbWUtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWJvcmFoPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IGllc2cgJmx0O2llc2ctYm91bmNlc0BpZXRmLm9yZyZndDsg PGI+T24gQmVoYWxmIE9mIDwvYj4NCldhcnJlbiBLdW1hcmk8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBNYXJjaCAwNCwgMjAxOSA4OjE1IEFNPGJyPg0KPGI+VG86PC9iPiBnb3JyeUBlcmcuYWJk bi5hYy51azxicj4NCjxiPkNjOjwvYj4gdHN2d2dAaWV0Zi5vcmc7IEJSVU5HQVJELCBERUJPUkFI IEEgJmx0O2RiMzU0NkBhdHQuY29tJmd0OzsgdHN2d2ctY2hhaXJzICZsdDt0c3Z3Zy1jaGFpcnNA aWV0Zi5vcmcmZ3Q7OyBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgQmxlc3MsIFJvbGFuZCAo VE0pICZsdDtyb2xhbmQuYmxlc3NAa2l0LmVkdSZndDs7IEJyaWFuIEUgQ2FycGVudGVyICZsdDti cmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20mZ3Q7OyBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiAm bHQ7c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbdHN2d2ddIFdhcnJlbiBLdW1hcmkncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdHN2d2ct bGUtcGhiLTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXIgNCwgMjAxOSBhdCAzOjA1IEFNIEdvcnJ5IEZhaXJo dXJzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj5nb3JyeUBlcmcu YWJkbi5hYy51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KSSBoYXZlIGhhZCBhIGxpdHRs ZSByZWZsZXhpb24gb24gdGhlIGRpc2N1c3Npb24gYW5kIEkgcXVpdGUgYWdyZWUgdGhlIDxicj4N CmZvbGxvd2luZyBuZWVkcyBwcnVuZWQvcmV3cml0dGVuOjxicj4NCjxicj4NCuKAnEhvd2V2ZXIs IG5vbi1MRSB0cmFmZmljIChlLmcuLCBCRSB0cmFmZmljKSBTSE9VTEQgTk9UIGJlPGJyPg0KcmVt YXJrZWQgdG8gTCwgb24gYSByZWd1bGFyIGJhc2lzIHdpdGhvdXQgY29uc2VudCBvciBrbm93bGVk Z2Ugb2YgdGhlPGJyPg0KdXNlci7igJ08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO0Fu ZCBJIGRvIGFncmVlIHdpdGggcHJ1bmluZyB0aGlzIGZyb20gdGhlIG5vcm1hdGl2ZSB0ZXh0Ojxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A74oCcb24gYSByZWd1bGFyIGJhc2lzIHdpdGhvdXQgY29u c2VudCBvciBrbm93bGVkZ2Ugb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDt1c2VyLuKA nTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7SG93ZXZlciwgZXZlbiB0aG91Z2ggdGhl IG9yaWdpbmFsIGhhZCBiZWNvbWUgYSBsaXR0bGUgZ2FibGVkLDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7aXQgd2FzIGFuIGF0dGVtcHQgdG8gY2FwdHVyZSB0aGF0IHRoZXJlICpBUkUqIGltcGxp Y2F0aW9ucy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO1dlIHNwZW50IHRpbWUgdGFsa2luZyBh Ym91dCB0aGVzZSBpbXBsaWNhdGlvbnMgaW4gdGhlIFdHIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7YSBsb3Qgb2YgdGltZSB0cnlpbmcgdG8gd3JpdGUgdGV4dCB0byBhdm9pZCBhY2NpZGVu dGFsIHJlbWFya2luZy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO0kgYW0gc3RpbGwg c29tZXdoYXQgdW5jbGVhciBob3cgYW4gb3BlcmF0b3IgY291bGQgc2FmZWx5IGp1c3QgbWFwPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDt0cmFmZmljIHRvIHRoZSBMRSZuYnNwOyAmbmJzcDtjbGFz cywgd2l0aG91dCBhIHByaW9yaSBrbm93aW5nIHdoYXQgdGhlIGZsb3c8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwO2V4cGVjdHMuIFN1cmUsIGFuIG9wZXJhdG9yIGNvdWxkIHNldHVwIGEgQkEtY2xh c3NpZmllciBhbmQgdW5kZXJzdGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCBhcHBs aWNhdGlvbiDigJxY4oCdIHdhbnRzIHRoaXMgc2VydmljZS4uIElmIGl0IGRvZXMgdGhhdCB0aGVu IHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMgd2lsbCByZWNlaXZlIHRoZSB0 cmVhdG1lbnQgb2YgTEUgdHJhZmZpYyBmb3IgdGhlIHJlc3Qgb2YgdGhlPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDtwYXRoLiBJZiBJIHVuZGVyc3Rvb2QgdGhlIGludGVudGlvbiwgaXQgd2FzIHRv IHJlbWluZCBwZW9wbGUgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7dGhpcyBpc27igJl0 IGp1c3QgYW5vdGhlciDigJxsb3dlciBsZXZlbOKAnSBpbiB0aGUgZGlmZnNlcnYgaGllcmFyY2h5 IC08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMgbWFwcGVkIHRvIHRoaXMgY2xhc3Mg bmVlZHMgdG8gYmUgcmVzaWxpZW50IHRvIHN0YXJ2YXRpb24sPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDthbmQgZXhwZWN0IHRoYXQgdGhpcyB3aWxsIGhhcHBlbi48YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwO0kgc3VnZ2VzdCBhbiBleHBsYW5hdGlvbiBjb3VsZCBiZSBhZGRlZCBhZnRl ciB0aGUgY2xhdXNlIHRvIGJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtwcnVuZWQgdG8gYXZv aWQgdGhpcyBub3Qgd29ya2luZyBvdXQgd2VsbDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwO+KAnFJlbWFya2luZyB0cmFmZmljIGZyb20gYW5vdGhlciBQSEIgcmVzdWx0cyBpbiB0aGF0 IHRyYWZmaWM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2JlaW5nICZxdW90O2Rvd25ncmFkZWTi gJ0uIFRoaXMgY2hhbmdlcyB0aGUgd2F5IHRoZSBuZXR3b3JrIHRyZWF0cyB0aGlzPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDt0cmFmZmljIGFuZCBpdCBpcyBpbXBvcnRhbnQgbm90IHRvIHZpb2xh dGUgdGhlIG9wZXJhdGlvbmFsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtvYmplY3RpdmVzIG9m IHRoZSBvcmlnaW5hbCBQSEIu4oCdPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNvdW5kcyByZWFzb25hYmxlIHRvIG1lLi4u Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCkdvcnJ5PGJyPg0K PGJyPg0KUC5TLiBSb2xhbmQsIEkgYWxzbyBqdXN0IHNhdyBhIGZldyBjbGF1c2VzIHNheWluZyDi gJxJbiBjYXNlIC4uLi7igJ0sIEkgZG9u4oCZdDxicj4NCmtub3cgaG93IEkgbWlzc2VkIHRoYXQg aW4gbXkgcmV2aWV3LCBidXQgdGhlc2UgcmVhZCBhbWJpZ3VvdXNseSB0byBtZTogSTxicj4NCmNv dWxkIGl0IHdvdWxkIGJlIGJldHRlciBpZiB0aGUgcGhyYXNlIHdhcyDigJxJbiB0aGUgY2FzZSB0 aGF04oCdLjxicj4NCjxicj4NCk9uIDI4LzAyLzIwMTksIDE4OjMwLCBTcGVuY2VyIERhd2tpbnMg YXQgSUVURiB3cm90ZTo8YnI+DQomZ3Q7IFRoYW5rcywgRGVib3JhaCE8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBSb2xhbmQsIGNvdWxkIHlvdSBzdWJtaXQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoaXMg ZHJhZnQsIHNvIEkgY2FuIGFwcHJvdmU8YnI+DQomZ3Q7IGl0IGJlZm9yZSBXZWRuZXNkYXkgb2Yg SUVURiAxMDQ/IDotKTxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBTcGVuY2VyPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gVGh1LCBGZWIgMjgsIDIwMTkgYXQg MTA6MTggQU0gQlJVTkdBUkQsIERFQk9SQUggQSZsdDs8YSBocmVmPSJtYWlsdG86ZGIzNTQ2QGF0 dC5jb20iIHRhcmdldD0iX2JsYW5rIj5kYjM1NDZAYXR0LmNvbTwvYT4mZ3Q7Jm5ic3A7IHdyb3Rl Ojxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBZZXMsIEnigJltIG9rIHdpdGggdGhlIGFiYnJldmlh dGVkIHNlbnRlbmNlIGFzIFdhcnJlbiBhbmQgb3RoZXJzIHN1Z2dlc3RlZDxicj4NCiZndDsmZ3Q7 IOKAnCZxdW90O05vbi1MRSB0cmFmZmljIChlLmcuLCBCRSB0cmFmZmljKSBTSE9VTEQgTk9UIGJl IHJlbWFya2VkIHRvIExFLiZxdW90Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyBldmVyeW9uZS08YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IERlYm9yYWg8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAqRnJvbToqIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGJmx0OzxhIGhy ZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAqU2Vu dDoqIFRodXJzZGF5LCBGZWJydWFyeSAyOCwgMjAxOSA5OjI3IEFNPGJyPg0KJmd0OyZndDsgKlRv OiogQmxlc3MsIFJvbGFuZCAoVE0pJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xhbmQuYmxlc3NAa2l0 LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnJvbGFuZC5ibGVzc0BraXQuZWR1PC9hPiZndDs8YnI+DQom Z3Q7Jmd0OyAqQ2M6KiBCcmlhbiBFIENhcnBlbnRlciZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tPC9hPiZndDs7IFdhcnJlbiBLdW1hcmkmbHQ7PGJyPg0KJmd0OyZndDsgPGEgaHJl Zj0ibWFpbHRvOndhcnJlbkBrdW1hcmkubmV0IiB0YXJnZXQ9Il9ibGFuayI+d2FycmVuQGt1bWFy aS5uZXQ8L2E+Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOnRzdndnQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQp0c3Z3Z0BpZXRmLm9yZzwvYT47IEJSVU5HQVJELCBERUJPUkFIIEEmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRiMzU0NkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGIzNTQ2QGF0dC5jb208 L2E+Jmd0Ozs8YnI+DQomZ3Q7Jmd0OyBJRVNHJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7OyB0c3Z3Zy1jaGFpcnMm bHQ7PGEgaHJlZj0ibWFpbHRvOnRzdndnLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnRzdndnLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgKlN1YmplY3Q6KiBS ZTogW3RzdndnXSBXYXJyZW4gS3VtYXJpJ3MgRGlzY3VzcyBvbjxicj4NCiZndDsmZ3Q7IGRyYWZ0 LWlldGYtdHN2d2ctbGUtcGhiLTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNvLCBXYXJy ZW4vRGVib3JhaCwgYXJlIHdlIGdvb2Qgb24gU0hPVUxEIE5PVCBoZXJlPzxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNwZW5jZXI8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBUaHUs IEZlYiAyOCwgMjAxOSBhdCAyOjM4IEFNIEJsZXNzLCBSb2xhbmQgKFRNKSZsdDs8YSBocmVmPSJt YWlsdG86cm9sYW5kLmJsZXNzQGtpdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5yb2xhbmQuYmxlc3NA a2l0LmVkdTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBIaSw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFtIDI3LjAyLjE5IHVtIDIy OjQ0IHNjaHJpZWIgQnJpYW4gRSBDYXJwZW50ZXI6PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDI4LUZl Yi0xOSAxMDoxOCwgU3BlbmNlciBEYXdraW5zIGF0IElFVEYgd3JvdGU6PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyBIaSwgV2FycmVuLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IE9uIFdlZCwgRmViIDI3LCAyMDE5IGF0IDM6MTAgUE0gV2FycmVuIEt1bWFyaSZsdDs8 YSBocmVmPSJtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQiIHRhcmdldD0iX2JsYW5rIj53YXJyZW5A a3VtYXJpLm5ldDwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBXZWQsIEZlYiAyNywgMjAxOSBh dCAxMjoxNyBQTSBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiZsdDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5zcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7Jm5ic3A7 IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFNvLCBqdXN0IHRvIGZvbGxvdyB1cCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gTW9uLCBGZWIgMjUsIDIwMTkgYXQg Mjo0OCBBTSZsdDs8YSBocmVmPSJtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlIiB0YXJn ZXQ9Il9ibGFuayI+UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPC9hPiZndDsmbmJzcDsgd3JvdGU6 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBEZWJvcmFoLCBXYXJyZW4sPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSUVURiBkb2Vzbid0IHNwZWNpZnkg U0xBcyBvciByZWxhdGVkIHRleHQsIEkgYWdyZWUuIFRoZSBMRTxicj4NCiZndDsmZ3Q7IHBlcmZv cm1hbmNlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyB3b3JzZSB0aGFuIGRl ZmF1bHQgZm9yd2FyZGluZy4gSSdtIHVuaGFwcHkgaWYgbXkgcGVlciBkZW1vdGVzIG15PGJyPg0K Jmd0OyZndDsgdHJhZmZpYzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gTEUg YW5kIHBvaW50cyB0byBhbiBJRVRGIHN0YW5kYXJkIGFsbG93aW5nIHRoaXMuJm5ic3A7IFdoYXQg YWJvdXQ6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgRElTQ1VTU0VEIENIQU5HRSBzbyBmYXI6PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOb24tTEUgdHJhZmZpYyAoZS5nLiwgQkUgdHJhZmZpYykgU0hP VUxEIE5PVCBiZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVtYXJrZWQgdG8g TEUgb24gYSByZWd1bGFyIGJhc2lzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNPTUVXSEFUIE1PUkUgUFJFQ0lTRUxZ IERFRklORUQgT1BUSU9OPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOb24tTEUg dHJhZmZpYyAoZS5nLiwgQkUgdHJhZmZpYykgTVVTVCBOT1QgYmU8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHJlbWFya2VkIHRvIExFIGJ5IGRlZmF1bHQuPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSdk IGxpa2UgdG8gYXZvaWQgTEUgdG8gcmVzdWx0IGluIGEgJnF1b3Q7ZGVmYXVsdCBiZWxvdyBkZWZh dWx0JnF1b3Q7IGFuZDxicj4NCiZndDsmZ3Q7IHByZWZlcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSUVURiBzdGFuZGFyZHMgbm90IGFsbG93IGZhbmN5IGludGVycHJldGF0aW9u cy4uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUaGlzIGRvY3VtZW50IHdhcyBhcHByb3ZlZCBvbiB0aGUgbGFzdCB0ZWxlY2hh dCwgYnV0IHdlJ3JlIGhhdmluZyBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERpc2N1 c3MtbGV2ZWwgZGlzY3Vzc2lvbiBhYm91dCBpdCBub3csIHdoaWNoIG1lYW5zIHRoYXQgSSBzaG91 bGQgYmU8YnI+DQomZ3Q7Jmd0OyB0YWtpbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dGhpcyBjb252ZXJzYXRpb24gdmVyeSBzZXJpb3VzbHkgKGJlY2F1c2UgJnF1b3Q7bmV3IHRlY2hu aWNhbCBvYmplY3Rpb25zPGJyPg0KJmd0OyZndDsgYXJlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGFsd2F5cyBpbiBvcmRlciZxdW90OykuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFtIEkgdW5kZXJzdGFuZGluZyB0aGF0 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDstIERlYm9yYWggKGFuZCwgSUlSQywgV2FycmVuKSBhcmUg dGhpbmtpbmcgdGhhdCBNVVNUIGlzIHRoZSB3cm9uZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YW5zd2VyLCBiZWNhdXNlIHdlIGRvbid0IHRlbGwgb3Bl cmF0b3JzIGhvdyB0byBtYXJrIHRyYWZmaWMgaW48YnI+DQomZ3Q7Jmd0OyB0aGVpcjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7bmV0d29ya3MsIGJ1dDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdhcnJlbiBpcyB0aGlua2luZyB0aGF0LCBpZiB5 b3UgcHJvdmlkZSBhbnkgc29ydCBvZiBTSE9VTEQvTVVTVDxicj4NCiZndDsmZ3Q7IGd1aWRhbmNl PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVnYXJkaW5nIHdoZW4gaXQgaXMgYXBwcm9wcmlh dGUgdG8gbWFyayAmcXVvdDthYm5vcm1hbCZxdW90OyB0cmFmZmljLCB5b3UgaGF2ZTxicj4NCiZn dDsmZ3Q7IHRvIGJlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWJsZSB0byBkZWZpbmUgd2hh dCB5b3UgbWVhbiBieSBub3JtYWwgYW5kIGFibm9ybWFsLi4uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQZXJzb25hbGx5IEkgd291bGQgdGhpbmsg dGhhdCBqdXN0OiAmcXVvdDtOb24tTEUgdHJhZmZpYyAoZS5nLiwgQkUgdHJhZmZpYyk8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTSE9VTEQgTk9UIGJlIHJlbWFya2VkIHRvIExFLiZxdW90OyAo b3IgTVVTVCBOT1QpIHdpdGhvdXQgYW55IHF1YWxpZmllcnM8YnI+DQomZ3Q7Jmd0OyB3b3VsZDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIGJlc3QgLS0gd2UgYXJlIG5vdCB0aGUgcHJvdG9j b2wgcG9saWNlIGFuZCBkb24ndCBoYXZlIGFuIGVuZm9yY2VtZW50PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgYXJtLCBzbyB3ZSBjYW5ub3QgcmVhbGx5IHN0b3AgaXQuIFdoZXJlIEkgdGhpbmsg d2UgcnVuIGludG8gdHJvdWJsZSBpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNheWluZyAm cXVvdDtJdCBpcyBPSyB0byBkbyB0aGlzIG9uIFRodXJzZGF5cyB3aGVuIHRoZXJlIGlzIGEgaGFs ZiBtb29uIGFuZDxicj4NCiZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdp bmQgYmxvd3MgZnJvbSB0aGUgU291dGgtRWFzdCwgYnV0IG5vdCBhdCBvdGhlciB0aW1lcyZxdW90 OyAod2hhdCBpZiB0aGVzZTxicj4NCiZndDsmZ3Q7IGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgb25seSBhIHNsaWdodCBicmVlemU/IFRodXJzZGF5IHdoZXJlPyBvciBhIHdheGluZyBnaWJi b3VzIG1vb24/KSAtIEk8YnI+DQomZ3Q7Jmd0OyB0aGluazxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHdlIHNob3VsZCBqdXN0IHNheSAmcXVvdDtZb3Ugc2hvdWxkbid0IHJlbWFyayZxdW90Oyx3 aXRoIHRoZSB1bmRlcnN0YW5kaW5nIHRoYXQ8YnI+DQomZ3Q7Jmd0OyBzb21lPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgd2lsbCBhbmQgbm90IG9wZW4gdGhlICZxdW90O3VuZGVyIHRoZXNlIGNp cmN1bXN0YW5jZXMmcXVvdDsgY2FuIG9mIHdvcm1zIGF0IGFsbDxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgdGhl IGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQgaWRlYSBp biB0aGUgZmlyc3QgcGxhY2UuPGJyPg0KVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2Vs cyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdyZXQgYXQgaGF2aW5nIGNo b3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpciBvZiBwYW50 cy48YnI+DQombmJzcDsgJm5ic3A7LS0tbWFmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C89EF90453MISOUT7MSGUSRDE_-- From nobody Mon Mar 4 19:39:31 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BF6130EE5; Mon, 4 Mar 2019 19:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DNc3zPAG-CGh; Mon, 4 Mar 2019 19:39:20 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 7E190130ED0; Mon, 4 Mar 2019 19:39:19 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id w6so6266106ljd.7; Mon, 04 Mar 2019 19:39:19 -0800 (PST) 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=rkMhvEOrwpxUrwLjH9As3OlMhptbLpnYxSkHZb+6qzw=; b=rW+kyOfsFWcCNQAqsCe86eWfIKeKYDga0xbK5fNZGkyiNl5Stbfk4ckFdbdTFFQjOZ VfRQxwtlswzsYZhf8MvQQHDM4R+ZiwvVC2NqMLjDNrozhnvE4Zvzw0XO2/hp+hTgoNKP zjQ3uv3VAaqb3HI9fdmsRJ0FGOwZyNmlFsARDOIpdw4+Ed6W7QKaQbTrRe9joGsijRq3 rJ9bJtlANlwPTt9N5cTXFYczEtv2kXCatnVCU8vho0laWpAlfNAnkLUde6Pd1KyCpGGq 53INfYv/G0Md1F4W602iOaOYeb3Hoocv3rTx3N16pxjcEF8M68NqCgmL9E5DXKbA25bu CUPA== 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=rkMhvEOrwpxUrwLjH9As3OlMhptbLpnYxSkHZb+6qzw=; b=fgeiDGysic6bwQuI4uCvBui1uDEq9IVtVMsM/GjkPxD7EC4oeWkG6aQf3mMKZ63P/Y w++XBmlFR7u8aWXbd0MKyReF3tRCItfvIXA2Vsd2rbpBKPykwFjy0Ov8TKhYiyeGf2uR ZKAvGk7DdPgWInHJOpAbI8ac1cqqRceNlnab++c6CpsZoYawXqiOI5ppIOpqbqnd0wYf iRL2CD0H2LfO/7vQIzLqZoIlvXX/V5vlvSAIhZMyrn4aVZ/qez6IzCwqw1pb/a7X1d76 jviTvOIZFmCN9oRoWWX3oC2oozwn9JKHCtsW8h8FYIv8JV5wa/Swbwz4Cr1woTRSddaZ xeuw== X-Gm-Message-State: APjAAAUzZS46jdpQClXBItMGZkbjX17lHiddQECmtZZH02ZUzSEO9lb3 7lRwEa9LGmhWgAzGlb5CXDEatJWYnJL7MIwmRXE= X-Google-Smtp-Source: APXvYqzdCHbyWJcSNB7QUagugMu7u+KHv2pmNG/qiJxuCHyBqZiU4RkTr5MjbJQM9Xadfq+b+VmQ7F4KP2zv6GJ1yZ4= X-Received: by 2002:a2e:9b95:: with SMTP id z21mr12174797lji.155.1551757157582; Mon, 04 Mar 2019 19:39:17 -0800 (PST) MIME-Version: 1.0 References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> <5C7CDC4E.3050606@erg.abdn.ac.uk> In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 4 Mar 2019 21:39:06 -0600 Message-ID: To: "BRUNGARD, DEBORAH A" Cc: Warren Kumari , "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , tsvwg-chairs , IESG , "Bless, Roland (TM)" , Brian E Carpenter Content-Type: multipart/alternative; boundary="00000000000027c9c40583509e92" Archived-At: Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 03:39:23 -0000 --00000000000027c9c40583509e92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Gorry, On Mon, Mar 4, 2019 at 2:39 PM BRUNGARD, DEBORAH A wrote: > Ok for me- > > Deborah > > > > > > *From:* iesg *On Behalf Of * Warren Kumari > *Sent:* Monday, March 04, 2019 8:15 AM > *To:* gorry@erg.abdn.ac.uk > *Cc:* tsvwg@ietf.org; BRUNGARD, DEBORAH A ; tsvwg-chairs = < > tsvwg-chairs@ietf.org>; IESG ; Bless, Roland (TM) < > roland.bless@kit.edu>; Brian E Carpenter ; > Spencer Dawkins at IETF > *Subject:* Re: [tsvwg] Warren Kumari's Discuss on > draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) > > > > > > > > On Mon, Mar 4, 2019 at 3:05 AM Gorry Fairhurst > wrote: > > > > I have had a little reflexion on the discussion and I quite agree the > following needs pruned/rewritten: > > =E2=80=9CHowever, non-LE traffic (e.g., BE traffic) SHOULD NOT be > remarked to L, on a regular basis without consent or knowledge of the > user.=E2=80=9D > > And I do agree with pruning this from the normative text: > =E2=80=9Con a regular basis without consent or knowledge of the > user.=E2=80=9D > > However, even though the original had become a little gabled, > it was an attempt to capture that there *ARE* implications. > We spent time talking about these implications in the WG and > a lot of time trying to write text to avoid accidental remarking. > > I am still somewhat unclear how an operator could safely just map > traffic to the LE class, without a priori knowing what the flow > expects. Sure, an operator could setup a BA-classifier and understan= d > that application =E2=80=9CX=E2=80=9D wants this service.. If it does= that then that > traffic will receive the treatment of LE traffic for the rest of the > path. If I understood the intention, it was to remind people that > this isn=E2=80=99t just another =E2=80=9Clower level=E2=80=9D in the= diffserv hierarchy - > traffic mapped to this class needs to be resilient to starvation, > and expect that this will happen. > > I suggest an explanation could be added after the clause to be > pruned to avoid this not working out well: > > =E2=80=9CRemarking traffic from another PHB results in that traffic > being "downgraded=E2=80=9D. This changes the way the network treats = this > traffic and it is important not to violate the operational > objectives of the original PHB.=E2=80=9D > > > > That sounds reasonable to me..... > > > > W > > > > > > Gorry > > P.S. Roland, I also just saw a few clauses saying =E2=80=9CIn case ....= =E2=80=9D, I don=E2=80=99t > know how I missed that in my review, but these read ambiguously to me: I > could it would be better if the phrase was =E2=80=9CIn the case that=E2= =80=9D. > > Thanks for sending your note. I knew there was an important point that wa= s trying to escape from the e-mail thread. And NOW, I think, Roland can submit an approvable update. Spencer --00000000000027c9c40583509e92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Gorry,=C2=A0

On Mon, Mar 4, 2019 at 2:= 39 PM BRUNGARD, DEBORAH A <db3546@att.= com> wrote:

Ok for me-

Deborah

=C2=A0

=C2=A0

From: iesg <iesg-bounces@ietf.org> On Behalf Of = Warren Kumari
Sent: Monday, March 04, 2019 8:15 AM
To: gorry@= erg.abdn.ac.uk
Cc: tsvwg@ietf.o= rg; BRUNGARD, DEBORAH A <db3546@att.com>; tsvwg-chairs <tsvwg-chairs@ietf.org>; IESG <<= a href=3D"mailto:iesg@ietf.org" target=3D"_blank">iesg@ietf.org>; Bl= ess, Roland (TM) <roland.bless@kit.edu>; Brian E Carpenter <brian.e.carpenter@gmail.com>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg= -le-phb-09: (with DISCUSS and COMMENT)

=C2=A0

=C2=A0

=C2=A0

On Mon, Mar 4, 2019 at 3:05 AM Gorry Fairhurst <<= a href=3D"mailto:gorry@erg.abdn.ac.uk" target=3D"_blank">gorry@erg.abdn.ac.= uk> wrote:



I have had a little reflexion on the discussion and I quite agree the
following needs pruned/rewritten:

=E2=80=9CHowever, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to L, on a regular basis without consent or knowledge of the
user.=E2=80=9D

=C2=A0 =C2=A0 =C2=A0And I do agree with pruning this from the normative tex= t:
=C2=A0 =C2=A0 =C2=A0=E2=80=9Con a regular basis without consent or knowledg= e of the
=C2=A0 =C2=A0 =C2=A0user.=E2=80=9D

=C2=A0 =C2=A0 =C2=A0However, even though the original had become a little g= abled,
=C2=A0 =C2=A0 =C2=A0it was an attempt to capture that there *ARE* implicati= ons.
=C2=A0 =C2=A0 =C2=A0We spent time talking about these implications in the W= G and
=C2=A0 =C2=A0 =C2=A0a lot of time trying to write text to avoid accidental = remarking.

=C2=A0 =C2=A0 =C2=A0I am still somewhat unclear how an operator could safel= y just map
=C2=A0 =C2=A0 =C2=A0traffic to the LE=C2=A0 =C2=A0class, without a priori k= nowing what the flow
=C2=A0 =C2=A0 =C2=A0expects. Sure, an operator could setup a BA-classifier = and understand
=C2=A0 =C2=A0 =C2=A0that application =E2=80=9CX=E2=80=9D wants this service= .. If it does that then that
=C2=A0 =C2=A0 =C2=A0traffic will receive the treatment of LE traffic for th= e rest of the
=C2=A0 =C2=A0 =C2=A0path. If I understood the intention, it was to remind p= eople that
=C2=A0 =C2=A0 =C2=A0this isn=E2=80=99t just another =E2=80=9Clower level=E2= =80=9D in the diffserv hierarchy -
=C2=A0 =C2=A0 =C2=A0traffic mapped to this class needs to be resilient to s= tarvation,
=C2=A0 =C2=A0 =C2=A0and expect that this will happen.

=C2=A0 =C2=A0 =C2=A0I suggest an explanation could be added after the claus= e to be
=C2=A0 =C2=A0 =C2=A0pruned to avoid this not working out well:

=C2=A0 =C2=A0 =C2=A0=E2=80=9CRemarking traffic from another PHB results in = that traffic
=C2=A0 =C2=A0 =C2=A0being "downgraded=E2=80=9D. This changes the way t= he network treats this
=C2=A0 =C2=A0 =C2=A0traffic and it is important not to violate the operatio= nal
=C2=A0 =C2=A0 =C2=A0objectives of the original PHB.=E2=80=9D<= /p>

=C2=A0

That sounds reasonable to me.....

=C2=A0

W

=C2=A0



Gorry

P.S. Roland, I also just saw a few clauses saying =E2=80=9CIn case ....=E2= =80=9D, I don=E2=80=99t
know how I missed that in my review, but these read ambiguously to me: I could it would be better if the phrase was =E2=80=9CIn the case that=E2=80= =9D.

Thanks f= or sending your note. I knew there was an important point that was trying t= o escape from the e-mail thread.

And NOW, I think,= Roland can submit an approvable update.

Spencer= =C2=A0
--00000000000027c9c40583509e92-- From nobody Tue Mar 5 00:49:30 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A8A124B0C; Tue, 5 Mar 2019 00:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeQOpuylbn1X; Tue, 5 Mar 2019 00:49:25 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (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 61C42130F3B; Tue, 5 Mar 2019 00:49:24 -0800 (PST) Received: from [2a00:1398:2:4006:953e:1767:2a12:5bc1] (helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 2a00:1398:2::10:8 id 1h15lJ-0007mr-JP; Tue, 05 Mar 2019 09:49:21 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 273494200C5; Tue, 5 Mar 2019 09:49:21 +0100 (CET) To: Spencer Dawkins at IETF Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , tsvwg-chairs , IESG , Brian E Carpenter References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <5C7CDC4E.3050606@erg.abdn.ac.uk> From: "Bless, Roland (TM)" Openpgp: preference=signencrypt Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= xsFNBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABzShSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+wsGABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEzsFNBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABwsFlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Tue, 5 Mar 2019 09:49:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1551775761.686832528 Archived-At: Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 08:49:29 -0000 Hi Spencer, Am 05.03.19 um 04:39 schrieb Spencer Dawkins at IETF: > Thanks for sending your note. I knew there was an important point that > was trying to escape from the e-mail thread. > > And NOW, I think, Roland can submit an approvable update. > > Spencer  I still have a backlog of IESG comments. However, I'll start updating the draft and hope to submit it within the next two days. Regards Roland From nobody Tue Mar 5 05:19:14 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3C0130FC4; Tue, 5 Mar 2019 05:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 4Hn9k1dD6Qlg; Tue, 5 Mar 2019 05:19:09 -0800 (PST) Received: from mailout41.telekom.de (MAILOUT41.telekom.de [194.25.225.151]) (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 84C17130F3E; Tue, 5 Mar 2019 05:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1551791948; x=1583327948; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7u5Hfp72gDysuoGG+XkWAqD4YHH8AtWlVrrPmFTKwgk=; b=dQqqiSMjEVgqFOh0EzTz5rR/0BxesftbZyLwjWcZ4dO4MsHQxzpskVB8 G7Yda9pv+f2q5sJip5sfRtAVKf6KvBPydgy6jYZS7H9Uh1o7Bv8i8GBEy xFMTDCF8/T7bmN+UQ2y3cCvU2bg8s7ANPtWjE5gwGOPBRuUOrCPvNwlhA b/8XrtSeNFkuM68Zy/shte60o3NT+9XBcEYtYx7k1xg3hqvCfUr9t92Yd 4XF7cap08Cu7ueyFC2CaeOfcLhmvjk7UDuzwAyTo25Lu5lA0ydBtmkV2Z TepY+5iiQuE3DBMXORoHYQWiREbSX5isPJegVxtkVcl+q/2R8b2xNNetZ A==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 14:19:04 +0100 Received: from he105690.emea1.cds.t-internal.com ([10.169.119.68]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 05 Mar 2019 14:19:03 +0100 Received: from HE105651.EMEA1.cds.t-internal.com (10.169.119.62) by HE105690.emea1.cds.t-internal.com (10.169.119.68) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 14:19:02 +0100 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE105651.EMEA1.cds.t-internal.com (10.169.119.62) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 5 Mar 2019 14:19:02 +0100 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.24) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 14:19:03 +0100 Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.153) by LEJPR01MB0459.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Tue, 5 Mar 2019 13:19:01 +0000 Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6846:71f5:e7d1:f189]) by LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6846:71f5:e7d1:f189%4]) with mapi id 15.20.1665.020; Tue, 5 Mar 2019 13:19:01 +0000 From: To: CC: , , , Thread-Topic: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) Thread-Index: AQHUyUAEdpZJCyHpGU+YgDrombg8eqXqrsuAgAFHxbCAAU0sgIAAVJiAgAKeNGCAA+m+gIAADueAgAACbICAAL5/K4AAYN4AgAAfAQCAACTigIAF8XDUgAB7vICAARc6EA== Date: Tue, 5 Mar 2019 13:19:01 +0000 Message-ID: References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> <5C7CDC4E.3050606@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d1da821e-89b3-4e9b-370d-08d6a16d223f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:LEJPR01MB0459; x-ms-traffictypediagnostic: LEJPR01MB0459: x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(136003)(376002)(39860400002)(396003)(366004)(199004)(189003)(53936002)(478600001)(9686003)(54896002)(236005)(6306002)(55016002)(7736002)(68736007)(33656002)(561944003)(8936002)(66066001)(72206003)(74482002)(76176011)(75402003)(14454004)(71190400001)(2906002)(2351001)(14444005)(85182001)(5640700003)(6916009)(71200400001)(316002)(296002)(54906003)(93886005)(4326008)(85202003)(105586002)(2501003)(256004)(102836004)(476003)(53546011)(1730700003)(8676002)(186003)(81156014)(106356001)(19627235002)(81166006)(52396003)(86362001)(486006)(790700001)(97736004)(5660300002)(6116002)(11346002)(26005)(3846002)(446003)(7696005)(66574012)(777600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0459; H:LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtMRUpQUjAxTUIwNDU5OzIzOkdZR1RpQnh1MTJOMk9qN0ZtSnRSdnkvSjZZ?= =?utf-8?B?cE1nZnU0bmtwbDR6SDBoTkNJODFWcUx0TVk2ZERMYUZaR2RPekxUQXdicUVG?= =?utf-8?B?VUpWVXNIZGRNWkd2dXdqWnpQbk9KcmhPZkdvQWZDT0Vzb24wRXhxWG1zY0hE?= =?utf-8?B?UFkxUHR6SW5IekRnMUVTNHpYNVNUTXZPMC9ZamFWNXpES0R0dUJXdjkwdTl1?= =?utf-8?B?b1dRNDIra05PdG9uWGJPNnpyRi92RkVxbG43TVJ3RlltWVdtaEFSWFFsWVU1?= =?utf-8?B?T3hyOGhwcGF6ZXdwSWRISXg1c0RBQVpDU1pKaWU0ZlEySEF1SnNBTTRzb29j?= =?utf-8?B?bVdwQjBSMTNiZjlsS3l0bEZTSXZDTncrTHVwSU1iczFpei94VmoxWHZLMXRy?= =?utf-8?B?czcwUVFrVldIZytBZmFRVmUxWVl0UmZWUXFxZFMrT2VxdkNJcXFLcy8yVTFF?= =?utf-8?B?SEJ4TmdwdWU2UmxnYnBUdWFoSUdBeEpGLzhEeHF0alN0TTRFZnFCWXMyQVEy?= =?utf-8?B?Um5ENXpDY0thVE5EbmJZcEt1QW5KM3J0NS9RY1lLeXYrbTZQUFhERnJJYjVa?= =?utf-8?B?MmtEWmxJSUhnZXJWVTRWdU52VklrMUxOMGFTWlU1Q1BnQVNMeGR6UzVna3g2?= =?utf-8?B?RElVZDNUOHlaYUhCMW5xOTJDeElXV2ZzaVpyRHN3eksvcXQ5SlF1MW5oY0RF?= =?utf-8?B?WkczQ3NZNDdYQnZvcGUrZGVRVU5KOUFldS82ZmExb3NrZ0Q3YXk4LzZ3RllI?= =?utf-8?B?WC9UUkJISWlCRVN3ejdORmw0Y3MxOHZzdTdoaGhSNXVnWGF3VGN4bkc5em11?= =?utf-8?B?clhOMVYvN3pHSWo1WEN4b2VTSWlkQWNLbHNmd1dMeGhWRUozYmhjNVl3Q1Qz?= =?utf-8?B?b0tMME1QTVRKeDR3T0J1WElFMVMrQkJwdG9kTDVGYXZlRXdjbzYzR1dTUW9s?= =?utf-8?B?TFEvaXFURWZQYzgwVzRWbkgvem1ZLzZyL0ZQamVOZVdhM3hSSTRlZjQ4ZERr?= =?utf-8?B?TFA0Vkw2VCtaT1IwYzc2T3Byb3ZOd3NZdnBIeUV1eUM4L0tDN3FkQ3llckQ2?= =?utf-8?B?WFBtd3d2L1d4RGRCSGNlQzI3Ulltbk1uQlE1QStsdHdMdkZMTFAvN3g5Qnli?= =?utf-8?B?dWl0UXJ0RVNWc1VQZUdVdGUwZ2lRQy93SGUzZDNRNkt2bDdWVk12a3E2Y3lj?= =?utf-8?B?amZKNm9hZGxFNVdGOXptUkxFQTl1NTQ4aERnc3NiYzA3ZjF4N0IvQ3MvQ2gr?= =?utf-8?B?UjFRYnRMcUhodHh6UWU0My9NdU0xZkkwSVd2NVZqY2RLdVQ3akVUT0w0TDcv?= =?utf-8?B?a2NmbU9VNWwxVlZvb3hUUVJoVGowYjhYV0dWZ3ZmWkxMYjdVRkdjVTIvVFp5?= =?utf-8?B?S1pVZ3o5cXE2NGFZVUxyU1JsVmo2c2FETXB2bTlURTJpN1pKZ2lOY0RwZXBa?= =?utf-8?B?M1Qzc0VvWTFibGVOOU1HNmlOSGlQTlE4bGZFTW02YWNMbUo2S2s2MFFXbTNp?= =?utf-8?B?am1aZ1pDSXRhcFIwOE02UXhQY1JWamhaKy9HcXo0UVAzekR6YzdwWEFCdys1?= =?utf-8?B?OFp4cHVIQzhyRGJrMStheFQ5SW1ja1ZYMnh2dUMyMEFYeGN2Tis0ZUxxSUdD?= =?utf-8?B?Ui9XamI3dHpWTHhlSWFlZG1qVmhjRnNZbVg1a3orTUlJVExHUFJXRFkxczd6?= =?utf-8?B?SDY3aXpMdER6eDVIZHdvc3RTVmE5ZDlNOEhsRy9yMFhFT3Z2K3NUMjhOZEtS?= =?utf-8?B?dWhFek82NXBTTms4UVRXN1c1YllxOUpOMXZ6dmJ5VVBTbVpKeklqVG9zZE9a?= =?utf-8?B?KzJadFdkL1Z6QWlxMW16REVGTlNRdEhvOHhwZDgwdVNvN290UFE5b0g4M3Z3?= =?utf-8?B?UG91REQvVWZHU2hNVkVyejZicUE0Q1BYSnBOT1dEWXVQcTczc3ltbHB5NXR5?= =?utf-8?B?KzFCdTZERmY0ZFJUcXVkS2I4ZTBvVjYyS0RWendrRm9MRVJuejJNTUZwQ0tZ?= =?utf-8?B?L3EwQ0ZKWEszTVcrRU5OY01pR1lDZUpsVDBFdEt5dUxHT0dNZ3pzMjN5dTlj?= =?utf-8?B?UnlIU3p2bnpsVWtFODEzQ1hUVHZFTTBPOEtJT3FxMThQMnZ2NEQ5S1Nnam1U?= =?utf-8?Q?OBa8RlGOSYx2aqngUg8IEQEH+PHB+vVsSq8tIgghAXgQ?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HA5FkvMzT+ZNA4hNdrsVYTKqqDUcKyyZXy1pg3jbDsmpo1/h9xrh+l2y2vVM1be640dXPN7C17bxK4DVrOwLq2dSkv2O7H90F04dMJhSDbtFUFhhhnDlnwWvKirqs6ciUtpUmi3uQsDh+NVKFKKTvGi8Zb6I4t5yB8UhVpfwb1uAFY7WxqH7lDSpo8zrJJGEQTTheG4hJBjMkWRFmFzaoPBDiLEJVojnL+wLE9xGJDUESkeqC9SP+wQbHSfdddLBOVb5673/sHd85qdSoR3e9bpGHOAXBZGIEysEO2s7QaB8VPFVCR83Bd6sYCdjvkRkQO4+PXeceBkvQvvET50Ettv2rpoH2FE3MErmagTNMIu7nc1nN39uDAGYfs0o0SP9FZF7RQrETsoFC2EIIsOEuGmfvfVL0ZdwM/seZjVaOAM= Content-Type: multipart/alternative; boundary="_000_LEJPR01MB0460544045836E38F73AE4039C720LEJPR01MB0460DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d1da821e-89b3-4e9b-370d-08d6a16d223f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 13:19:01.6768 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0459 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 13:19:13 -0000 --_000_LEJPR01MB0460544045836E38F73AE4039C720LEJPR01MB0460DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR29ycnksDQoNCkkgYWdyZWUgdG8geW91ciBwcm9wb3NhbCB0b28uDQoNClJlZ2FyZHMsIFJ1 ZWRpZ2VyDQoNClZvbjogdHN2d2cgPHRzdndnLWJvdW5jZXNAaWV0Zi5vcmc+IEltIEF1ZnRyYWcg dm9uIEJSVU5HQVJELCBERUJPUkFIIEENCkdlc2VuZGV0OiBNb250YWcsIDQuIE3DpHJ6IDIwMTkg MjE6MzkNCkFuOiBXYXJyZW4gS3VtYXJpIDx3YXJyZW5Aa3VtYXJpLm5ldD47IGdvcnJ5QGVyZy5h YmRuLmFjLnVrDQpDYzogdHN2d2ctY2hhaXJzIDx0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmc+OyB0c3Z3 Z0BpZXRmLm9yZzsgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IEJsZXNzLCBSb2xhbmQgKFRNKSA8cm9s YW5kLmJsZXNzQGtpdC5lZHU+DQpCZXRyZWZmOiBSZTogW3RzdndnXSBXYXJyZW4gS3VtYXJpJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRzdndnLWxlLXBoYi0wOTogKHdpdGggRElTQ1VTUyBhbmQg Q09NTUVOVCkNCg0KT2sgZm9yIG1lLQ0KRGVib3JhaA0KDQoNCkZyb206IGllc2cgPGllc2ctYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9m IFdhcnJlbiBLdW1hcmkNClNlbnQ6IE1vbmRheSwgTWFyY2ggMDQsIDIwMTkgODoxNSBBTQ0KVG86 IGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4NCkNjOiB0 c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+OyBCUlVOR0FSRCwgREVCT1JBSCBB IDxkYjM1NDZAYXR0LmNvbTxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+PjsgdHN2d2ctY2hhaXJzIDx0 c3Z3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRzdndnLWNoYWlyc0BpZXRmLm9yZz4+OyBJRVNH IDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPj47IEJsZXNzLCBSb2xhbmQgKFRN KSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU8bWFpbHRvOnJvbGFuZC5ibGVzc0BraXQuZWR1Pj47IEJy aWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208bWFpbHRvOmJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbT4+OyBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiA8c3BlbmNl cmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwu Y29tPj4NClN1YmplY3Q6IFJlOiBbdHN2d2ddIFdhcnJlbiBLdW1hcmkncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtdHN2d2ctbGUtcGhiLTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQoN Cg0KT24gTW9uLCBNYXIgNCwgMjAxOSBhdCAzOjA1IEFNIEdvcnJ5IEZhaXJodXJzdCA8Z29ycnlA ZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj4gd3JvdGU6DQoNCg0K SSBoYXZlIGhhZCBhIGxpdHRsZSByZWZsZXhpb24gb24gdGhlIGRpc2N1c3Npb24gYW5kIEkgcXVp dGUgYWdyZWUgdGhlDQpmb2xsb3dpbmcgbmVlZHMgcHJ1bmVkL3Jld3JpdHRlbjoNCg0K4oCcSG93 ZXZlciwgbm9uLUxFIHRyYWZmaWMgKGUuZy4sIEJFIHRyYWZmaWMpIFNIT1VMRCBOT1QgYmUNCnJl bWFya2VkIHRvIEwsIG9uIGEgcmVndWxhciBiYXNpcyB3aXRob3V0IGNvbnNlbnQgb3Iga25vd2xl ZGdlIG9mIHRoZQ0KdXNlci7igJ0NCg0KICAgICBBbmQgSSBkbyBhZ3JlZSB3aXRoIHBydW5pbmcg dGhpcyBmcm9tIHRoZSBub3JtYXRpdmUgdGV4dDoNCiAgICAg4oCcb24gYSByZWd1bGFyIGJhc2lz IHdpdGhvdXQgY29uc2VudCBvciBrbm93bGVkZ2Ugb2YgdGhlDQogICAgIHVzZXIu4oCdDQoNCiAg ICAgSG93ZXZlciwgZXZlbiB0aG91Z2ggdGhlIG9yaWdpbmFsIGhhZCBiZWNvbWUgYSBsaXR0bGUg Z2FibGVkLA0KICAgICBpdCB3YXMgYW4gYXR0ZW1wdCB0byBjYXB0dXJlIHRoYXQgdGhlcmUgKkFS RSogaW1wbGljYXRpb25zLg0KICAgICBXZSBzcGVudCB0aW1lIHRhbGtpbmcgYWJvdXQgdGhlc2Ug aW1wbGljYXRpb25zIGluIHRoZSBXRyBhbmQNCiAgICAgYSBsb3Qgb2YgdGltZSB0cnlpbmcgdG8g d3JpdGUgdGV4dCB0byBhdm9pZCBhY2NpZGVudGFsIHJlbWFya2luZy4NCg0KICAgICBJIGFtIHN0 aWxsIHNvbWV3aGF0IHVuY2xlYXIgaG93IGFuIG9wZXJhdG9yIGNvdWxkIHNhZmVseSBqdXN0IG1h cA0KICAgICB0cmFmZmljIHRvIHRoZSBMRSAgIGNsYXNzLCB3aXRob3V0IGEgcHJpb3JpIGtub3dp bmcgd2hhdCB0aGUgZmxvdw0KICAgICBleHBlY3RzLiBTdXJlLCBhbiBvcGVyYXRvciBjb3VsZCBz ZXR1cCBhIEJBLWNsYXNzaWZpZXIgYW5kIHVuZGVyc3RhbmQNCiAgICAgdGhhdCBhcHBsaWNhdGlv biDigJxY4oCdIHdhbnRzIHRoaXMgc2VydmljZS4uIElmIGl0IGRvZXMgdGhhdCB0aGVuIHRoYXQN CiAgICAgdHJhZmZpYyB3aWxsIHJlY2VpdmUgdGhlIHRyZWF0bWVudCBvZiBMRSB0cmFmZmljIGZv ciB0aGUgcmVzdCBvZiB0aGUNCiAgICAgcGF0aC4gSWYgSSB1bmRlcnN0b29kIHRoZSBpbnRlbnRp b24sIGl0IHdhcyB0byByZW1pbmQgcGVvcGxlIHRoYXQNCiAgICAgdGhpcyBpc27igJl0IGp1c3Qg YW5vdGhlciDigJxsb3dlciBsZXZlbOKAnSBpbiB0aGUgZGlmZnNlcnYgaGllcmFyY2h5IC0NCiAg ICAgdHJhZmZpYyBtYXBwZWQgdG8gdGhpcyBjbGFzcyBuZWVkcyB0byBiZSByZXNpbGllbnQgdG8g c3RhcnZhdGlvbiwNCiAgICAgYW5kIGV4cGVjdCB0aGF0IHRoaXMgd2lsbCBoYXBwZW4uDQoNCiAg ICAgSSBzdWdnZXN0IGFuIGV4cGxhbmF0aW9uIGNvdWxkIGJlIGFkZGVkIGFmdGVyIHRoZSBjbGF1 c2UgdG8gYmUNCiAgICAgcHJ1bmVkIHRvIGF2b2lkIHRoaXMgbm90IHdvcmtpbmcgb3V0IHdlbGw6 DQoNCiAgICAg4oCcUmVtYXJraW5nIHRyYWZmaWMgZnJvbSBhbm90aGVyIFBIQiByZXN1bHRzIGlu IHRoYXQgdHJhZmZpYw0KICAgICBiZWluZyAiZG93bmdyYWRlZOKAnS4gVGhpcyBjaGFuZ2VzIHRo ZSB3YXkgdGhlIG5ldHdvcmsgdHJlYXRzIHRoaXMNCiAgICAgdHJhZmZpYyBhbmQgaXQgaXMgaW1w b3J0YW50IG5vdCB0byB2aW9sYXRlIHRoZSBvcGVyYXRpb25hbA0KICAgICBvYmplY3RpdmVzIG9m IHRoZSBvcmlnaW5hbCBQSEIu4oCdDQoNClRoYXQgc291bmRzIHJlYXNvbmFibGUgdG8gbWUuLi4u Lg0KDQpXDQoNCg0KDQpHb3JyeQ0KDQpQLlMuIFJvbGFuZCwgSSBhbHNvIGp1c3Qgc2F3IGEgZmV3 IGNsYXVzZXMgc2F5aW5nIOKAnEluIGNhc2UgLi4uLuKAnSwgSSBkb27igJl0DQprbm93IGhvdyBJ IG1pc3NlZCB0aGF0IGluIG15IHJldmlldywgYnV0IHRoZXNlIHJlYWQgYW1iaWd1b3VzbHkgdG8g bWU6IEkNCmNvdWxkIGl0IHdvdWxkIGJlIGJldHRlciBpZiB0aGUgcGhyYXNlIHdhcyDigJxJbiB0 aGUgY2FzZSB0aGF04oCdLg0KDQpPbiAyOC8wMi8yMDE5LCAxODozMCwgU3BlbmNlciBEYXdraW5z IGF0IElFVEYgd3JvdGU6DQo+IFRoYW5rcywgRGVib3JhaCENCj4NCj4gUm9sYW5kLCBjb3VsZCB5 b3Ugc3VibWl0IGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0LCBzbyBJIGNhbiBhcHBy b3ZlDQo+IGl0IGJlZm9yZSBXZWRuZXNkYXkgb2YgSUVURiAxMDQ/IDotKQ0KPg0KPiBUaGFua3Ms DQo+DQo+IFNwZW5jZXINCj4NCj4gT24gVGh1LCBGZWIgMjgsIDIwMTkgYXQgMTA6MTggQU0gQlJV TkdBUkQsIERFQk9SQUggQTxkYjM1NDZAYXR0LmNvbTxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+PiAg d3JvdGU6DQo+DQo+PiBZZXMsIEnigJltIG9rIHdpdGggdGhlIGFiYnJldmlhdGVkIHNlbnRlbmNl IGFzIFdhcnJlbiBhbmQgb3RoZXJzIHN1Z2dlc3RlZA0KPj4g4oCcIk5vbi1MRSB0cmFmZmljIChl LmcuLCBCRSB0cmFmZmljKSBTSE9VTEQgTk9UIGJlIHJlbWFya2VkIHRvIExFLiINCj4+DQo+Pg0K Pj4NCj4+IFRoYW5rcyBldmVyeW9uZS0NCj4+DQo+PiBEZWJvcmFoDQo+Pg0KPj4NCj4+DQo+PiAq RnJvbToqIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwu Y29tPG1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4+DQo+PiAqU2VudDoqIFRo dXJzZGF5LCBGZWJydWFyeSAyOCwgMjAxOSA5OjI3IEFNDQo+PiAqVG86KiBCbGVzcywgUm9sYW5k IChUTSk8cm9sYW5kLmJsZXNzQGtpdC5lZHU8bWFpbHRvOnJvbGFuZC5ibGVzc0BraXQuZWR1Pj4N Cj4+ICpDYzoqIEJyaWFuIEUgQ2FycGVudGVyPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTxt YWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPj47IFdhcnJlbiBLdW1hcmk8DQo+PiB3 YXJyZW5Aa3VtYXJpLm5ldDxtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQ+PjsgdHN2d2dAaWV0Zi5v cmc8bWFpbHRvOnRzdndnQGlldGYub3JnPjsgQlJVTkdBUkQsIERFQk9SQUggQTxkYjM1NDZAYXR0 LmNvbTxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+PjsNCj4+IElFU0c8aWVzZ0BpZXRmLm9yZzxtYWls dG86aWVzZ0BpZXRmLm9yZz4+OyB0c3Z3Zy1jaGFpcnM8dHN2d2ctY2hhaXJzQGlldGYub3JnPG1h aWx0bzp0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmc+Pg0KPj4gKlN1YmplY3Q6KiBSZTogW3RzdndnXSBX YXJyZW4gS3VtYXJpJ3MgRGlzY3VzcyBvbg0KPj4gZHJhZnQtaWV0Zi10c3Z3Zy1sZS1waGItMDk6 ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+Pg0KPj4NCj4+DQo+PiBTbywgV2FycmVuL0Rl Ym9yYWgsIGFyZSB3ZSBnb29kIG9uIFNIT1VMRCBOT1QgaGVyZT8NCj4+DQo+Pg0KPj4NCj4+IFNw ZW5jZXINCj4+DQo+Pg0KPj4NCj4+IE9uIFRodSwgRmViIDI4LCAyMDE5IGF0IDI6MzggQU0gQmxl c3MsIFJvbGFuZCAoVE0pPHJvbGFuZC5ibGVzc0BraXQuZWR1PG1haWx0bzpyb2xhbmQuYmxlc3NA a2l0LmVkdT4+DQo+PiB3cm90ZToNCj4+DQo+PiBIaSwNCj4+DQo+PiBBbSAyNy4wMi4xOSB1bSAy Mjo0NCBzY2hyaWViIEJyaWFuIEUgQ2FycGVudGVyOg0KPj4+IE9uIDI4LUZlYi0xOSAxMDoxOCwg U3BlbmNlciBEYXdraW5zIGF0IElFVEYgd3JvdGU6DQo+Pj4+IEhpLCBXYXJyZW4sDQo+Pj4+DQo+ Pj4+IE9uIFdlZCwgRmViIDI3LCAyMDE5IGF0IDM6MTAgUE0gV2FycmVuIEt1bWFyaTx3YXJyZW5A a3VtYXJpLm5ldDxtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQ+Pg0KPj4gd3JvdGU6DQo+Pj4+Pg0K Pj4+Pj4gT24gV2VkLCBGZWIgMjcsIDIwMTkgYXQgMTI6MTcgUE0gU3BlbmNlciBEYXdraW5zIGF0 IElFVEY8DQo+Pj4+PiBzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86c3BlbmNl cmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+PiAgd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4+IFNvLCBqdXN0 IHRvIGZvbGxvdyB1cCwNCj4+Pj4+Pg0KPj4+Pj4+IE9uIE1vbiwgRmViIDI1LCAyMDE5IGF0IDI6 NDggQU08UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVr b20uZGU+PiAgd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+Pj4gRGVib3JhaCwgV2FycmVuLA0KPj4+Pj4+ Pg0KPj4+Pj4+PiBJRVRGIGRvZXNuJ3Qgc3BlY2lmeSBTTEFzIG9yIHJlbGF0ZWQgdGV4dCwgSSBh Z3JlZS4gVGhlIExFDQo+PiBwZXJmb3JtYW5jZQ0KPj4+Pj4+PiBpcyB3b3JzZSB0aGFuIGRlZmF1 bHQgZm9yd2FyZGluZy4gSSdtIHVuaGFwcHkgaWYgbXkgcGVlciBkZW1vdGVzIG15DQo+PiB0cmFm ZmljDQo+Pj4+Pj4+IHRvIExFIGFuZCBwb2ludHMgdG8gYW4gSUVURiBzdGFuZGFyZCBhbGxvd2lu ZyB0aGlzLiAgV2hhdCBhYm91dDoNCj4+Pj4+Pj4NCj4+Pj4+Pj4gRElTQ1VTU0VEIENIQU5HRSBz byBmYXI6DQo+Pj4+Pj4+IE5vbi1MRSB0cmFmZmljIChlLmcuLCBCRSB0cmFmZmljKSBTSE9VTEQg Tk9UIGJlDQo+Pj4+Pj4+IHJlbWFya2VkIHRvIExFIG9uIGEgcmVndWxhciBiYXNpcy4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gU09NRVdIQVQgTU9SRSBQUkVDSVNFTFkgREVGSU5FRCBPUFRJT04NCj4+Pj4+ Pj4gTm9uLUxFIHRyYWZmaWMgKGUuZy4sIEJFIHRyYWZmaWMpIE1VU1QgTk9UIGJlDQo+Pj4+Pj4+ IHJlbWFya2VkIHRvIExFIGJ5IGRlZmF1bHQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEknZCBsaWtlIHRv IGF2b2lkIExFIHRvIHJlc3VsdCBpbiBhICJkZWZhdWx0IGJlbG93IGRlZmF1bHQiIGFuZA0KPj4g cHJlZmVyDQo+Pj4+Pj4+IElFVEYgc3RhbmRhcmRzIG5vdCBhbGxvdyBmYW5jeSBpbnRlcnByZXRh dGlvbnMuLg0KPj4+Pj4+Pg0KPj4+Pj4+IFRoaXMgZG9jdW1lbnQgd2FzIGFwcHJvdmVkIG9uIHRo ZSBsYXN0IHRlbGVjaGF0LCBidXQgd2UncmUgaGF2aW5nIGENCj4+Pj4+PiBEaXNjdXNzLWxldmVs IGRpc2N1c3Npb24gYWJvdXQgaXQgbm93LCB3aGljaCBtZWFucyB0aGF0IEkgc2hvdWxkIGJlDQo+ PiB0YWtpbmcNCj4+Pj4+PiB0aGlzIGNvbnZlcnNhdGlvbiB2ZXJ5IHNlcmlvdXNseSAoYmVjYXVz ZSAibmV3IHRlY2huaWNhbCBvYmplY3Rpb25zDQo+PiBhcmUNCj4+Pj4+PiBhbHdheXMgaW4gb3Jk ZXIiKS4NCj4+Pj4+Pg0KPj4+Pj4+IEFtIEkgdW5kZXJzdGFuZGluZyB0aGF0DQo+Pj4+Pj4NCj4+ Pj4+PiAgICAgLSBEZWJvcmFoIChhbmQsIElJUkMsIFdhcnJlbikgYXJlIHRoaW5raW5nIHRoYXQg TVVTVCBpcyB0aGUgd3JvbmcNCj4+Pj4+PiAgICAgYW5zd2VyLCBiZWNhdXNlIHdlIGRvbid0IHRl bGwgb3BlcmF0b3JzIGhvdyB0byBtYXJrIHRyYWZmaWMgaW4NCj4+IHRoZWlyDQo+Pj4+Pj4gICAg IG5ldHdvcmtzLCBidXQNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+PiBXYXJyZW4gaXMgdGhpbmtpbmcg dGhhdCwgaWYgeW91IHByb3ZpZGUgYW55IHNvcnQgb2YgU0hPVUxEL01VU1QNCj4+IGd1aWRhbmNl DQo+Pj4+PiByZWdhcmRpbmcgd2hlbiBpdCBpcyBhcHByb3ByaWF0ZSB0byBtYXJrICJhYm5vcm1h bCIgdHJhZmZpYywgeW91IGhhdmUNCj4+IHRvIGJlDQo+Pj4+PiBhYmxlIHRvIGRlZmluZSB3aGF0 IHlvdSBtZWFuIGJ5IG5vcm1hbCBhbmQgYWJub3JtYWwuLi4NCj4+Pj4+DQo+Pj4+PiBQZXJzb25h bGx5IEkgd291bGQgdGhpbmsgdGhhdCBqdXN0OiAiTm9uLUxFIHRyYWZmaWMgKGUuZy4sIEJFIHRy YWZmaWMpDQo+Pj4+PiBTSE9VTEQgTk9UIGJlIHJlbWFya2VkIHRvIExFLiIgKG9yIE1VU1QgTk9U KSB3aXRob3V0IGFueSBxdWFsaWZpZXJzDQo+PiB3b3VsZA0KPj4+Pj4gYmUgYmVzdCAtLSB3ZSBh cmUgbm90IHRoZSBwcm90b2NvbCBwb2xpY2UgYW5kIGRvbid0IGhhdmUgYW4gZW5mb3JjZW1lbnQN Cj4+Pj4+IGFybSwgc28gd2UgY2Fubm90IHJlYWxseSBzdG9wIGl0LiBXaGVyZSBJIHRoaW5rIHdl IHJ1biBpbnRvIHRyb3VibGUgaXMNCj4+Pj4+IHNheWluZyAiSXQgaXMgT0sgdG8gZG8gdGhpcyBv biBUaHVyc2RheXMgd2hlbiB0aGVyZSBpcyBhIGhhbGYgbW9vbiBhbmQNCj4+IHRoZQ0KPj4+Pj4g d2luZCBibG93cyBmcm9tIHRoZSBTb3V0aC1FYXN0LCBidXQgbm90IGF0IG90aGVyIHRpbWVzIiAo d2hhdCBpZiB0aGVzZQ0KPj4gaXMNCj4+Pj4+IG9ubHkgYSBzbGlnaHQgYnJlZXplPyBUaHVyc2Rh eSB3aGVyZT8gb3IgYSB3YXhpbmcgZ2liYm91cyBtb29uPykgLSBJDQo+PiB0aGluaw0KPj4+Pj4g d2Ugc2hvdWxkIGp1c3Qgc2F5ICJZb3Ugc2hvdWxkbid0IHJlbWFyayIsd2l0aCB0aGUgdW5kZXJz dGFuZGluZyB0aGF0DQo+PiBzb21lDQo+Pj4+PiB3aWxsIGFuZCBub3Qgb3BlbiB0aGUgInVuZGVy IHRoZXNlIGNpcmN1bXN0YW5jZXMiIGNhbiBvZiB3b3JtcyBhdCBhbGwNCi0tDQpJIGRvbid0IHRo aW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFk IGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLg0KVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vh c2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdyZXQgYXQgaGF2aW5n IGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpciBvZiBw YW50cy4NCiAgIC0tLW1hZg0K --_000_LEJPR01MB0460544045836E38F73AE4039C720LEJPR01MB0460DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFn ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEdvcnJ5 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgYWdyZWUgdG8geW91ciBwcm9wb3Nh bCB0b28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcywgUnVlZGlnZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+Vm9uOjwvYj4gdHN2d2cgJmx0O3RzdndnLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IDxiPkltIEF1ZnRyYWcgdm9uDQo8L2I+QlJVTkdBUkQsIERFQk9SQUggQTxicj4NCjxiPkdl c2VuZGV0OjwvYj4gTW9udGFnLCA0LiBNw6RyeiAyMDE5IDIxOjM5PGJyPg0KPGI+QW46PC9iPiBX YXJyZW4gS3VtYXJpICZsdDt3YXJyZW5Aa3VtYXJpLm5ldCZndDs7IGdvcnJ5QGVyZy5hYmRuLmFj LnVrPGJyPg0KPGI+Q2M6PC9iPiB0c3Z3Zy1jaGFpcnMgJmx0O3RzdndnLWNoYWlyc0BpZXRmLm9y ZyZndDs7IHRzdndnQGlldGYub3JnOyBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgQmxlc3Ms IFJvbGFuZCAoVE0pICZsdDtyb2xhbmQuYmxlc3NAa2l0LmVkdSZndDs8YnI+DQo8Yj5CZXRyZWZm OjwvYj4gUmU6IFt0c3Z3Z10gV2FycmVuIEt1bWFyaSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10 c3Z3Zy1sZS1waGItMDk6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T2sgZm9yIG1lLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5EZWJvcmFoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gaWVzZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ct Ym91bmNlc0BpZXRmLm9yZyI+aWVzZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJl aGFsZiBPZiA8L2I+V2FycmVuIEt1bWFyaTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNo IDA0LCAyMDE5IDg6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpnb3JyeUBl cmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8 YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5vcmciPnRzdndnQGlldGYub3JnPC9hPjsgQlJVTkdB UkQsIERFQk9SQUggQSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiMzU0NkBhdHQuY29tIj5kYjM1NDZA YXR0LmNvbTwvYT4mZ3Q7OyB0c3Z3Zy1jaGFpcnMgJmx0OzxhIGhyZWY9Im1haWx0bzp0c3Z3Zy1j aGFpcnNAaWV0Zi5vcmciPnRzdndnLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7OyBJRVNHICZsdDs8 YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7Ow0KIEJs ZXNzLCBSb2xhbmQgKFRNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGFuZC5ibGVzc0BraXQuZWR1 Ij5yb2xhbmQuYmxlc3NAa2l0LmVkdTwvYT4mZ3Q7OyBCcmlhbiBFIENhcnBlbnRlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSI+YnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tPC9hPiZndDs7IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGICZsdDs8YSBocmVm PSJtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20iPnNwZW5jZXJkYXdraW5zLmll dGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gV2Fy cmVuIEt1bWFyaSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10c3Z3Zy1sZS1waGItMDk6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1vbiwgTWFy IDQsIDIwMTkgYXQgMzowNSBBTSBHb3JyeSBGYWlyaHVyc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpn b3JyeUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxicj4NCkkgaGF2ZSBoYWQgYSBsaXR0bGUgcmVmbGV4aW9uIG9uIHRoZSBk aXNjdXNzaW9uIGFuZCBJIHF1aXRlIGFncmVlIHRoZSA8YnI+DQpmb2xsb3dpbmcgbmVlZHMgcHJ1 bmVkL3Jld3JpdHRlbjo8YnI+DQo8YnI+DQrigJxIb3dldmVyLCBub24tTEUgdHJhZmZpYyAoZS5n LiwgQkUgdHJhZmZpYykgU0hPVUxEIE5PVCBiZTxicj4NCnJlbWFya2VkIHRvIEwsIG9uIGEgcmVn dWxhciBiYXNpcyB3aXRob3V0IGNvbnNlbnQgb3Iga25vd2xlZGdlIG9mIHRoZTxicj4NCnVzZXIu 4oCdPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtBbmQgSSBkbyBhZ3JlZSB3aXRoIHBy dW5pbmcgdGhpcyBmcm9tIHRoZSBub3JtYXRpdmUgdGV4dDo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwO+KAnG9uIGEgcmVndWxhciBiYXNpcyB3aXRob3V0IGNvbnNlbnQgb3Iga25vd2xlZGdlIG9m IHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7dXNlci7igJ08YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwO0hvd2V2ZXIsIGV2ZW4gdGhvdWdoIHRoZSBvcmlnaW5hbCBoYWQgYmVjb21l IGEgbGl0dGxlIGdhYmxlZCw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2l0IHdhcyBhbiBhdHRl bXB0IHRvIGNhcHR1cmUgdGhhdCB0aGVyZSAqQVJFKiBpbXBsaWNhdGlvbnMuPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDtXZSBzcGVudCB0aW1lIHRhbGtpbmcgYWJvdXQgdGhlc2UgaW1wbGljYXRp b25zIGluIHRoZSBXRyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2EgbG90IG9mIHRpbWUg dHJ5aW5nIHRvIHdyaXRlIHRleHQgdG8gYXZvaWQgYWNjaWRlbnRhbCByZW1hcmtpbmcuPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtJIGFtIHN0aWxsIHNvbWV3aGF0IHVuY2xlYXIgaG93 IGFuIG9wZXJhdG9yIGNvdWxkIHNhZmVseSBqdXN0IG1hcDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7dHJhZmZpYyB0byB0aGUgTEUmbmJzcDsgJm5ic3A7Y2xhc3MsIHdpdGhvdXQgYSBwcmlvcmkg a25vd2luZyB3aGF0IHRoZSBmbG93PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtleHBlY3RzLiBT dXJlLCBhbiBvcGVyYXRvciBjb3VsZCBzZXR1cCBhIEJBLWNsYXNzaWZpZXIgYW5kIHVuZGVyc3Rh bmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQgYXBwbGljYXRpb24g4oCcWOKAnSB3YW50 cyB0aGlzIHNlcnZpY2UuLiBJZiBpdCBkb2VzIHRoYXQgdGhlbiB0aGF0PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDt0cmFmZmljIHdpbGwgcmVjZWl2ZSB0aGUgdHJlYXRtZW50IG9mIExFIHRyYWZm aWMgZm9yIHRoZSByZXN0IG9mIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7cGF0aC4gSWYg SSB1bmRlcnN0b29kIHRoZSBpbnRlbnRpb24sIGl0IHdhcyB0byByZW1pbmQgcGVvcGxlIHRoYXQ8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3RoaXMgaXNu4oCZdCBqdXN0IGFub3RoZXIg4oCcbG93 ZXIgbGV2ZWzigJ0gaW4gdGhlIGRpZmZzZXJ2IGhpZXJhcmNoeSAtPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDt0cmFmZmljIG1hcHBlZCB0byB0aGlzIGNsYXNzIG5lZWRzIHRvIGJlIHJlc2lsaWVu dCB0byBzdGFydmF0aW9uLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7YW5kIGV4cGVjdCB0aGF0 IHRoaXMgd2lsbCBoYXBwZW4uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtJIHN1Z2dl c3QgYW4gZXhwbGFuYXRpb24gY291bGQgYmUgYWRkZWQgYWZ0ZXIgdGhlIGNsYXVzZSB0byBiZTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7cHJ1bmVkIHRvIGF2b2lkIHRoaXMgbm90IHdvcmtpbmcg b3V0IHdlbGw6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDvigJxSZW1hcmtpbmcgdHJh ZmZpYyBmcm9tIGFub3RoZXIgUEhCIHJlc3VsdHMgaW4gdGhhdCB0cmFmZmljPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDtiZWluZyAmcXVvdDtkb3duZ3JhZGVk4oCdLiBUaGlzIGNoYW5nZXMgdGhl IHdheSB0aGUgbmV0d29yayB0cmVhdHMgdGhpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7dHJh ZmZpYyBhbmQgaXQgaXMgaW1wb3J0YW50IG5vdCB0byB2aW9sYXRlIHRoZSBvcGVyYXRpb25hbDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7b2JqZWN0aXZlcyBvZiB0aGUgb3JpZ2luYWwgUEhCLuKA nTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlRoYXQgc291bmRzIHJlYXNvbmFibGUgdG8gbWUuLi4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KR29ycnk8YnI+ DQo8YnI+DQpQLlMuIFJvbGFuZCwgSSBhbHNvIGp1c3Qgc2F3IGEgZmV3IGNsYXVzZXMgc2F5aW5n IOKAnEluIGNhc2UgLi4uLuKAnSwgSSBkb27igJl0PGJyPg0Ka25vdyBob3cgSSBtaXNzZWQgdGhh dCBpbiBteSByZXZpZXcsIGJ1dCB0aGVzZSByZWFkIGFtYmlndW91c2x5IHRvIG1lOiBJPGJyPg0K Y291bGQgaXQgd291bGQgYmUgYmV0dGVyIGlmIHRoZSBwaHJhc2Ugd2FzIOKAnEluIHRoZSBjYXNl IHRoYXTigJ0uPGJyPg0KPGJyPg0KT24gMjgvMDIvMjAxOSwgMTg6MzAsIFNwZW5jZXIgRGF3a2lu cyBhdCBJRVRGIHdyb3RlOjxicj4NCiZndDsgVGhhbmtzLCBEZWJvcmFoITxicj4NCiZndDs8YnI+ DQomZ3Q7IFJvbGFuZCwgY291bGQgeW91IHN1Ym1pdCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhp cyBkcmFmdCwgc28gSSBjYW4gYXBwcm92ZTxicj4NCiZndDsgaXQgYmVmb3JlIFdlZG5lc2RheSBv ZiBJRVRGIDEwND8gOi0pPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDs8YnI+ DQomZ3Q7IFNwZW5jZXI8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBUaHUsIEZlYiAyOCwgMjAxOSBh dCAxMDoxOCBBTSBCUlVOR0FSRCwgREVCT1JBSCBBJmx0OzxhIGhyZWY9Im1haWx0bzpkYjM1NDZA YXR0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRiMzU0NkBhdHQuY29tPC9hPiZndDsmbmJzcDsgd3Jv dGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IFllcywgSeKAmW0gb2sgd2l0aCB0aGUgYWJicmV2 aWF0ZWQgc2VudGVuY2UgYXMgV2FycmVuIGFuZCBvdGhlcnMgc3VnZ2VzdGVkPGJyPg0KJmd0OyZn dDsg4oCcJnF1b3Q7Tm9uLUxFIHRyYWZmaWMgKGUuZy4sIEJFIHRyYWZmaWMpIFNIT1VMRCBOT1Qg YmUgcmVtYXJrZWQgdG8gTEUuJnF1b3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzIGV2ZXJ5b25lLTxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgRGVib3JhaDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICpGcm9tOiogU3BlbmNlciBEYXdraW5zIGF0IElFVEYmbHQ7PGEg aHJlZj0ibWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICpT ZW50OiogVGh1cnNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE5IDk6MjcgQU08YnI+DQomZ3Q7Jmd0OyAq VG86KiBCbGVzcywgUm9sYW5kIChUTSkmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGFuZC5ibGVzc0Br aXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+cm9sYW5kLmJsZXNzQGtpdC5lZHU8L2E+Jmd0Ozxicj4N CiZndDsmZ3Q7ICpDYzoqIEJyaWFuIEUgQ2FycGVudGVyJmx0OzxhIGhyZWY9Im1haWx0bzpicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5icmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb208L2E+Jmd0OzsgV2FycmVuIEt1bWFyaSZsdDs8YnI+DQomZ3Q7Jmd0OyA8YSBo cmVmPSJtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQiIHRhcmdldD0iX2JsYW5rIj53YXJyZW5Aa3Vt YXJpLm5ldDwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCnRzdndnQGlldGYub3JnPC9hPjsgQlJVTkdBUkQsIERFQk9SQUggQSZsdDs8YSBo cmVmPSJtYWlsdG86ZGIzNTQ2QGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj5kYjM1NDZAYXR0LmNv bTwvYT4mZ3Q7Ozxicj4NCiZndDsmZ3Q7IElFU0cmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXNnQGlldGYub3JnPC9hPiZndDs7IHRzdndnLWNoYWly cyZsdDs8YSBocmVmPSJtYWlsdG86dHN2d2ctY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dHN2d2ctY2hhaXJzQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAqU3ViamVjdDoq IFJlOiBbdHN2d2ddIFdhcnJlbiBLdW1hcmkncyBEaXNjdXNzIG9uPGJyPg0KJmd0OyZndDsgZHJh ZnQtaWV0Zi10c3Z3Zy1sZS1waGItMDk6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgU28sIFdh cnJlbi9EZWJvcmFoLCBhcmUgd2UgZ29vZCBvbiBTSE9VTEQgTk9UIGhlcmU/PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgU3BlbmNlcjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIFRo dSwgRmViIDI4LCAyMDE5IGF0IDI6MzggQU0gQmxlc3MsIFJvbGFuZCAoVE0pJmx0OzxhIGhyZWY9 Im1haWx0bzpyb2xhbmQuYmxlc3NAa2l0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnJvbGFuZC5ibGVz c0BraXQuZWR1PC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IEhpLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQW0gMjcuMDIuMTkgdW0g MjI6NDQgc2NocmllYiBCcmlhbiBFIENhcnBlbnRlcjo8YnI+DQomZ3Q7Jmd0OyZndDsgT24gMjgt RmViLTE5IDEwOjE4LCBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiB3cm90ZTo8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IEhpLCBXYXJyZW4sPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgT24gV2VkLCBGZWIgMjcsIDIwMTkgYXQgMzoxMCBQTSBXYXJyZW4gS3VtYXJpJmx0 OzxhIGhyZWY9Im1haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPndhcnJl bkBrdW1hcmkubmV0PC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIFdlZCwgRmViIDI3LCAyMDE5 IGF0IDEyOjE3IFBNIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGJmx0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPC9hPiZndDsmbmJz cDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgU28sIGp1c3QgdG8gZm9sbG93IHVwLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBNb24sIEZlYiAyNSwgMjAxOSBh dCAyOjQ4IEFNJmx0OzxhIGhyZWY9Im1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGUiIHRh cmdldD0iX2JsYW5rIj5SdWVkaWdlci5HZWliQHRlbGVrb20uZGU8L2E+Jmd0OyZuYnNwOyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IERlYm9yYWgsIFdhcnJlbiw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJRVRGIGRvZXNuJ3Qgc3BlY2lm eSBTTEFzIG9yIHJlbGF0ZWQgdGV4dCwgSSBhZ3JlZS4gVGhlIExFPGJyPg0KJmd0OyZndDsgcGVy Zm9ybWFuY2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIHdvcnNlIHRoYW4g ZGVmYXVsdCBmb3J3YXJkaW5nLiBJJ20gdW5oYXBweSBpZiBteSBwZWVyIGRlbW90ZXMgbXk8YnI+ DQomZ3Q7Jmd0OyB0cmFmZmljPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBM RSBhbmQgcG9pbnRzIHRvIGFuIElFVEYgc3RhbmRhcmQgYWxsb3dpbmcgdGhpcy4mbmJzcDsgV2hh dCBhYm91dDo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBESVNDVVNTRUQgQ0hBTkdFIHNvIGZhcjo8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vbi1MRSB0cmFmZmljIChlLmcuLCBCRSB0cmFmZmljKSBT SE9VTEQgTk9UIGJlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZW1hcmtlZCB0 byBMRSBvbiBhIHJlZ3VsYXIgYmFzaXMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU09NRVdIQVQgTU9SRSBQUkVDSVNF TFkgREVGSU5FRCBPUFRJT048YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vbi1M RSB0cmFmZmljIChlLmcuLCBCRSB0cmFmZmljKSBNVVNUIE5PVCBiZTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgcmVtYXJrZWQgdG8gTEUgYnkgZGVmYXVsdC48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJ J2QgbGlrZSB0byBhdm9pZCBMRSB0byByZXN1bHQgaW4gYSAmcXVvdDtkZWZhdWx0IGJlbG93IGRl ZmF1bHQmcXVvdDsgYW5kPGJyPg0KJmd0OyZndDsgcHJlZmVyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJRVRGIHN0YW5kYXJkcyBub3QgYWxsb3cgZmFuY3kgaW50ZXJwcmV0YXRp b25zLi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRoaXMgZG9jdW1lbnQgd2FzIGFwcHJvdmVkIG9uIHRoZSBsYXN0IHRlbGVj aGF0LCBidXQgd2UncmUgaGF2aW5nIGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRGlz Y3Vzcy1sZXZlbCBkaXNjdXNzaW9uIGFib3V0IGl0IG5vdywgd2hpY2ggbWVhbnMgdGhhdCBJIHNo b3VsZCBiZTxicj4NCiZndDsmZ3Q7IHRha2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0aGlzIGNvbnZlcnNhdGlvbiB2ZXJ5IHNlcmlvdXNseSAoYmVjYXVzZSAmcXVvdDtuZXcgdGVj aG5pY2FsIG9iamVjdGlvbnM8YnI+DQomZ3Q7Jmd0OyBhcmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgYWx3YXlzIGluIG9yZGVyJnF1b3Q7KS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQW0gSSB1bmRlcnN0YW5kaW5nIHRo YXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOy0gRGVib3JhaCAoYW5kLCBJSVJDLCBXYXJyZW4pIGFy ZSB0aGlua2luZyB0aGF0IE1VU1QgaXMgdGhlIHdyb25nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDthbnN3ZXIsIGJlY2F1c2Ugd2UgZG9uJ3QgdGVsbCBv cGVyYXRvcnMgaG93IHRvIG1hcmsgdHJhZmZpYyBpbjxicj4NCiZndDsmZ3Q7IHRoZWlyPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtuZXR3b3JrcywgYnV0 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2FycmVuIGlzIHRoaW5raW5nIHRoYXQsIGlm IHlvdSBwcm92aWRlIGFueSBzb3J0IG9mIFNIT1VMRC9NVVNUPGJyPg0KJmd0OyZndDsgZ3VpZGFu Y2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdhcmRpbmcgd2hlbiBpdCBpcyBhcHByb3By aWF0ZSB0byBtYXJrICZxdW90O2Fibm9ybWFsJnF1b3Q7IHRyYWZmaWMsIHlvdSBoYXZlPGJyPg0K Jmd0OyZndDsgdG8gYmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYmxlIHRvIGRlZmluZSB3 aGF0IHlvdSBtZWFuIGJ5IG5vcm1hbCBhbmQgYWJub3JtYWwuLi48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBlcnNvbmFsbHkgSSB3b3VsZCB0aGlu ayB0aGF0IGp1c3Q6ICZxdW90O05vbi1MRSB0cmFmZmljIChlLmcuLCBCRSB0cmFmZmljKTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNIT1VMRCBOT1QgYmUgcmVtYXJrZWQgdG8gTEUuJnF1b3Q7 IChvciBNVVNUIE5PVCkgd2l0aG91dCBhbnkgcXVhbGlmaWVyczxicj4NCiZndDsmZ3Q7IHdvdWxk PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmUgYmVzdCAtLSB3ZSBhcmUgbm90IHRoZSBwcm90 b2NvbCBwb2xpY2UgYW5kIGRvbid0IGhhdmUgYW4gZW5mb3JjZW1lbnQ8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBhcm0sIHNvIHdlIGNhbm5vdCByZWFsbHkgc3RvcCBpdC4gV2hlcmUgSSB0aGlu ayB3ZSBydW4gaW50byB0cm91YmxlIGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2F5aW5n ICZxdW90O0l0IGlzIE9LIHRvIGRvIHRoaXMgb24gVGh1cnNkYXlzIHdoZW4gdGhlcmUgaXMgYSBo YWxmIG1vb24gYW5kPGJyPg0KJmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg d2luZCBibG93cyBmcm9tIHRoZSBTb3V0aC1FYXN0LCBidXQgbm90IGF0IG90aGVyIHRpbWVzJnF1 b3Q7ICh3aGF0IGlmIHRoZXNlPGJyPg0KJmd0OyZndDsgaXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBvbmx5IGEgc2xpZ2h0IGJyZWV6ZT8gVGh1cnNkYXkgd2hlcmU/IG9yIGEgd2F4aW5nIGdp YmJvdXMgbW9vbj8pIC0gSTxicj4NCiZndDsmZ3Q7IHRoaW5rPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgd2Ugc2hvdWxkIGp1c3Qgc2F5ICZxdW90O1lvdSBzaG91bGRuJ3QgcmVtYXJrJnF1b3Q7 LHdpdGggdGhlIHVuZGVyc3RhbmRpbmcgdGhhdDxicj4NCiZndDsmZ3Q7IHNvbWU8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB3aWxsIGFuZCBub3Qgb3BlbiB0aGUgJnF1b3Q7dW5kZXIgdGhlc2Ug Y2lyY3Vtc3RhbmNlcyZxdW90OyBjYW4gb2Ygd29ybXMgYXQgYWxsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZG9uJ3QgdGhpbmsgdGhlIGV4 ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQgaWRlYSBpbiB0 aGUgZmlyc3QgcGxhY2UuPGJyPg0KVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2VscyBp biB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdyZXQgYXQgaGF2aW5nIGNob3Nl biB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpciBvZiBwYW50cy48 YnI+DQombmJzcDsgJm5ic3A7LS0tbWFmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_LEJPR01MB0460544045836E38F73AE4039C720LEJPR01MB0460DEUP_-- From nobody Tue Mar 5 08:31:52 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B96E2130FC4; Tue, 5 Mar 2019 08:31:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <155180349868.24668.1533917097763591332@ietfa.amsl.com> Date: Tue, 05 Mar 2019 08:31:38 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-13.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:31:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME Authors : Vincent Roca Belkacem Teibi Filename : draft-ietf-tsvwg-rlc-fec-scheme-13.txt Pages : 39 Date : 2019-03-05 Abstract: This document describes two fully-specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over the Galois Field (A.K.A. Finite Field) GF(2), a second one for RLC over the Galois Field GF(2^^8), each time with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes, as defined in [fecframe-ext]. These sliding window FEC codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these sliding window FEC codes offer key advantages with real-time flows in terms of reduced FEC- related latency while often providing improved packet erasure recovery capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-13 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 5 08:49:29 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1FD126D00; Tue, 5 Mar 2019 08:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNA_bIPS-9Bf; Tue, 5 Mar 2019 08:49:25 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 977A91200D8; Tue, 5 Mar 2019 08:49:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.58,444,1544482800"; d="scan'208,217";a="298211535" Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 17:49:22 +0100 From: Vincent Roca Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EE6108FE-3B8E-480C-A116-F6854BA29955" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 5 Mar 2019 17:49:21 +0100 In-Reply-To: <20190212003042.GN56447@kduck.mit.edu> Cc: Vincent Roca , tsvwg@ietf.org, The IESG , Emmanuel Baccelli , Belkacem TEIBI , =?utf-8?B?5paO6Jek44CA552m5aSr?= , m-mat@math.sci.hiroshima-u.ac.jp To: Benjamin Kaduk References: <154775953855.10322.13019924919889018658@ietfa.amsl.com> <4A1F8C46-9E3A-4F0C-B1CF-E2582100349F@inria.fr> <20190212003042.GN56447@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-10.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:49:29 -0000 --Apple-Mail=_EE6108FE-3B8E-480C-A116-F6854BA29955 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Benjamin, Thank you for your explanations. I have removed all parts that require = no action from us. >>> (More details on almost all of these in the COMMENT section.) >>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Comment (2018-10-10)=20 >>>=20 >>> For >>> instance, at session start, upon receiving new source ADUs, the >>> ew_size progressively increases until it reaches its maximum >>> value, ew_max_size. [...] >>>=20 >>> This seems to preclude the window shrinking due to ADUs aging out. = Under >>> the constant bitrate assumption this is justified, but a somewhat >>> artificial limitation. >>=20 >> [VR] Yes, I agree, but as explained above we give non normative hints = that >> could also be totally absent from the doc. >=20 > I don't really read this as non-normative, though. Even though it = starts > with "For instance," that could just mean that we are considering one > way to think about the behavior, but the rest of the text is written = as if > it is a statement of fact, unqualified to a specific example trace. I > think it would be better to say something like "For example, in the = common > case at session start, [=E2=80=A6]" [VR] Yes, I understand and agree. This sentence has been changed in = version -13 that I=E2=80=99ve just uploaded. >>> Section 8.4 >>>=20 >>> I found where RFC 6363 Section 9 claims that the following = subsections will >>> define a mandatory-to-implement security scheme, but not where = IPsec/ESP >>> was actually specified as such. Can you give me a pointer? >>=20 >> [VR] RFC 6363, section 9.5. "Baseline Secure FEC Framework = Operation", I quote, >> "describes a baseline mode of secure FEC Framework operation based on = the >> application of the IPsec protocol". >> It does not refer to IPsec/ESP explicitly, in this sentence, but this = is=20 >> largely mentionned before and after. The RFC 6363 "Security = Considearations" >> text could probably be improved (I'm also responsible of it). >>=20 >> The section 8.4 "clarifies" this in a sense but may go beyond what is = said >> in RFC 6363. Is that acceptable? >=20 > Thanks for the pointer. I guess, the Section 8.4 here is just = reiterating > the intent of RFC 6363, so this document is fine as-is. It might be = worth > filing an errata report against 6363 to clarify that the "baseline = mode" is > the mandatory-to-implement-but-not-mandatory-to-use functionality = indicated > by the Section 9 (of that document) introductory paragraph. [VR] I=E2=80=99ve done nothing for the moment but that=E2=80=99s = something that should be done independently. >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Eric Rescorla Discuss=20 >>> Discuss (2018-10-09)=20 >>>=20 >>> Rich version of this review at: >>> https://mozphab-ietf.devsvcdev.mozaws.net/D3423 >>>=20 >>>=20 >>> S 12.2. >>>> s->status[0] =3D s->status[1]; >>>> s->status[1] =3D s->status[2]; >>>> s->status[2] =3D x ^ (y << TINYMT32_SH1); >>>> s->status[3] =3D y; >>>> s->status[1] ^=3D -((int32_t)(y & 1)) & s->mat1; >>>> s->status[2] ^=3D -((int32_t)(y & 1)) & s->mat2; >>>=20 >>> You also can't assume that negative numbers have any particular >>> representation (e.g., twos complement) so this XOR is not >>> deterministic. >>=20 >> [VR] Here on the opposite this part of the core PRNG and we cannot = change >> nor remove anything.=20 >> We didn't notice determinism problems on our target test platforms, = and >> provide validation tables. If there's an issue in one particular = environment, >> it should be quickly identified and a work-around will have to be = found then. >> I'm sorry but here there's little we can do IMHO. >=20 > C99 is quite clear that both twos-complement, ones-complement, and > sign+magnitude are permitted representations for signed integers (see, > e.g., Section 6.2.6.2 paragraph 2 in n1256.pdf, the last public draft > version before the final spec, which is paywall'd). Alternately, = consult > n1570.pdf (same section/paragraph), the draft C11 spec with same = caveat. >=20 > Wikipedia (https://en.wikipedia.org/wiki/Ones%27_complement) has a = small > list of ones-complement architectures, including the PDP-1 and certain > UNIVAC series machines. Just because the authors of this document = have not > encountered any such machines, it does not mean they do not exist; it = still > seems needlessly restrictive to limit the applicability artificially = like > this. [VR] This is a very good feedback. Sorry for not understanding it = immediately. I don=E2=80=99t know if you followed, but the TinyMT32 PRNG = specification has been moved to a separate document: https://datatracker.ietf.org/doc/draft-roca-tsvwg-tinymt32/ = in order to fix copyright/licence issues, with the TinyMT32 inventors as = co-authors. In order to address your comment, we changed the source code as follows: NEW: s->status[0] =3D s->status[1]; s->status[1] =3D s->status[2]; s->status[2] =3D x ^ (y << TINYMT32_SH1); s->status[3] =3D y; /* * The if (y & 1) {...} block below replaces: * s->status[1] ^=3D -((int32_t)(y & 1)) & s->mat1; * s->status[2] ^=3D -((int32_t)(y & 1)) & s->mat2; * The adopted code is equivalent to the original code * but does not depend on the representation of negative * integers by 2's complements. It is therefore more * portable, but includes an if-branch which may slow * down the generation speed. */ if (y & 1) { s->status[1] ^=3D s->mat1; s->status[2] ^=3D s->mat2; } It is still backward compatible (same sequence of pseudo-random numbers) while removing the dependency on 2=E2=80=99s complement representation. It may slightly impact the PRNG speed, hence the comment, but nothing really serious. If ever an implementer falls back to the original non = portable version, and if it is erroneously used on a 1=E2=80=99s complement = environment, the validation criteria won=E2=80=99t succeed. We therefore believe the = situation is now safe. Thanks a lot for your valuable feedback. Cheers, Vincent, on behalf of all co-authors --Apple-Mail=_EE6108FE-3B8E-480C-A116-F6854BA29955 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Benjamin,

Thank you = for your explanations. I have removed all parts that require no action = from us.


(More details on almost all of these in the COMMENT = section.)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Comment (2018-10-10)

=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;For
     instance, at session = start, upon receiving new source ADUs, the
=      ew_size progressively increases until it = reaches its maximum
     value, = ew_max_size.  [...]

This seems to = preclude the window shrinking due to ADUs aging out.  Under
the constant bitrate assumption this is justified, but a = somewhat
artificial limitation.

[VR] Yes, I agree, but as = explained above we give non normative hints that
could = also be totally absent from the doc.

I don't really read this as non-normative, though.  Even = though it starts
with "For instance," that could just mean = that we are considering one
way to think about the = behavior, but the rest of the text is written as if
it is = a statement of fact, unqualified to a specific example trace.  I
think it would be better to say something like "For example, = in the common
case at session start, [=E2=80=A6]"

[VR] = Yes, I understand and agree. This sentence has been changed in version = -13
that I=E2=80=99ve just uploaded.


Section 8.4

I found where RFC 6363 Section 9 claims that = the following subsections will
define a = mandatory-to-implement security scheme, but not where IPsec/ESP
was actually specified as such.  Can you give me a = pointer?

[VR] RFC 6363, = section 9.5. "Baseline Secure FEC Framework Operation", I quote,
"describes a baseline mode of secure FEC Framework operation = based on the
application of the IPsec protocol".
It does not refer to IPsec/ESP explicitly, in this sentence, = but this is
largely mentionned before and after. The RFC = 6363 "Security Considearations"
text could probably be = improved (I'm also responsible of it).

The = section 8.4 "clarifies" this in a sense but may go beyond what is = said
in RFC 6363. Is that acceptable?

Thanks for the pointer.  I = guess, the Section 8.4 here is just reiterating
the intent = of RFC 6363, so this document is fine as-is.  It might be worth
filing an errata report against 6363 to clarify that the = "baseline mode" is
the = mandatory-to-implement-but-not-mandatory-to-use functionality = indicated
by the Section 9 (of that document) introductory = paragraph.

[VR] I=E2=80=99ve done nothing for the moment but = that=E2=80=99s something that should be = done
independently.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Eric Rescorla Discuss
Discuss (2018-10-09)

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3423


S 12.2.
=       s->status[0] =3D = s->status[1];
=       s->status[1] =3D = s->status[2];
=       s->status[2] =3D x ^ (y << = TINYMT32_SH1);
=       s->status[3] =3D y;
=       s->status[1] ^=3D -((int32_t)(y = & 1)) & s->mat1;
=       s->status[2] ^=3D -((int32_t)(y = & 1)) & s->mat2;

You = also can't assume that negative numbers have any particular
representation (e.g., twos complement) so this XOR is not
deterministic.

[VR] = Here on the opposite this part of the core PRNG and we cannot change
nor remove anything.
We didn't notice = determinism problems on our target test platforms, and
provide validation tables. If there's an issue in one = particular environment,
it should be quickly identified = and a work-around will have to be found then.
I'm sorry = but here there's little we can do IMHO.

C99 is quite clear that both twos-complement, = ones-complement, and
sign+magnitude are permitted = representations for signed integers (see,
e.g., Section = 6.2.6.2 paragraph 2 in n1256.pdf, the last public draft
version before the final spec, which is paywall'd). =  Alternately, consult
n1570.pdf (same = section/paragraph), the draft C11 spec with same caveat.
Wikipedia (https://en.wikipedia.org/wiki/Ones%27_complement) has a = small
list of ones-complement architectures, including the = PDP-1 and certain
UNIVAC series machines.  Just = because the authors of this document have not
encountered = any such machines, it does not mean they do not exist; it still
seems needlessly restrictive to limit the applicability = artificially like
this.

[VR] = This is a very good feedback. Sorry for not understanding it = immediately.
I don=E2=80=99t know if you followed, but the = TinyMT32 PRNG specification has been
moved to a separate = document:
in order to fix copyright/licence issues, with the TinyMT32 = inventors as co-authors.
In order to address your comment, we = changed the source code as follows:

NEW:
      =  s->status[0] =3D s->status[1];
    =    s->status[1] =3D s->status[2];
  =      s->status[2] =3D x ^ (y << = TINYMT32_SH1);
       s->status[3] =3D = y;
       /*
    =     * The if (y & 1) {...} block below = replaces:
        *     = s->status[1] ^=3D -((int32_t)(y & 1)) & = s->mat1;
        *     = s->status[2] ^=3D -((int32_t)(y & 1)) & = s->mat2;
        * The adopted code is = equivalent to the original code
        * = but does not depend on the representation of negative
  =       * integers by 2's complements. It is therefore = more
        * portable, but includes an = if-branch which may slow
        * down = the generation speed.
        = */
       if (y & 1) = {
            s->status[1] ^=3D= s->mat1;
            = s->status[2] ^=3D s->mat2;
        = }

It is still backward = compatible (same sequence of pseudo-random numbers)
while = removing the dependency on 2=E2=80=99s complement = representation.
It may slightly impact the PRNG speed, hence = the comment, but nothing
really serious. If ever an = implementer falls back to the original non portable
version, = and if it is erroneously used on a 1=E2=80=99s complement environment, = the
validation criteria won=E2=80=99t succeed. We therefore = believe the situation is now safe.

Thanks a lot for your valuable = feedback.
Cheers,

  = Vincent, on behalf of all co-authors

= --Apple-Mail=_EE6108FE-3B8E-480C-A116-F6854BA29955-- From nobody Tue Mar 5 20:41:32 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2965130EB8 for ; Tue, 5 Mar 2019 20:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_02=0.437, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXikXIBzm1Ew for ; Tue, 5 Mar 2019 20:41:28 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 03F8C12D4EF for ; Tue, 5 Mar 2019 20:41:28 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 010A86066C7333E22675 for ; Wed, 6 Mar 2019 04:41:26 +0000 (GMT) Received: from DGGEMI401-HUB.china.huawei.com (10.3.17.134) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 6 Mar 2019 04:41:25 +0000 Received: from DGGEMI526-MBS.china.huawei.com ([169.254.7.246]) by dggemi401-hub.china.huawei.com ([10.3.17.134]) with mapi id 14.03.0415.000; Wed, 6 Mar 2019 12:41:13 +0800 From: Shweta r To: "tsvwg@ietf.org" CC: Santosh Ukkali , Sharath Chandra B Thread-Topic: Query regarding COPS RFC-2748 & RFC- 4261 Thread-Index: AdTNGdiEdcplVKKOStK3lkn/aqgFFgGvOEPg Date: Wed, 6 Mar 2019 04:41:13 +0000 Message-ID: <421CE35A2FDF994790546C7F50F875455E9E3E19@dggemi526-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.208.102] Content-Type: multipart/related; boundary="_006_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [tsvwg] Query regarding COPS RFC-2748 & RFC- 4261 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 04:41:31 -0000 --_006_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_ Content-Type: multipart/alternative; boundary="_000_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_" --_000_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Group, Greetings. I have a doubt regarding COPS RFC-2748 : 1) RFC-2748 mentions the use of minimum of HMAC-MD5-96, so it means di= fferent algorithms can be used with different C-Types ? If so is there any standard for this ? [cid:image001.png@01D4CD42.21CD1110] [cid:image002.png@01D4CD47.5EE14260] If we want to use HMAC-SHA1 in our COPS implementation, what should be the = C-type, how peer will get to know about the algortithm used ? I have a doubt regarding RFC- 4261: 1) In 4261, if rfc-4261 is implemented does it mean that no need to use r= fc 2478 (HMAC-Md5-96) object for message integrity ? 2) rfc-4261 is implemented, the integrated object is required, then Client-= Open and Client-Accept will have 2 integrity objects , C-Type =3D 1, HMAC digest & Client-Type 0 4.1. The TLS Message Integrity Object (Integrity-TLS)= ? [cid:image003.png@01D4CD47.5EE14260] ________________________________ Regards, Shweta K R Tester - VPP, 2012 LAB Huawei Technologies India Pvt. Ltd. Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield Bengaluru, Karnataka - 560066 Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email: shwetakr@huawei= .com --_000_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi Group,

 

Greetings.

 

I have a doubt regarding COPS RFC-2748 :

 

1)      RFC-2748 mentions the use of minimum of HMAC-MD5-96, so it means different algorithms can be used with diffe= rent C-Types ?

If so is there any standard for this ?

 

 

 

If we want to use HMAC-SHA1 in our COPS imple= mentation, what should be the C-type, how peer will get to know about the a= lgortithm used ?

 

 

I have a doubt regarding RFC- 4261:

 

1)  In 426= 1, if rfc-4261 is implemented does it mean that  no need to use rfc 24= 78 (HMAC-Md5-96) object for message integrity ?

 

2) rfc-4261 is = implemented, the integrated object is required, then Client-Open and Client= -Accept will have  2 integrity objects ,

     C-Type =3D 1, HMA=
C digest 
    & Client-Type 0  4.1.  The TLS Message Integrity Object (Integrity-T=
LS)  ?

 

 

 

 



Regards,

Shweta K R<= /span>

Tester – VPP, 20= 12 LAB

 

Huawei Technologies In= dia Pvt. Ltd.

Survey No. 37, Next to= EPIP Area, Kundalahalli, Whitefield

Bengaluru, Karnataka -= 560066

Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email: shwetakr@huawei.com

 

--_000_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_-- --_006_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=21189; creation-date="Wed, 06 Mar 2019 04:41:12 GMT"; modification-date="Wed, 06 Mar 2019 04:41:12 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAo8AAAEWCAIAAACIc+o6AAAAAXNSR0IArs4c6QAAUn9JREFUeF7t nQua4riShd2zHMjlXLKWAyyncS8nye3UhB62ZTtCUgjJGDh8PXOrQA6FToRetkt/1+EDBaAAFIAC UAAK7FuBf8i9v3//7ttJeAcFoAAUgAJQ4HMV+Oeff/7vc1uPlkMBKAAFoAAUeBEFMFu/SKDgJhSA AlAACnywApitPzj4aDoUgAJQAAq8iAKYrV8kUHATCkABKAAFPlgBzNYfHHw0HQpAASgABV5EAczW LxIouAkFoAAUgAIfrABm6w8OPpoOBaAAFIACL6IAZusXCRTchAJQAApAgQ9WID1bf//T/fOdpdD1 q/uHCv/TfV0T5e9XX/Kfr667d1/2KvPnSh/j8z/d9T6Y63Pt999p5yv5CDNQAApAASgABXIVSMzW NAF3l+6YYY3muf5Ex6KZ/w6X7ruPXXM8dz+X7nTr/v50ZP186jq6lv5c6XP7MT5fhkVD33fHY0df Jj/k0s85WcoXIHGircy1g3JQAApAASgABeIKxGZrNwHf/pelYTjPnS9Zl7hCNOfR1v3vbbhk3GqH u+3hS7dd9lvz+F781F1+7Wx672jWpvWA/7h99uoewLjdD28MuC+/v6dL/PRs/bncO7eJN2XGeZvz X7RDPnH+xMrTFaM/X0Y9fwuB1U0RBxSFAlAACkCB/SogztY0YdAkmr/RDJt47bvbND3GGk+zndmR j1M1Td5/utOP36P/nIbb48fu59YdL93ZbvNpa37J2Cufz9312vXX7jB35mZvANB/p36aZckmfUM7 /vDj7gHQ1txdQn8mg9aD7uev9WEwNbaX9V+0Y42t/YmUp6naLG6cP7QiGe7287rtN/HgGRSAAlAA CigUEGfrX5oGhse99z77aa7d4XV5N5Np4uluZsqctrP3rr93l/H5N82d9I1rzsmU9H+mP9Bfk808 2Xvyv/Olw6G7DhvicaqLW6LbBq6u4yFVZcR/agFrR/aHLd//Tosbt8IwK5hovSmn8TsUgAJQAArs XQFxtjYPld3GkZ4Bn7I22eb+7ZfZGWdurKkKKnn+CabhY3c4DvWOO+BBQ7dXpg/9f/pzzudGVcwf V39bD/3elFYDdT9R/9mq6vijr7duu2ENCkABKAAFmiqQfiecn2Ps9jR8x8q8Td0PWz2lyzT10rNh 9zkd5H28215nbqy9ufkW/N790ktt7q25e/fn4dna3IGgj70J4dSI+b+WRe/Pwj49SnCPzHX1KgOE 4lAACkABKPB8BYhvLX1uJ0Jfm/+Ol1kRetZs3gwbv/v5S1tiV9L9d5p+Y2z/XIaSR/+rMTj8+XKc mZpZome8Yb2s34Ezl5+/f4O/kqmpanLSts656loU/hcWNmVs1TMphm8WLq39Hytd22H9iZQnV0P7 oc4x3SIxxk9QAApAASiwbwVooUAPmWlDTJPQi3zoIfdv1m35F2kP3IQCUAAKQAEokFDgn3/+KbwT vr20/p8tfXf31D/m3t431AgFoAAUgAJQoKkCr7a3bioGjEMBKAAFoAAU2J8Cr7S33p968AgKQAEo AAWgwEYKvMyd8I30QDVQAApAASgABfanAGbr/cUEHkEBKAAFoAAUmCuA2RoZAQWgABSAAlBg7wpg tt57hOAfFIACUAAKQAHM1sgBKAAFoAAUgAJ7VwCz9d4jBP+gABSAAlAACmC2Rg5AASgABaAAFNi7 Apit9x4h+AcFoAAUgAJQALM1cgAKQAEoAAWgwN4VwGy99wjBPygABaAAFIACmK2RA1AACkABKAAF 9q4AZuu9Rwj+QQEoAAWgABTAbI0cgAJQAApAASiwdwUwW+89QvAPCkABKAAFoABma+QAFIACUAAK QIG9K4DZeu8Rgn9QAApAASgABTBbIwegABSAAlAACuxdAczWe48Q/IMCUAAKQAEogNkaOQAFoAAU gAJQYO8KYLbee4TgHxSAAlAACkCBtrP1/fr1j/t8XbvxL/TnZ3/6b/Lo/mwvtqv/Vdob9ZN+tIlU 7+NS8ruvZ/FFLFkp/aeg+UndquZb/bjvLUq+hY0HpCnoNPZdv8a4h9+Pyowj9zB+T85NP31/f1ft j3uLyx79+dvy83M5nm6+gtup68a/tKy0ru2gBXUNv7m1BrrdTsdLsWqsP2F+Flt+sQupzRoZd6Db Q3FvHZ0qeW5C8qPzVFVvOPZS/GkeciPx8vspMeiXabAe3bO54x0112oSSdc8lJ4r4JcOTWUZR0OT IeFU7VLGfcaQ+y99Pox/4z10Px+PlDPGtMmdMQldGo7mp34wVht2Dp++p/GSwdHQyZn1v385/0U7 vlss/YmVD1twvEx9hNVNDiHbXld8CsCRPulZMAiY12fZ7U0krdQR3YR6RT8DUybGy1SZ54+kg+yP yU9S10cmSFClzhE9p0wM4xjqMHQMl9CXy5iHQZI+4k/Q8YJukSGdXrdq+SbFndPNhX2tM5+f8XFD 1a+jea4aV00Hv415OOtG07Sa17+YeqU16WrdFkzRs9l6NBDO1qoGovCDCmw2W7tF2GzpGK4lTc6P o7AZkKeSifWj7S0mm4cl4pSWt9uwpTfT0mJLv8650ZKba5I+SP6LdgR/pPKrtbD3SNQtmgtse1Vr ZBuiIS7k3BCv2TiQEbvQk/XafOWnrSlYyo/1Fugg7RHDMXCsTGtfapccR17PYNvjFj0+c7X+SPHy a6mMxdmYUCrd3FUP51sk7rxuks58fsrjhrpfm9VDhRuGfqHmUj2Iu7Z/8cPAvGOOZZipdyrJ763n q9L0Ev/BKQqXjwrQbN32ubVbDvTf393t76n/mh4V36/9/X4ZH2pf7t397p8enm6n/ur/3H/3p/O0 R2YfI9CS1G+qp62xKXj4vQ5P5sh8zmfcnh8Ph0T5iP/BNn9mR/aHq7fvfy/jZuF4pk78c6aFSbTe nDZO9xvO58MQAFL59nOOXU71HqjItAW9Hfqy5/5HVb1Ghn+HasnJYfNRTwd7N8a3bIqX3r7QLjmO sp5jPnTH87+X3546g9afevGKZAWjm1y6Wtx53QSdI96z40ZBv1b1umjhUc8p7vWMF1manmj3p7Eb dmY0couKU1/3PZIiJz/ooi1ma1p50oRKMZ6mYRoXl6v76T7W+dxd7VRwvXbncYbQBaX//upPY1YF 93B1ZqTSUf+5iyr5o643OtiOy7Zbt+HbIsFGpLjemjpwEpXYr9Eu48vxuF4rlvhTJ9PrWamlTz2P 1paeqTMX91ptPRy7/j+muf87Lb7v+56G5qHkFLJppR5YoRXYadxl1XIVdmQFtpitx9ppGv72byKe TrSzk3Znbnuds7GWGnb//T2e/ER/v/7J3FyLMv3+ut25WWu6BkT9X9tR+7OwP1asrFcO/DW402FK xW8nHM+nX7eCch/aygzydp1XJ3zN1Bdb69bp6jXNHW60UK3XMZBlOjD+CAqp7QvtEuIY0/N++TO9 9/5ff7C3jJT+ROOlHw/zdRNt14m72C6pvxh/5Pxce6vUWc7zYbjI/ycHQdzNkOXiHvc/Oy7uzsbU gYfxxH4//qMI04N/h1uVfCTnL/vTsHaa39HU5xau0CnQ7tnA9BKG30nbDfSwq57veOfPfnJeHx+t u827ffw4vlcSvP9xPJ3GdyCXL9m4p96hpen+c/iY1is6c3Ltf8QO60+83tB+WHFMt2Us+fbOHj6Z pmU8eAsaMLsgjLF9PWr2eHulm+C86Gf4tiDNWbn5w+b0VMnsLTnfnOHX4NF12I8SEkWCwsdR0JOe m7p0dZ/5+xMKfxYv+o3eL28zZUQ+CEFSt3r5FloK4y7l4eztsyCh1/k56suNG2zXKBsfhjEpPb66 kkHc2bcL/euH8f4VqUwaT8K384KXFdgcXMRX/R57WguUEBSgePxD/0e/6qb3DUrTnePfM3v7ZYPK UQUUeJYCtAft/kXiP0v+mvXSv0ump3GIZU1NP9iWeQtrb7M13WoZ/9n+sPb94BCh6Z+kAI3v/l4/ 3X+Kv/f3SbK8ZFvptvLX/Ty7NfSS7YDTO1Fgj7P1TqSBG1AACkABKAAFdqIAzdabvmW2k2bDDSgA BaAAFIACr6UAZuvXihe8hQJQAApAgU9UALP1J0YdbYYCUAAKQIHXUgCz9WvFC95CASgABaDAJyqA 2foTo442QwEoAAWgwGspsNFs/TjvNqBj5536vcs4PK6DplnumN/FEUbmi/H8X/ptxiC31tf82qnM hEXeiA/+HnHXRM2UfTPOd5LfvG5vPO7b9iNt9J5ZXtLtM/vRMyPRqO4XOj2Ggca0917L2NGWb9iC 8Wg3WwfxdeikLIcmm1N5JhIly5Iavxy5PAU43uCYpJwDtGaqNI37juKVmwoP8Z6fwqsuSxhV3GvF sZad3GA2KCfpptKzgV8wWa4Azf7N99bMms599fVld37fdB643bCZM1HcD9er+2a+L5SWKuG+78se sCzbn34dzDur7orv77He4YAW+8PlPrFoxpNb7JnhKy/l8pG17bSXHQ6GEf1Z7H2/6DOdKc0rdLo5 jBM1kiApCaDZ3IQ9lNWwuQgCtjiSafXFqnKlPuqV6DruzgRbr6RbJL6cQ5H8dEEM7lVMmbKOb3hv Y3LYhlLMk6C9k+nwAlt9QsZ4e39HT4MaJJ2lmmT9u8l+SOPzJL7MezW8PlK7fGlve/ybqFJUn3Uc eTvx8YfTR+rv/ntLJljeKIvonN+XtPrkW0bJRgqUT/fZVy7XdDG+LLVy2HsFnFdX1XptyPNoN+DX yvzsyNqc81/kRo86hFexe18xDlTaHghH5/m6bfHom7S3np2TvKIgz5i38egX6SOZzI27uWnAc80j uqn2UhJ/2t2vMD3UiXY7uSSOcMFnBz7Pbzes2vsynG9Jf4nfLPXrgu/5OGYw1xdZx9qJ8cLXWSuP P5H8lPr7lBphW+T+xY6Top56fbJHfRSsqQANLc331uIKQ+JSB3zoNOc1wqNtza/V87MZKaIcYpa3 reMEuyotWChF15m8q8OvraKPlD2RuAv1lugm1M7wp4eSZgJ2J4a6QnJ8rT8eL3a9/l7idz1eh/Md 4co/h9/sgH4uQMVYvwJeuDS+6Tj38gatVv+qok+jfSTMzhV43mwtT+MM31cqrOXRasuLTlbiVZek YwEnmKaO2y1y7jSR7zhPHuDXNtZHjGOk3gLd2PDU4hCfzu4RRf99OZRi3Kvls5CIavsR/Wvppu4z BOp1tFfzKMhjdNVGKl1Qq1/UsmOatSd9Ksn8pmZ2OFuzfF9Jfi2PVlve1bviyCZ41QrubIQbzbZZ xwkeTawwtIScH8nR9//6u+dbV+LX1tJH7HVCHOV6o7plx8v4o8nPKGeaFkM0gaQ31lTnq3C+Y3EX +c31hlYhjm77qNhYr+zU4oWrOffB6EPPmMfXCYrsyJ1Jq0+9iMGSVoGaN9eXtjjebUiLXXGpBb6v zD+ec23NLcio/dlzWaNUId+a5VX71q84ysMjzTAy4bP56Xv3bYSnq4Bbh2Tfn8Do8FoAx7UV+bUy VphPH6U+Ug5q4j682TCoGXLNzfPj4LOGqbsf0y+rZ+bnZCgq3OrFjJfnfLNxl/nNUnu139vYM/1u yCvzUzq4cv8Nu08qUaLjD6tPpL8HnPIZ31roX0W6eemy9Wk5YcC2pACl3e6ImeD7ahdbKL+lAsjP LdWuVhfdOf49AzUt6gl9qqVaK0O7I2aC79sq1LBbQwHkZw0VN7VBj3bG+8f2n0dsWvv+K4M++4+R 83B3s/WrCAc/oQAUgAJQAApspgD41ptJjYqgABSAAlAACpQrsMN3wssbgyuhABSAAlAACrylApit 3zKsaBQUgAJQAAq8lQKYrd8qnGgMFIACUAAKvKUCmK3fMqxoFBSAAlAACryVAi82WwfgmekfZlBA 9sO79ZimV2Jwe/pwQV6HjCDV5fuJl8rtHRZuzS1+Ci855H6FoLvifFsH7qP66T7ytnyc2Yf/z/fi pWZrYj7+WsDR4uQie0zRTo4+ICTG/Nis58c45UHuP0MNTj70Jg1Js6i1+4lXShzF72t9FBeXFqUQ hIfflZoRr5PsN6+X+Cj2dLIRZUYuFufbunkf1U+rZ0WRwdxxpsj4R1y0xWw9bYgJXU1A5mHfqeI6 GyNfl/v9MjKlXXzkvUUAEbbA7JE97E5LWPBiRT6xlu87pM2SR8zaifJlJ31yONYabu5MOIcWj3/q cZGleEX40OLGiOWgC9xf0f66fJxPLMeR56AL+ZPFw86Juxw4icfM98c98ZITPPUqHO56/XQdgRiX muAinuhNQ1LAp5fGGYlrzsa9Cp/be0iDtRk27Wc5aGdy3KVxJq4Pn5+l43BqaHu135sezRoe0Gv3 YZ7qG+H+spxXf3z2irgscVvJvj/3NqzVHvfL82LHc4aXfOIJQ2wsCQ6EGjrk9oi4dT/xHG5b6VSB KTZ5PX5vNEzWK3OdOT1FXnIkGVjub6huSGUW2zuc5h22ena3ZK6/5I/ImY5wfzn+NM8b1vPRbYiZ k5ZjOnD+6Pjlgzr53HSpP0rcZal/id9X5SWveepl+cZmUZV+KuWnNM5I8RXypFo/1fG5PXwhZBmE CLt8jrvov6SPPF+ox+Gm89r2xv2yomXFpu8y9mexMr+PfTw2m9pMZ71djlbzkuGv8dl6OYUw93nT Z9/7e8Ohq1E70yg/G+nCQxLTlQan/5uwjhfw7Z0Pqeba5GpAmI14+ynd1rPLLAkyMnJajQ3Tf7g4 GxfMM+EWrR4nnGB5Ha6VnEtOSt/MzDiO/sd1YP2ZHY6ZEXd29SP2L6E/uhaudZBXA5FZXMjnjKCu irCzNbPaTuWbMFvbBj/aT/l2yeMM168l/2v1U3m8jayGw+SLDZtT95iMecdl/wWD8nyx3APndo2S tNvlNSTAFnfCn36vgSi9hT6o+b6+HgOovN+nG8xROwJfVsVjrsm7LdQqvKxUN03VLC9Zq4OyvLZd 2vKzhRatFbrvr6tGk+KySh2i9TyBl1yis9W6Qj/Vas7161L/tXVryj+NR844uUd9NFpWKtt6tl5w iM0jCfOUtBYvVlKB7Hf99ID8Onsw6+m1IS9WVLOMh308ngkg0IVAgdPhMj38WVTH8Xd1HGst71bk JcfTKp8DXaabKqk5zrRWB215C5oW47jmoCfKM+3VxT2S/7/XMf/pJY3+93Q2e2ehP6p1iEZK5Em7 J5Lp1yRUeWALl+VbhX4acZUdZ4T4Cv7X6qcl420NjnvUf04fIT8L46vPo/1f0XrfH95ii3N/xxtC pthwx8jdnV6+euwNyTzg4ObSkT7WiPlM34e82KWd8D6LAint/TS1jRbHqlOI5dm9HVWl8xuZE9c5 ouf8hittMXIejY8Ao+Vd53W8ViFzl+Tyd5P3uQTOdHhDN+Rbi/EN0+R0shPaZdB+eImVIuiKhe8n D/169TxvsT9e89c5HUYryrhn5f/ouesBbH9kdDABy43Xkh7N86SdtWRs5900uCSWz7zO4thmRajQ T8UK+HEmxlnnQz+7cV7YT0VB5aG/Gsdd8l/QR8pPYTxpPXftyD7l6+741i0WN7SL/tP9u5N/4sU3 EHxZZeDBmVYKtm3xd83nd23XKjvQv7btMOna6K6UKbSj9UNVV6a1asYrVFVrVhhTvkumsPzGRV8i sm+sf6Rp75rP79ouNpToXzvsvJ+yt06vW1ACCkABKAAFoMBeFQDfeq+RgV9QAApAASgABQIFWr8T DrGhABSAAlAACkCBRxXAbP2ogrgeCkABKAAFoEBrBTBbt1YY9qEAFIACUAAKPKoAZutHFcT1UAAK QAEoAAVaK/Cc2boipzYkXrc6KEkfhI35zZ4cG4FqG8VbnCHlpAG5NkwRRo2N8yGZsLX8idppmBVS veFoEKZ7UXvT/qf7XTIS0QK1xsmJX0UH2QYUvMe8m13Nj8NLUHm7IahiU/ZtqvW/LZPYTVlnGuU5 x1MihGtZf/LqeahU03pDhs9DXsaONxIj5uBqjep9QbMyPKNBY5rm1WP+PqSDul15cBpNi9L+V+x3 TcfJkKLBHzSn0UUqy4zDIZilXcU1nN+5DVpENN5b1+MiqxY8fk36PfJZhzVdxB+Rn8pwsskZiU/M 85uleqN8a6nJEre4m7i/LEQ8oNSSaZkXy/Bl43F0jq7QKbl87gKetK1Qss9/L/Kb+fhG9OHjInCI JZ73AFi38OCBv24sy3Fh2pUTl7m7sj+inmx7RTsSj5lrV0E/leo1Ufy63O+Xkcjs3M7xkyIwtVHy PzIArfudtl9vOE6am2wdUQyGU4TZfNP6nzk6n24/l9n59ZnXodikQOs1RUUucv6azh5DG/IPh3PC lRxiiZNtPGF5ydZFdq/P7xWUPGCJUzuee+yrX5/GvKyI58WK/GNBNxeREGPrvgkVMDbjO+8xWkP1 41ZA4kNL9sV6Be61FN84n3uVhwkO8ToftPVG9FTvQbn81MVraP+qXaIOkTiq+uk6u6ZYyHtrTn82 /xNxXI8/Yr9T9muy3HSctB3KdcRpJLSVCtxovf/8uLeAnq4ZqK2nn3ex7yfs1s1J3+EJ6dbLdVTW /fJ1b4wAWRl/AqbBUP+ANQ6mmWUtPJ9YOVuHvVQ26GM0a5WbJn1nE3nPY3RD41J7rT0pH5Szguas xnGcHTqzb6jo57hWcuEKk0Sod25qybFerDBi9XLypDjEy8yZzyvTryXt5Uf5eKfmVpOaeEmztaSD 3C5dPxVXCVP82IYz+rPjTCqO7GwtcaC1nO+m46SLALk6W+5H81zrP2brpjMpha/xnXDtLYxncUzz 6i3nZEd1qMQD1vBo89qrjd68vIrPLVQV81Oyz36fxW+e4ruFPlOT8+qtoWcsoi3tb6tnOm9r+iP2 u0r9mmtNkf8OKXf++XvqB4Rw1E4L/w2a9XhIBwglOAW2ma13xUUmGdb+CHzZKCdbn1GCDiIPeFVD jFMb8Gjv1z+Xg6XrSR+JByzxZZ2d/DjSQ9A5Bnr1VDtPPZFbLNnnv5f4zWJ8lbxkLYdYX29UT0Vc JNnrxEvUQamn97JCu4T2VuRJy/0uv1+r21ump6+GpuFv/yZP1I7a/2Sf7q+Xw9mC1vEpVKDp/t3d rh08K+Yiiz6y4OLxBg/LXV7746zzfNngZlHAyZZ4yTJvmNNhalX+25LcHV1bq8c5W6kXD6dsPavb 7BJKmeeRx/1fxUfBaQ6j5VqSwZPOcT68Qx6G0XOsLXB7BsQOOehKXrLAC5fzgc8rMQ9TcHTXw5KP jUR/FPGad+lF145w09dV6Ptppv+jErH++DhPOt3v8vt1y3FyyjX/nMt3s9i4537L9p8fEFd32pMJ 2nwyetkKqKN9BN+6cBWzuozelGzFyW7PzW3ofC19n23nWRI9q95n6/0B9bfv121FfHX/26qzqfU3 51vXWkU1pb2WvNujaFhgHv8eWtCtaXwjsXpWvYr0QdFSBRr361K3sq97df+zG/oyBbG33nRxhMqg ABSAAlAAChQoAL51gWi4BApAASgABaDA1gps80741q1CfVAACkABKAAF3kkBzNbvFE20BQpAASgA Bd5TAczW7xlXtAoKQAEoAAXeSQHM1u8UTbQFCkABKAAF3lOBjWbrx7mzEXbQEJk0j1aK4RLDajg+ 5iguzwjq9x77yX/wa3cZqyK+cuuWlPeXYs9ehYdd3MCNL5TG1Y3dQHXbKdD8X5zNGQaPVMfRCEJ7 aR4tW/todiTEjGiaFUfjEfcbXhv6mX0AkdofRv8QqtOuYrWniguUtBKF5d0XzeovG+qT5Y+kqtrP euPScwL96v4/R7VXrZUWBM331tW4sxn74oFirV7oHM8/P/PTa2dfTPxaX0O453bL2/BQ7Fyuc9xN kcecaN2e+bVWGY9zthziQDahvRJHvFuXL+BkR7jCAmda9EcISxWedEm+SZxsFb85yl0WOeucFDmc 6Vn/fQoPu4jrvNZB5HaTMlJc5G7N6iyNq+qxDxe8lgLNFxvyGnC9V4tzhVflaTc3nok9O/y2rFFr +qo96dZXEdYukf7CMsah4hPEBB6z1C7rj6tw1/zaAdxn22HEHU4OjrTXnavklLyd/AVseRut4XB4 879jmCJ5xe7JYnnI+hNNuHWea/NEm2+C/yX9RdAnyDRrNafH5fffp/GwlVxniTc/ZqJL87FXKrnp c8DlQmfsrXNy7l3KbLG31i1c7tf+fr+YHZjdeV3o0fE99tS4738v/w674tNtdYi8rnahNNl1VeQQ M4/n82FowHdvLi304fB79TL8QzLkfPrv7+5GOLyAfhXR0wF2nN2ePD3HkF051WeXcasKK+j538tv 75yIttcMdk7J8WKp/PHirZ8CCJk2r1LlGX+ymz80vU6e8Pkm+V+rv5D9w9ArXFAOPb3nof5I/kT1 H1Mgpz+qXVL1i6gOjJ+pvFp6W0tntQq4YI8KNL8Trmt0EbdVV0Xz0lU4wVk85kVTXoRfy/Jtte1V ltfmlbZ8SVJVyRM7VY67h1v3Ta8ZmmXQ4bDc7K5pVCVOb3TNU/1vwXX2uj21XRvFDtU0U2Bns3Wn 5LYmuMLu2Wbx4+yE6p6+Sw+ighpinOB8dyQec14e7JtfG/CAu+6/3nK4te3Vlk/kVTbvPE//nFIF PGlNvlXkN1NrVvrEOOs5rR/K7JOHnc91VuugHN/U9jXio+wrKtD0xv4cIlvMnZU5tTNYjL35Oe0q 3G9ZTNX5TfQMDnfIjL14KjMpGeEE++fqs8fKovaBPx5cHWnGC/Fr6bmdw0u7z/g8T2gvj831j7wH G55XfRm0dzcZ8jjZ7ln4OHtM+1Q+lKI/QiDFvFXypEMO9/GSl2+P85t9o1h92A4jpnNJ/30GD3to QP6/buB0GL8bXqGYpbou9ILOwrjadCyH8WcqQDkEvvV26yt6t7M/LV8+3656tqbN+bW0p+z+XbyA /2QNUD0UWCqweb9ACKBAXAFzm5hK0IIBSjVXgG6Yf93PwT6ueY3RCuiu/Hj/ftiLNveI1iv+jTm6 /1H8/l1zN1HB5yrwlH7xuXKj5dkKYLbOlgoFoQAUgAJQAAo8SQHwrZ8kPKqFAlAACkABKKBRYG/v hGt8R1koAAWgABSAAp+hAGbrz4gzWgkFoAAUgAKvrABm61eOHnyHAlAACkCBz1AAs/VnxBmthAJQ AApAgVdW4ENn63zesMQOyuBtN8mLsnofb2/dxuT7I9VbpkPdVrSw5jFlBWduN/BmW757mrftSzQT p2J7A3DWBJsL+VsDC8GeFNt1bPkGISWTaZ1Ff5YNmA5xrOT/jKzXpvkvbvWZB7Rwdas5tUIDatlZ UHTC2hje8yZqsvVu0N5NGqeopLUOClfqFQ0xTfWsFlqasb8KbeRfluZbVxSH7S/12jvj+Y1uzzJ2 BtHiy+drpymZ1tme8DcdnzjJLvLs6/lvZZmz0DSNe9OytMpou7eO8Yxny8lhjabkDYscWdmOuCcr 5UnPlmoqPq7MY47zjJnFobK98bjwi89HuLxf9PF7CEb/TXRgeNgDa/j72x4nvzhSXm6vyDO2MLFa vPMlh5r1J5pvWs66WH7Fd5/auaSU+z0iccsHf2dde7GhNHaW7czY+kz+DHx0Vb8bKr3cpz4/Ywmw 7dXnf9iS/53oLPzwCzos7UoMOjrakG3wqvyqFDdeZXK1C8AJvD+Gevh75eBraf/lON8JHnA+04nq /X/N7qJkZNlOizRdi0g8Y4kLa4/aZo7Ebs67jfKkpT00872KjyvzmCWesQuWdk+5Li9ypgX7Wi5v nN+89GcDHYT4ajnEEZ7xlLVBDsR1YLuekzp0zHaKCVxufhoPwxfyTVuvVN66wfDd/yp55LV42zZv BymMcyMf/RSS3XPuM0l7a7a92vyX9qarI/3HFFDuTXX5XMA1z9hbk+9TKaX/8qwzxCXnBkDTuWtf xpvvrd3yhOEZa7mtG/Bu9TxpfvGl4uPakYfhMW+yruM502zVWi6vQVcr+c2tdZDjq+AQa/O2QAe7 3yRC+ld/mngjek65Vv9IeZ7vruKRV+Vtj/7M+Ojafid3Maa9+vy35qf9b3/69zywbOyqggWY8uV5 T1X5XMg11/gjt1c3mPXfF4vlo3njdLgU3AbQVfdSpdveCbdSsDxjpUjNubBKXnLU/YZ8XKVs0eKa uJToX4vfXKXNyviWtFfys0SHE41X97u9s+76UIxXLeSbtl5V+SfqKeZtw35XmA+TpCuOjVkSrDIm Un5RVql/YR9K+2PQtcfDYD5dPulI3/fjIoemavNXfAYFNpitOZ5xgttaize8tiNEXs1LjmZQPh83 aoblGedcYdM9uSrl4iJaV3J5zUsJwzNFZ/Mwdml156uggzq+QnujeavhT8dFOB7PBP3sQvAK7TPm ggYWuHzT6q8rX0vPBJ+eVSnI2/v1z7ARM0XV/S57fEjw0dUpPV5w/Ur2U864Vv8SnXMa1V8v9Ih5 AuAK17g9ek5LzU2A8Ab05RfT9VzUprfnJZ6xey43fmZPqrN5w3GOLMctFjm7gTshT1oqL/N6nZo5 fNzQ+zWPOXzANfGMo/UyukX4yixnOmZfxeUVCnP2t9AhTLcpvvH84Zsg5S0frxjvXHhoTX3C3Csd lRofx8b0X+WbKlj2uXg4KKT57pn9JezXj/O2XS8J+Ojho+rsfhc+KfaNTrdXkkgaPIPGzl84WE5o vmq2fGRkZvWP5XPY88ytG5NlEfu8P/PktwskbyPqv6ubeRtp5kDYg+hZAdMDms5UezdOCjYnZn4o z3j3fNwPjUvOhuEVy+w+3zYSFTpsJDSq2VqB5sTMD+QZvwQf9wPjsnXf2qq+l8i3DcSADhuIjCqe qEDz2fqJbUPVUAAKQAEoAAXeQwHwrd8jjmgFFIACUAAKvLkCG7wT/uYKonlQAApAASgABVorgNm6 tcKwDwWgABSAAlDgUQUwWz+qIK6HAlAACkABKNBaAczWrRWGfSgABaAAFIACjyrQdraeuDUEnAno S496HVwfoGgCipLMYY1X/Th3Wdu0upzm7f3Xtnef5R/XrW4c1yrV4iXX7S+NotmaMx2CvxbstUqc 5kbCwOzHK9D0EJeQJZVzwFeZMywLazo8p13FZe6urmKZWvIxSalTgSp5tTCTwzVqU3Mdqxv4r4qj slU1ecm76i9P4UzP8M2z8aEaS0oZX549qDWC8u+qAK1T2u6tw4UQLVq/Ozr92B5CRx89r7d8WSVz WEebkb2RihPsCiv4vlKrWN62kmM92jBHTAd/EfWXnIlwx1lOeSRUGo54jMMt2OH1V+rm3J9q+Lq6 Y7TV3PGZFZMVozBinuRleX1eclhvRn+h4iLnm+WFs+2K5lW3BWfauvUYp3mtwygOMw7odWDti2mi 6V95uYZSe1Fgm9naZFB/Cs4+pq7+x3zhPj+nnkYyIwnh2Q3V1NPl6G9m3S0A21USEkTnPsfBLy6n uown87OM3aJidPRGNlK1GjO3EyEPLfGQ/kwYGXMN396YtWkDfeqHs/+tl+FeZDpNmvOfTLhdlEEA 0V/ctsHqqfNHrpeGkimQBKJwcdS2SyhPbboc75cLrfKGRJkoCJw+Xcfrr9TNTbJmcTlUe7GBJzPs UcwF7ZXyJKWe//2/nrhc/s+Gr5lCJoTlc6pI9hc27k4fSngn3M/l9xosUJh65biYEFx8ZoV2dHm7 qlLSQWpvUjcp/3XxfVL/yskElNmPAlvM1v23Gfdoypn2Fnpe77Mk03KCnZ/mIH+3yHDw5AI+biXe tvX/6rBz1+vv5WzvbRT4wwZAz3vu9O3iOdwqvrI6eywLaFgK2bF0xTzMtFnTz5a85MzmuGLRuDO8 cJXxoXBrzrTsVDbXOZX/y3FAq0PKPmNP37+0TqH8sxTYYrZ2mzoa8U69nzaKeL0PSTTnsKpMqbi/ gmU1H7civ/Z0dtg5g3kf6HZqf1SKRQoXtIvlGRfYqdUElZ26frbjJS8b9UB/UemjLFyYt2nucnVO s7JhtYrXzbdaXsFOHQW2mK1HTwkX/+0hp1FesppTm9Qik8PK2NFxf0VHlHzoBL82n8trHKLtNW2r p421+U7pj2/Xqt4Ep3wlh5bLawxwHO4SO2QqX7eFPjNguIK3XehnMp/FAoW85KW9VH/Rxj3RoOK4 lAs1vzLVXqme1jpo7W+eb7UCADu5CrR7iS4kltpaPMbZ1aji9UpOLoHJbhktc1gFOxEOdChj8mVs 3h25vVre9qSidWv0J8HbNnqsfNcikDle+FLqpEACF1nMQYmPXsBXVvHOF/kZ7M5G2Y6XDO54iZ+c GLV4yZX6Cx/3BG8+3Yc34kxHxgctZ3phasiT2Dgg5jrDp2/ev9oN/rBcVwEa7pvzrXOXDIty4NQW Cvdul4HD/W4RRXugABTQK7BHYiY4tfo4vu0V4HC/bWjRMCgABTQK7HG21viPslAACkABKAAF3l8B 8K3fP8ZoIRSAAlAACryBApu+E/4GeqEJUAAKQAEoAAW2VwCz9faao0YoAAWgABSAAjoFMFvr9EJp KAAFoAAUgALbK4DZenvNUSMUgAJQAApAAZ0CbzJbvyif+FU4u615w0scuaWYuUSuwhuO2Fd1lwId PEYsSYNR+bHjwk053/b87pBkthchQmq4P63Ruvb4uPRAC71aD1jI9b+gXzzi1UdfW/fIlXbW3pJP /Cqc3ZBT/liIa3Ka8z2ZEZ3tX/KvDUsW6GApaGW1bXpVxf7VjvO9RzEfSKfGATZAw+pVNOaRV/f3 TQzSGqXt3hp8YmkZuOIT24K1Obt+zftKvGE6xO5qyZSWYLb68LopFtsr+zIPeM239vWw3OWUD8H+ 3u6+Hue7OwtfX2bDScRM764xHudwM7z2OGeabZqeoyxx4nX8ZnJm0j/YZ7N6RoMixVfF7TZGvi73 +8UEIbgnJN9jCDjzV3+vIBIvkYMutXeZZzEJfEuHuwHeM3tbi/e/gEee6hf4XadA07WHPXd3OD03 PK76dvP0YHtg+Ox8aXderlsV3k7jT5G1/3otb2yE1VqIpTtBfKrLLD1nux5mT6D3Uz6KfKp52iLM tpr2JHVfit+DSsEiDae20KXDmtoe3Twdv5yzy5PWzg4E6jQc7YR7HVNXei0v7q191i4t6HSQ9Fkd WT8UFOIbyR9Wh0gnchKFgbCHkE+hmOk2z8nEfnc0Org7preU52HszEWB2rq9daRfzDPEKSPVK+Vt JM9H/a2mPre1eSjFt6QfyXvr9XgyeWxjNyZBbFzixkOhvbbn+yFtBmXg9VzdKVqMiOw9EtX40HRy +SjjzffWbvwFn3hYPWVzc/0F2eXfgjdsh5k1noS0yNYhukzl7fM84BjfmuEuJ5bH98vXP1/9aWpd Rb778eIlO53sIjfxKeO1M0aVHGW+3gJ+s70DdTZ7AEOX+9fRYNW8diG+rfsR2e+GeBnnXTPSnyUn W2qvada/Xhx7py5RgWF8Gf3MJttsqen603B52qtFCX2/UFfx4Re0vRPuutTxsBb5VTisdf18O85u fd6w6fKrdEnrlt2NF/brxlf0wsyk97u5Ae4+Ud0s4NS8lna9dgOQPLt96YI1eO20fqLVx3BbKjkp WKeq1CuMJ4V5mBaraQnyutB+vfYeDoQr7e+0hjj01/73t9ilwpbgMoUCG8zW4BPnx2OvnN3INHS4 tHhJN4/T7Pbc4Uu4uVJ7+yIPOMa3zq1jKnc8nm9/b9335OoWfHeWwx3ltWdzpvUcZb5eLb/ZSBqM J/frn8vB3lLQ8tqF+Jb4o0kHst/1diVmPlfaaQcfBTddaq9p1mSURpPkv0WgK2ij/nv6H/2Bpmun ZuqTnScpQ/hdrUDTu//gEzt5eW7ualcSPKQf45jzrPm1ecPc5mx8HhnRwd0DTjK11zjj6aqg6uPp FL5kMeOvL7Dp5q/DPft4eGzcTZHxFn/wyD/sqvNWhI9Vk4/i6VL/jPLHNcfYCh/UTxzuJFTeuaSS NNRNz4mfxz5esWulC5P9zLTX8trD8hy/fBJi9HEd9+W95umlk8U4PHuJxnt/XLy8MDRK5qaH+vDt DSPgHo7EXyVxL02Y2ySrZ96zFoS3RsYZPYtH3nR++RzjFI3mfGvwidWrJ1wABcB3/4AcoDes/3T/ Dg/hP6DBaOIDCjQnZoJP/EB0cOknKgC++9tHHaPi24e4RQObz9YtnIZNKAAFoAAUgAIfpQD41h8V bjQWCkABKAAFXlWBDd4Jf1Vp4DcUgAJQAApAgZ0ogNl6J4GAG1AACkABKAAFRAUwWyM5oAAUgAJQ AArsXQHM1nuPEPyDAlAACkABKNB8to7zbiX+q8SL1QbsqXxZrbMvXL5WvDIl2Iyn+yr5U+TnjvjH Rf6nkyWZJ5n1Ju1IrmTaT7aklp1kRWOBsnHbXl4hr/L9/LiSGxwHw7JcxHplpg17iY4dtEFrn1TF 03RQxksrT2ue7tN00wpRv/z7849XlKlCEWvZsccapo+KK/Sy9mW6cXuqvUle1W7ci9mjdUnzvbW0 9pHWbhIvNsIDvtynrd14ZjRjX+YBGyc1fNxq3O5hJTqwce2xvgV+RrizQrtEbq4D8niHvr4s7Dby EeMV2gmO8o7Uy9RSwNPVxNFJva/8UcYrsgfiudE74x+z/vu9bDaXPcJpNknF8cgjulXhmpfwoblu lhVf6qbRfhogte8T0M5douSUi/5o8iper2r8wd66/qJDWqPx33N7tQi/VsG9lnnAWj5uNW43ywku 8pPVIdYujpsb4R+r7oXEuMUCv1xGGjN7kZAOHPqsjWN8r7PMz6K4CDeEaJxhuO/aeDnjLEeZ453v lH+89n9Umm3dUlKZ0yzliaRbRa655HnB3prVZwayTnHlZxZCZLySUy7opswrcyr5jQ6zd5+J+S1z 0OvPSa9m8Zl7a92aSM2vlc2zPOAi+3W43RInuIqfqXYtubkGGXwmqpbbWn/3LL8yI3QpbvG63gyj yyIMTzfV3oJalpdUiYs1yuRPyv9c3ST9X4p/POqTJktGOc0a7nJdrnmFdJNMaPupLe/xXNfr74Vg YO6j5JTz/mjzSq5X266GEu/P9NPuhOukqMdz5estsV+F263kBGv91JZ3k8i46iTIY+pOuC6OrUuX tLeGTyX1cvlTYqeG/7KNV+Efv4qf9aKl7aen8+W3J0Rn/305jNh05fhTzftIvdp2VfNp/4ZeZLZO 8Gsf561q+bgU2RrcbjUnOO7nWgd1u6L84+x8rswJzo+vur22Sfn2JQUK6uXyR81pFvyR9H9f/nER p3mtXl2uuZQtj+cbvVwyx8ofDsnOSdtWQmrPNtbq8UeoRJtXcr0F7Uo2/K0KtLyBL/FuMzm4s52e yK+djI3rMs5+SKld84BnCOr5FpMTqBa3m+ErX4aGstziiJ+MDv6xUJCvTqKlPhxXOy2Ce+Y0+4yG eG6xWG8sCVftivCGVy5lvH+7p/wR/Jd0E/vRguk9qbAv/jHvfzy+fKpwnGbZjqzbPKVLueYx+0Hn SyZn5jiZtOM1M4LMyzLjjxkg1OP27IoMrrZQb5S/3nKi2r9tGmab863fal0TNAbc7neN7DbtQv5s ozNqgQLvoQCImYVxBKG2UDhcZhVA/iARoAAUUCmA2VolFwpDASgABaAAFHiCAuBbP0F0VAkFoAAU gAJQQKvAq7wTrm0XykMBKAAFoAAUeB8FMFu/TyzREigABaAAFHhXBTBbv2tk0S4oAAWgABR4HwUw W79PLNESKAAFoAAUeFcFdjdbS4yXOG/1XcNTq12b8HHBtV2GK8lFbheXbfpLpv9JHWrlOeyUKSDF Ucutz8yHMidxlVFgh8e46JhdO2zAK7tUwAgamrsLru0D/tcPW0UucoFzpXzigqqmS1rzyB9yrsHF u8q3mu3jWIg17cOWRgGaqdvurWPcWRWHuGBZJXNbdfxUzo6Wv2vc1/sj+clzi8Mavq7jcbviHov1 R8/JDrngI1w8Hi6WH8xzr733/kjk8W8iXzzKwxZ0C+C/12/6R42uMpHDzekW452TrVp8ZVZWJZ84 SBPKkqm9Y5M9fW2oS9KhhN+80CHOceca+95ceanXrMeBmA7yuMr2O2l84Ln1Qn8kz/Wccr7fFYz0 n3WJZoJXlpW5s3EOcYW9dS1+qmxnPMQ8awej9EfiTEvcaInL6wLGeChzbTWcbDXXNuYny7022/Wf Me1G30S+uDnnmTk2WdJtOjg5JCG7+nh/eC6v5E8tvrLY8ZR8Yqm9ZTxyNvOlvTXhWF0kp6tkXrjU 3nflykvtjYwDKj66enwY4rR0TOiP0jgjccpj/U45yXxIcb8oadpa13VNHzO89OFO6Rz5YP2YjbAV ZmueKjGOwa7tGafhC3Zm65B5BvN6qv2Z4Rc8xVJc/SRuQTN6iv5ws50Ur0XD07fOon4KMk6jf1Bg gScIhWFmC0m3ucNLlVh/BN0kf+J5soqL/lGCHEdmlSa1V15Vu1VLuGAK01s1W4dkkXDe9gsj+/PK kWVnEuMe0SE/jqM+1PlCf6LjFZ9vyx1fCIIU9eSGDm4csCNqOHh53UQ/9eODNFuHq+GVsOt84PM/ 3u+aTkgva7z5nXCqgOfONuf41uKn1uK/FvjTlPOqbFfzeMXuZlnQn707fe1GMC+t/o5pSKDuJhm1 MnVBRLf6/qScsc9XvvrTcOuBGaujJjLam+HC1kXelSsv6SiNA0/jowv9sTwPXjMPy9tbfGXb59Zm 93o63K/97+l/9If+2h9OJ7epPR0uc0BrcRO4C2vxU2vxX/X+8JxXkRut5PIm2pXNydZybZdxN8+u 0k+7T7cTpU7/3Z/OLnvsh+VDu59W/ku60fddb1cC5nO99oksjOkW8Sc/t+vGcVWv1N6n8cjzlYnG XdtPteUT41V2f9E3V+Y9q/joyryK+8n3R03btP1OY/vNy7a9N2AW/O6+V/iM09TJ8ar1XFXB+2Cf cTydDITZrVFFSLbGzmjc2Bxclu4Wjk90hjTK8kf0M3YHe0rUYUEu8nElffxtSW9p9qSAd0nLS+b4 wRHetg9L+NjNfiXxxUX/Jd1CIY7HIYgih1vOKx9Wp5yzI+eJjq8c6aGCP1nca2rulLS8Pnqu9uxZ k88fXgfXLV3PtPWQM65k5AHVu3LlpRBL40Ak/+VLFOODyK13ji77o55Tzve7tnPRS1un4IFv/eZL sTdpHt3x/T3/nP3wbvbBX1/dv+EXFRpK77X+KTXawp8KTYqaeKS9rX2T7L+izi20erIOq/74SBtf MQ8faW/ZtfSPNcyFL73igPPvrQD7js208DevLj76edza4xYebYPm+tfyNmzZ63quiU+67BN14N95 S7vMlHhiK4r8ffJF2FuXrXJwFRSAAlAACkCB7RQA33o7rVETFIACUAAKQIFiBZq/E17sGS6EAlAA CkABKAAFnAKYrZEJUAAKQAEoAAX2rgBm671HCP5BASgABaAAFMBsjRyAAlAACkABKLB3BZ4zW2/A uwXfN5J6nkQ9nOG1syStwMnO5OzWysNadigQHq+0dWhmJK/95ENmHEeHteW3b6k0LhWMVyFTiy4f zwQMvx8bGADoDGUtPEdy+un7+/vrur0mqFGhQOt/R/ZE3i1LHXj19lbh6YYMtNaC6O3r4RYZddTK w1p25OOr4sfiZTS1rIjtLWsERpV8K/PoXa+SxqX88WrF1PIHwC2/nw4kGEAlVtOx+4c1mmtrHGDw rlF7brvav2UW5Q2z3N+Ql0wrwPSi45P4vk6cy31qc3jItsS9FjWceMPBUlvDHQ/3lM4nfs3+RZ8h lJL94PvkyeERbnoF7nIk5zbI56H2pR6sbjJvON1xViXu//WH89mc5//fsLWPt5etI78/RvnWWl4y U162z+etnrcdEzlfh5JQEeDGH9dKVx/P/mBnGh+uv5fpLOTzz+1wYXvT/07d/XdZsTnw9edc4A4u 2U6B1ksGBe82WPSRV+6I8YR7H8b3tetiBb9Z3sCZbu7J0UZobzPOHV9b44l4c6J2uGYX7Cs52Suw IofunKjYzm1VHkayTmVHq+e477HnKE+BFu1EecOqrj20a3ljQ7e3jvbHpT9jI4ct4SKwLIExwpVf lpftiyRHZ13wR6GnclxylnP31gLDlLl8KsnvrW2+DXNNcrBVtB9FKyvQfm8dXXKcbv6c54mYRriu +/1C+0f7+brcu/s9wUU6/F59cdp0ppY4ZL+je3222PH875in9P1h8IZ+Ot1uBAwLrJlpza066aeA A5Wqb/Y70147Y3qDJ48nU9n0hVP+szZHf6wUvz0JXaC/4O7xfCbKmosMwbNIXFNQst/3v5d/h1PA qfCSKbCsxDCjjL9mk2127XT9KThEXCchHxedDZcaNfLZykTKEQlzgp1E4uKASM7bJaZM04b+++IB eYbXlLy9IZpW9cei/B+7YBZpUdu/tOUlIbQ6aGJVWnba7/ensbt1dmdu1wqnPut2Zmn1uO5BBZ7z lpnotJqj/IF83wcjPl7emo/LcXnV8ZUnhQNhCvs7rb0MiPX3N42mrqWbxk5pe83KLVynRu1U4Q33 tPgZBnOaqs1fSz4P9ceSCnd6TWMdDseu/2/d9CPd4J5/T3E8UGH/mboky8OhFfYpuTvaqeAf4dY2 s/Wa/yqJq+Reazm178D3Jemy+c2xHA74uPfrH7+xUupv7XtvwtdSLSMrvDnR+dlUsK/mZEvc9Hin zc/DWnZK9KT7LcczPZXsvif2d9SOyBt202/OPtnc3Ajv3LlbLcMnWzdtf3zqGMvmbcyjfDlb6+Du XE0dbODE2+/HgJse+TvcuuMbNn+Jntx+5A7fU6P5KZVXvr++NjfdO47ybv1DVB2C+tP4vkbdlZ7+ kVeQsBFC8GAg5DHPXkLWIcCnABwvF08pnj0MM1414GS7lxqW3PQYN3qtm8yfjvaJlvlsxTftGisZ YxOLy4r/bRvgbMRzIaBwT3q6TFrDvlOmQmPdjOPOCBqqv+Rba3nJXPmY/XmrXd6meNuDj1njpXJc iuatUGGYD2FgJlvBc+igcNjZF/U+6R8jZCn66YUoRT+abw2u6qcsSN++nVV5w2+vVlkD6SWJ/vRT male5gqu+jwFzG0yajUtWj6q7dTr/PtotPbEv1j4qNi/XWPpVuZ4p5s2WMWvQL6dMLUbREv7r/sZ AtfWFfYyFfjQ2TpTHRSDAlAACkABKLAHBcC33kMU4AMUgAJQAApAgYQC27wTjjBAASgABaAAFIAC 5Qpgti7XDldCASgABaAAFNhGAczW2+iMWqAAFIACUAAKlCuA2bpcO1wJBaAAFIACUGAbBTaarR/n zhbwX7dRUFXL4zpoqlthsYYvxvOC6Tikie00YLLWvNuQ/zQcyj4/qkzj1uuWrcaxDs74DM77FONl TgAfdF+f5Cxxjlc6y/aXAQ6OP5v9lHMsWuDrujhPjxMz4n7t6B+Z0n/+2K7e/9UYDv78HZYhY+6n L2PW/TT+Nayp/55+oopGZ90lLP9v4Y9Y7737Guu1f5gOhpv/FJ7vGqn3dbsMPK+swAsdEpPLqKna JB2DSGA9VfUo25g7UWk46Ih4PMeB3zWn+EzYJZZ3O345cnz2jcfm9akSxxX9KzsW84ILBpSPkRwv f1zdij8tcY55tyL2Q0TTwmj6BLOgNktTc38PwWr01wVVLEe4n8vfBReKvpncuf3tCH1iTP89dsOf Tb1/j8e/RNLyH/qV/nr6OxyW6HybypNNOnUibOW6Xmdq+X2k3tE3U5mx7/2hS5zP3EeqN0crlHlv BWggb763VnFn7a7u63odNxIZG7g19zfOqeU4wX7P9D3WO6yzI3xfll8rl4/cG1hzqUV/7DptKh9y o6Ul3Onmz3wm9m13VvHDRt4tAXQXRzitvmCqX/vJc4V9i5i4x/OB5Xm7L4N7BjaUWk7zhhzrpXBy vFj+NM85jqznc/LBUNB+r7Nz3nN3COaoacKM2I9F2Q3wCTqLPqSK5drLLnfqLr92C3vvCMoW5vn9 v+5wpoPlA+CFLUMnsbvP8UwnRHWFB8vI9U6un7qfS0fdDx8o8IgCzWdrR0qfIRDN2H853u/EUzfo gm/zvzQ6EEaAytIPl4v5xi5lT/1X4uabGQMWxDfZvpnq1uUtzp08IgdcvdNQZb0P92RBl57W4pOX cnlGh2HqnRpAatgbcKI/dt4Zy98OJGL64xhN/XUgIkavoKqpOQOytHyAYf107RqG8unAcynukXxw x0D61fSgG1k2AbudCDlpiZMmwQyeIhZHTo5o+f7iaw6nNDav4rEJ7wqHQDQpXv/1FmlJgI9xCvy9 d8dDOgPmJXLygaBf9/uvv05z+5ou7Id5idaHBMD1N3vJ1cN9SqycxBUaNt3B/ib+yVTItqvrr91h vib9rzdTNU3gh/G+M7UsuFAr4KK8VG9YjKI09dXhHv7sDvmDTuDyD1Cg+WwtaihzZCeE9MhdlqxE uL+s/Si/WcfNrcKvjXKpWX94bnQ8Uy3AKUXjCUa9GrzbAj+luDPfp3jeVXjkkqi1ONbBHd359MLG S8efDu78+JVXsOpV5YNbZrqPWVu7GU+2T+oQJtnx6fvTRJA3gFOCy1tjVOJP+ULwdDNbYfPfsDn2 kaL5+NJ9/853yVTnwW+1T4fp4XTNsZ2tV6rg2P04563/tFfBBwpkKvC82VqexhW7BS0/WFtedLIx vzYWPY4bnYg2zXe3W+REdLp9ye8wH+Hdav3keNvGK+n7zAzfpFi1vHLeMvHi+dMC55jjboU3elP5 QLdwfn8Z3Qmn6DNl/Sg7ID+N8/vPgfb+00qE1lBnu6Wdg2srRuh2624/M3vmzkrwPprngNL9iDJ+ t+Drut5FQbpPEd4GGJcXJ7bjVVQEpt5IgR3O1gF3uev83T9RcS0/WFveVbzi+yb4tdk8YBq2Zs8H CTN8cgOa9BG40amUXGFraZy/XP2IRQ9E754/XY13G/FT4ApLcee+1+vGxzEhW3Ycze3pkDecCkfy 92W8BP60xDlW219cYB6bnG0i0hOH8eURc2fb50myAlOgp53j8AybtuiX7jJs8Pt7l8jzrArWhU6z J9bGh99hI2u3s/7Z9rE7H2ZvfdP72Fnvu0turepdFLxevBLXr6leesO8Vz/HKBQGl72JAi1fpVNz Z+ll45EzS/quEbuD6NPqfsn9jXNtzXPoMHD2VSruYerEeuV40gK/1t0wHLcTo5Myv3b2SH/2ajB5 aa4fLnX+KODTIXmaLp3+6r3iOLgi75ZzM5Y4op8iD5uNO7WX/37+KkTw2vu8U872gCwXPNKIZhxr Pt+mvLehnitumzXyvF0jfYZKnONlyyL5sKor1G2yv3g/m5VuvoefF9EGYPkOtnt527+/bV+0pv/o FWvzQrj9z+o2/dV96b//+/c0/+vl6H9dvBBu31xZvovuX6QJvw8qWtR7W/kw13Oo97gOEV9vyyEa tl9DAerwuyNm0p6s+xcM2TdZCOY3Q4o78iFfw/crSbvPP123PdVWqre1P63tv1+GfE6LdsfgsuRp ep/X/BOczwkDWirFHfmA3LhfgtNRNpGD7op/XcSa2vkTr3eTpqOSXSuwu731rtWCc1AACkABKAAF NlfA/CsLqpRu229eNSqEAlAACvAK2GEJH/NaHD5QwCmA2RqZAAWgABSAAlBg7wrs7rn13gWDf1AA CkABKAAFnqHADv+99TNkQJ1QAApAASgABXasAGbrHQcHrkEBKAAFoAAUsApgtq6ZCEn+cTu+9Tb8 70z/kzpoRQ+PpX7ozCltxU8qn6nzk7x70WptEs3/aejedG6d54+3t+4487g/L5qLZW6/wzvh16/v w08h765MtchVlM3X53lDtf/Z/HAZVv+aOthWEbOzerCea3BXeftcKbaqnY73/40dmF/VD3V8XyfP nzLOVA3O6xnb6C2zacFICOMvf+pwhENs8cRGTb+OM1cJ3Osoh5jlHwf4IA9UdpXx/tAPHMc6weH+ HWue9oGRNSmrj5hNLFc7lnvjBbP2jk22tKTJT0kH3n8VBzrOHReaYLz/MkfmrCGeCr51tG9K+i/t y/5L+SDxvCO8bVbnKO9cjC/f6Pz80XPiXY0Sf53/XvRHaBfHp4+FNygf3pWR+6O6XqZdWp66G2Za 5rk+r4KRLxi3WanFPJfzITIervt1NP9fb959yOOmx6SaPe9wSK49jXg6ftufgO0OH76dxtOrgxIT W9oeVhwaCs8JXxOBzHnas4O+hyOO6XtfeunNcCL30p+bh23bM7rHmiR/Qqv057At9vzh5Tcxffhz mHl/hnOMl/al9kr6TOecL3SwFaz9t0eXM/rzOthvh8PP/QntzMWLhttaF9+V+b9WVNKfty/7H8mH kIzJ5vbaKzZzxvwPf43lsz5/2KPF2XiFiWxUGQIU+ma0TX3/l+hwQ62L/sX2U6leYRAjF0bJ7e23 eSKtdZb7yxS6nPZK/SI22LbMc2l8GDN60bvj4xKbn2yeS/kQGa/YcVvys+nktSvjfo5v6dPtFCEB mB8neO7oxjT6BwXCnuwSK5g4VwN++LO16y3N+8My51h/BJyF5M+s5pXBVZZH9WEDI/jDZ7/UXkkf Z0WIi3a2Znrv6A8NBvbnlSNcm9ejWKn/K+uC/sn8WflfkA/sKicyqsb0tJexayl2Ah5X94mlkhSv eRJaayzAJjQv4D7YfI7k7XJjEm3BIpNXibRUrKReEWMSiS8/5DbMc19h9iybGJey7djRZArZMliM /vMiYwDj42rLKWwvtknFPb5lRpC9q7s7fSXM3AjMqs85Jipx6qZEhGNd35+UM/a+/Fd/GlY4zJgZ NZHR3gwXUIRX4Cn5MHMlI74P5c9UWYznHQy3t+57equL/T7Ln6ldlTniiVTOq1dqL/qJUwD6VMuE 1rP1gvtrns6k3+k93U79te+/+9M5WJdFuNcrDrHEP6bvu949FLergRSSPsaxVnG4pYAp9UlwtVe1 SO0t5ENLrcjnQFdK3Gr+C/qX2BfzQeB5kxQP61Yzn1WhEXneEtec/17KZ7FdSo64KT51cqJ2D11f aKy+3ihvvkZ8f93OxX0Ic96GC77UQzku2cvZPI/qw41Xz2mvKvmfWrj1Vp/j7y5f4V7eIgkfm1j/ RM7x7F5LYEa6Yxx8f6SPvxUv+hMWdwBiVwfrz1h4eNRn4mqrkPnWc2R18iGu4E8WPzto7xKfPNQr 6RDzf83z5nUY+c1UmX+G+ONKRlo952QHRfn4pvKKy3WeD722H7Zq5X8Gh/t4ubgnp8O9kWwOupxX szjO4iv0aimfmeLR9touEA5bPoYS11z6XvSH76eu6zH1ioPY7EbsaXh0re8vyva6J0qDo8luvWhU 9Tzn2xvLK35cytFtludCsHLsGPGccHE/W89fO7FPauz1X3CZf2pxDjHXLTjHj/w7hBb+tF6zPdLe 1r69uv095MO7xvdZ7XpWva/eF+B/CwUcgsswuPbzYd9JmBZokXfWstvwuLXHLWQ7W6Hga3lbocGb m3iuws+tvZ3Yz2rXs+ptpyQsv4ECO95bt1icwCYUgAJQAApAgRdUYKPTUV5QGbgMBaAAFIACUGBH CrR+J3xHTYUrUAAKQAEoAAVeVAHM1i8aOLgNBaAAFIACH6QAZusPCjaaCgWgABSAAi+qAGbrFw0c 3IYCUAAKQIEPUmCj2boRx7QWR3ni9NBBiQEdpk0iMJzdeUWOAuRBZOan4Ys2/jSwGoKS5owvV1mj fKjekgd5w7Xyc0wBDyKbUdOqN1phcOM4+p4TOZDMKJ4+LFHRwqKiybhn6pa0I3mXab+ocZtdlBwn F55oy2/WkKoVvcq/RZNYT+mDgjJaGJ4avzpILeN6XZEUzGN+xBeVPnKcK12dG5ceuBfDoU5VopTV BjVNQbK6pixE62+an67mNU0h4lE1HbJUnwo1rXcFsVM6l1G8iv8zCkVGpZEc3K7nPOBnm0tT4+Sy Vm35Nl63sUpzfvO9dQFXlVmKqDjK7notB3eo1SzOO380pmjHG19yuGP1Cpxdcd11ul1+e3OO+d3A Tabz0uV27YsrHDbsdPu5+PN/98YVJjdZTnaEN/zc/AxrF7m/kf4i5g/Pda7DO4/0F3njIfDp6UDq 8Zfp/lNQOLwrFRsHGK65kkvtKx02897gCDKpxbnn7EiyZXGjv+hzTez4OO64xHGXvpfGwxivWhon pbzVjqtVN7pPMNZmKTCzyhLWWF6vdq9gd6H+6OWwFiUH16EbHZB3BvEU7cxhfON6XCif4OwuW+1W 5rYKt0dN2Z/tunbAFbaHJC94ifND3Fc689xxLUeZlFTtjWKc7Ep76yr5Ke2tbf57ZRe9jNVB0jPG yXbnCz7GO19gWJMxkuJiDxobcsc0frXzXHZMnksd4TcnfZt662oHHRIe2bhLcZT8kca3+KDNjrcz 0HfyUEiZOz4dYh7oL/HdI/2Xy1txnKwzrm4w1TWrwq8MmtmfZfVidJ7luQxUDn1L32mc95X5widN 8qXydl4MJuw52sEanOwwHG6pfIqzy8/WA/timoFi/kgcWeF7looxn5+mPh/Vgc8f1WxdUq/UXs1s LY+2433n/N7RND8js/WUkcIKctYPl9sBe7Wkv7uyBu98topK9nc5LhHOvW9maFzM29gtU8VsPSwN 3ZbBKTVGSorLoHe4KxD9KRgnOfs2ilPoM26us+ODRX2EF4/u8d/L4wbfLmmcrDWu5nfm/ZXc4k74 E+4VmMX34bBcPK6pL8y4RYXOP38Nr9P9GLXDcLiL6pUlot3+7fZzngq8LFfYoBGPSZq4b+j7c4Ur 50l2J8urN4OTnV1jUFDg1mtN5edR4TigcuhwIFBkf+8utwONGr+/h9wkV9VSo7CKMx3hjkv6c9/n 5Vu6dbXspGvadYnmz62rtj6fF6vk4M69pGHl2z+LitphONxCeS1nd/TnZBl/waKYgL3By+LTD/vi Ci+jTmThw/k8Ix3OijyLK1zCsY5k9Eb5md2n1v4I+anlZCc8EHTgufWcrVhcAo74/frnclj0kLk5 qf/G+c35cezI0J1m6dP/6A80Xce9iazL5/3aPDSu+2q7jjMtccdNAySOO/u9chwWx8na42p2F9pd wZab/hKuqujPihc73iBZ8aSNjXwO7nSjxe/IPb7YeRKzw70+zpfnObtcW0Nv6G7Z9NcYQnhfXOHV nSuJnz1/BjbsrSfuuKh/KijO1EN3/ObLJAvajX+a5efiPubYsnj+S3xlXrogZBncd5lPPPOVeaic FRR3MzdcpVr5XbccOemrl0z4+/Y5XWPmqIZLbf10T/mmZ65yXGK6hX6Wcp1F+/mD4Xgnf5DfC+5c kjjuIt+dGz9jeSuPk4+Oq6nuu/PfKRx75VvvbkkjOLTicL+K4zl+Povv+6x6czT5hDIN9W/fXxo6 /wmxT7VR4rjvge+e8v21f98j33rnC5zRPeU7G6/SrPleNvniaNVmgStcVU61sab6N+4vgfltk1at 8itfIGVI08x5ZcFq+o699WuvtuA9FIACUAAKfIIC4Ft/QpTRRigABaAAFHh5BV7rnfCXlxsNgAJQ AApAAShQoABm6wLRcAkUgAJQAApAgU0VwGy9qdyoDApAASgABaBAgQKYrQtEwyVQAApAASgABTZV 4LVn62L+66YaozIoAAWgABSAAo8psMVsff2qc4je2s7x/MOc9/6YIrgaCkABKAAFoMDeFGg8W0d5 sSK/di1SU76126F/fdHZvOZ0Xg92HVYYr8iT3luWwR8oAAWgABR4TIHGszVtfue84fHMIZoh+9PA jLt133E6umyHmt9fvKWfy+/1eneCXP9M5n9OPRHqRaHcDv1+7+ggXPLk2/wvmeoth0uyQ5P4WMHt QBf7j/R9eDzyqZ/uNtANA1OfORj5RA2hE4d/LP1C4f9jGYCroQAUgAJQ4DUUqHk8GmeL4cXGucKC Qw35wSPfd6AyewdfiCfdOoqwDwWgABSAAk9SgBYTjffWz1qu1OKhvixP+lnCo14oAAWgABRoocA2 s/WKF1vIFc7nziq5qqK0op2n8qTdo/U67+61yCrYhAJQAApAgfoKNN/Zs7xYjl+b8KQRPzikrXqw tX/VfEC6hprHINOW/8oUNk+lA06NA/R6QzxXeM7CMiZDAq8TIgPe3Dy0qAAKQAEoAAWaK0AjPvjW 9Vc/xRaB5i2WDhdCASgABd5YATC4dhHc8V+ymbfM7Qvh+EABKAAFoAAUCBXA3hr5AAWgABSAAlBg 1wrQ3nrX/sE5KAAFoAAUgAJQgBT4f2rhC1NPbOcAAAAAAElFTkSuQmCC --_006_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=24590; creation-date="Wed, 06 Mar 2019 04:41:12 GMT"; modification-date="Wed, 06 Mar 2019 04:41:12 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAskAAAE8CAIAAAC94LuNAAAAAXNSR0IArs4c6QAAX8hJREFUeF7t vU2Wo7rStk19E9jzMPnO5uBsPu09CuMhVKfau1umJlL9tKeTX+g/BAohYYz/btZe51RiEQpdERKB JIgf//d//9fgAAEQAAEQAAEQAIGVCPwgOf/999/fv39XEggxIAACIAACIAAC70vg//2///fjn3/+ +fnzJ8UWv379el8SaDkIgAAIgAAIgMAaBH78+PH/rSEHMkAABEAABEAABEDAEkBsAVcAARAAARAA ARBYkwBiizVpQhYIgAAIgAAIgABiC/gACIAACIAACIDAmgQqYovjR/Pjh/rv41ikQW35YS8LH2zV VPsgV77X6h3ProS56qNI2wcpZCCE//YPoRdpVWj0BeqGJjtLmTPBjlOh5+Yj6wkL1Ci/hBzb6/ay 9iLCT9Vxys2HkiAAAhsQKI0taAwduub7W/2365t95g6vta4tfz42dBv9PiWaTD/92DcnXTX918lU Tl9N2zS9C32GoWnbhk4+0dGdVBu/+qbtdXtTQEbNoVvdnDWuBUBafR3GQlapl/xE2V1b9quzgSBV 15MhM0fbfGU9oaTBC/Ufmn7XHJx6L2uvtjns5rt5CWeUAQEQeEMCpbEFv7sc+nlQteXbg3AfPTef w0xIEWnTNf1F32vPDcUYIRDRT7p2PiB+IPPzKzTDwZ/V0ufZDMroUd7MmqgHbgqG/OyOXO88RFdC RVc/mj2b0rDBhBbenxtfdYj55HqTeprGUotMXX5+yP8ZNVaq11VqHuvttZnHX7LRJdidfODE72eX YDI/TxCMMpo/k9vL50XslEOG25xVyLhdJrzVl7+GvbpDcymboZxjht9BAATejwB934K+nfXvv/9+ Fx9dW1xUF6wof/pu+1g4nem+2+abHm7pv/4rW/WXKvythZy67+703bf0lzroH/7ar/67cU2gf/sa 6ZLZ8yTOCDQyqYrxv0mHJsiU6s0T5FqZkkpnugu7f3NKvo1cplRv0DnWU11LU0ME2ZA5haaZ2sd2 0c33KELVsQXTZVzphFh3OV0YzK1VHdc1qShpX2VTcgnG0BfL6yYZiCbvpq1+VXtRY2d6XN6P8SsI gMBbEqBIqnTewgZd+oGvmUyPiyFZbfmJoPOlOdNDulkg+GqGz4Lor9OrNpfm5J8vz81wbnq/X4Tm XeiMlkTPylTYPKnTQ79fQJHON7vm6OYnaMLAYyFptrq2+e3ndeR6C5oxLkJTQaZB7W7uaqle3eqE nk6eWogxS0gdozdXW/R713SDW6Ohf9CfVZezwtReu/SgkdIKV8bNJPsO8bwIeZFfzlii17m5FF/2 AvaiJUXqgDhAAARAoJZARWyhZno/mu6r9K5TW15UnRbXTTTTqhtVboufE3E6xdss2mZHT75ux8Zo 34bfyUGbG/ZsAj95ngoQAbs/wMcQserh3p+tt9ZUFeXL6p2PUSqqDEUPB7UqRAf9L/07c7T/o405 0e8UQOxc5FShXll7F7Vmk4vK9K8AUqN1ub1qpKIsCIDAWxMojS3UmwJ630Pysc8s4fPbRG15yQg0 f0B3cL+NgGYKip47J4/L3S79pgPf8690cDe29Hl6bKU9bmYfH20E8bFFHPSYO6s5pHrXdbqLmUHR e0GMFdL1ynou02dar65bT12UTFroDYO0Udccaj8vm23q/RyVRp3f5SBxHp0nR+XbkNP6Z1hQELCM VHzVs9jrfC6YJFsDCGSAAAi8GoGi/RZ6wdvseDD/+X0GZi2J1mX9bgC9O6CyPK3v07o4ryLe0mHk T+uNVrJYpWqRmP3pt1zwKjInSaxZ7/f/+SV2s+/BKqN1tihYdW0b7U6QRCWX4cYc9F4BX6mqy+yK YFs6/JnIBFITBD094RHn0fmoCqfJqF6/dSOxGyPV5tBkZ3RzpmMukVj1n2zNkTjz85HfZvSXl0j5 Jhu1L2Xkt69kL3KVyp1Vb7myjEaDAAiMCVCchFxl6weL9PxNj9zTlzbXr+k6iTfUc2g+LrclcEPl 81Rpcogm8AreDb7OOImrb9jklL3Ma+Rh09Lq7YFAEACBFyWAXGVrGjZ8K2y47W31SqVvqqd94XPf nAs+grKgIf4FWlqhu0/0pl9yLtn0s6B1yUvuYy/9ejACi7WMCDkg8G4EMG/xbhZHe0EABEAABEDg hgQwb3FDuBANAiAAAiAAAu9JoPQ9kfekg1aDAAiAAAiAAAjUEkBsUUsM5UEABEAABEAABHIEEFvA P0AABEAABEAABNYkgNhiTZqQBQIgAAIgAAIggNgCPgACIAACIAACILAmAcQWa9KELBAAARAAARAA AcQW8AEQAAEQAAEQAIE1CSC2WJMmZIEACIAACIAACCC2gA+AAAiAAAiAAAisSQCxxZo0IQsEQAAE QAAEQACxBXwABEAABEAABEBgTQKILdakCVkgAAIgAAIgAAKILeADIAACIAACIAACaxJAbLEmTcgC ARAAARAAARBAbAEfAAEQAAEQAAEQWJMAYos1aUIWCIAACIAACIAAYgv4AAiAAAiAAAiAwJoEEFus SROyQAAEQAAEQAAEEFvAB0AABEAABEAABNYkgNhiTZqQBQIgAAIgAAIgsGlscT5+/BgfH8dzY87v h9XMMex/KLkPc2ysD1X3Iw9AEV+Rdyno6zl4F6q3r6VSqivKbU5g3m83V4lVCP/J00/wub6/39Pg qPs6ApvGFqRq2399f3+fuqY70f9/961Svz18fZl/rXSQ8K9DqcDjx83vskl9blcvVTeDk4grI1x1 LNC/yi5J5ZTi39+LvIUqv7bJV/HCxXME5v12TsItf4f/5Okm+Fzf3zNVLhh/bukekD0msGlsoWKI +JYfnbj4aQ12s+dzHR/HWQMmn2vtvMhePc7rw8nXP/RnHXFHPzR2LsWcjer1hT+OxzA/YFSnh2mn gK0i/Zwt1WtL22dy/1e+1WwyKA6SAs/wkM9njqJHf5lzoEMt/tAXZbgJutbZRQtJ1JsVbhpvrgpN Y+2K6MjtDYg+6JhzuaBl6VRZWn6BPvvBPdizeb5Me73fiv6f4VzT7yT5fD4y6GnOfnxoQ9k2RbOW Kb+V+qPU78Quk7JXjo/kP1IF5f6Q51DgD8SQ+2far0R90uOYPO7Ndex44lmeX6yuN9Gu+vFn9saB AusT+Oeff/77779///1XTSNsdfh5C1+hfhI1kxrqqdT+S01s+H/qp9W2L9GRSzDltXwzVxLJ13Mn 9jyXLNVLYoIUr7G50jwVGw1PHRc61Ueqly4MDRZ0i/V01IwCjo+et3CSVOMnbRxXlOas2uQu5TYS 9c+ap9wumXqnFjRnQgtD0zQR7VTWPIFPur1cQ6XDrL+dTsapNJAp5TEOSX7G35yi2r2cPkJ7xf4i +b/EubbfSfLTevrSrnpfTPLbnD5yv0s4o2AvQX/Rf0Q3r/KHHIc6/xT9VtBHGscq7T7DZ9rfa+vN 9MfkuJ0dfvDjdgTUrfBxYovEvSEx952IA6bAkvew1L3H3BImMqV6tVxf3biW+G7NtaqILbg+skAr PBq5zf3TDkmj+9ykICtq7szjqNUwUfIkf1zQt4vtkqu3IrYYAfTmy/kVXzcpcLZYVMEFKfll/sZj x8w9O7ZkiITTsVfSvvX9Top1RD1dCG7CMR5bjIJy9Wden9luMuqKDJCvK62n5D+ZIbrKH7xDuoct q8YS/xT8NqmPNI7V2n2Oz7i/L6lX7I8Lxp/tbq1vXxN1sk3XRKpnXdrdbjz2bbJkXlYvlapuUcEF h0Nz1BtRj8fmULxrZCK4bcu1K2tvge5PUiTXXnZrOzX7mTWRYf8xdHZepHAXSEp+If9dO7OHqFDO rJXWkjNbUaJAym9X02eBvarasJL8Jf6Z9NsifcI4thrnImhl9Vb1x6J6UWgbAo8dWzRdt+vr3wio RXe5mHdK1FKgWZQX6m0PXTP4F1COxyvfbJnWq9XoTt1wpLX1oaPqsgfpczFxiDmG4dK5aOTcf7q9 AufjZ7/rcrIkzqPzAZCuTtC/Fn+ifL7edAVWG1qL9RsrlJhgpOHYO1SiX9kNJb6GfPh4vlxaB1xB nn81SZBf5G9Mf0aft7e6v0ic1+x3CbvkPCTptyvpU2sv0X+EBtTKFzlU+2faryR9xHGsknMtn/p6 s/3xduPPCkMYRGy9JiJN0RlLqBjVTUywLRfcTPlZ5+msRjSlmpTP3h6IhMfrBNGmA6NQS4ddzB/X 60qn9bETZuHHxGaIsM0hP72WAmpW5rvOP+XyLRxO3GQmOd1e9y5PMJDXJ6P/WOclduH6zPMMHNq+ NzsT9HxCNKWq46toS4p3LVuDBEEyAsNvgecdNCN/1t8ocghLVFJ7Y3sZL/JlZ/sXV74cRU7+VE/v l1SZ3UPCXxMT/Talj9TvxD6TtFdOf9l/knVU+AOvNeZgrJDkX9JJ+dAh6sN/COOYWK8INM1HHvcq 6805YcX48/ZLFJsDoIH1B+23+Pnz59+/f3/9+oVQq4oAPTF+Nr/LX3atEE5zmZfDTSQ7JW6ofEU7 UbSKgHKL09eh6hoUBoE8gXsNBfeqF/6wAQF6B+zB10Q2gFBdhX8nSi21L98Pka7XvqG1H879LT67 wd7rvIHy1ShxQTEBbTnlFvEb0cXXoyAIxARuOo5lYN+rXth/YwKYt9gYOKoDARAAARAAgVcmgHmL V7Yu2gYCIAACIAACdyGANZG7YEelIAACIAACIPCyBBBbvKxp0TAQAAEQAAEQuAsBxBZ3wY5KQQAE QAAEQOBlCSC2eFnTomEgAAIgAAIgcBcCzx1bsCR/PrdpGqOcly+HvVz+XYzH80zeVAHicNOvo95a /iI4NunoomvFi/J+mOWwgj4bc17dPzfWf9b099LnpuMSzz/MP/rKz3syPK9ylH+YUhbo1NA62e1+ 7tv5s6RR4AkJ3CVX2TpfCYsz35TIHOfOmf3k5WwazJJaVyqTzM0T5Vi6rqJb5/65tfzrWp+8eiZl 2uIa6/wwVFOkz70439o/a2k/FIda5XPl68e98toneXFtat/x+TAwujRrug6fRpV7eFE+4XIVUfIZ CKhQaMvYwnzv1WXYVLXH+cRdaKY/pm0B8m9aszv9+KOy+qe8fFMg9fnrhK2S8k059hna8Ilkc5KE O33nMmKyCrxKov6T/IRR/sbea8QqTXGz8kNmkcSHzI0NuHxzZsottIC+sp36+nmcJTqKu/PyRT0V fl9t/G1vqb9lOE85eB+yEGbu5UyVL65XpGYK3dQPvbnGnJkduxPTJ9Wuaba0jTiv5J+ZMTPJZ4E/ R4iiJ4e0X0n9Om0viYM9b23r/8rfI5LjTGZcSktL+olUsfSkMolmWEARxRZeQPlI+ww3SuhYTWDr 2MIM3eEGyFJaSHEuDwZUn+TDQSp+l+QbNnUen5KvVXCJL6lbcX1MN3bJo2eCi9NJJw2wwcpMrmdb LCFSj1NhzGJJWOI7u9NTl7dyRjQyz3lTbpPnG59ZJd0uHZOJSIR7bULPkDuetzzj+TLnFAdtUWte m+Mh36sizfkwK9Sb98MJB1kfWf59OAv2rfXPCtquR1f5szSe5PxK7tfJ8STNP07fMzunkhtnUuOS yC3rh+OrhGz1iWaGkul5i+gZ7JFmf6tvkrhgEQG6Ez7Kfov2cKCMp3Z5buhs0oTzcTjTx6/tst0H 5Zk8n6/MPXrVshXpsyPVXA4wepDchbSo9uHepHtQz5jZqnaXo1uOLEifmROlYJlZE5+0M8vNq3ZF jnhKuNqHrHIHuhs7Kmu2yyKM2tX07uzhd5zIKM1I1ifBQTXrtzMvcZ2vQPutTbV6PF56n7l2FQ4Z fVaR76dnzNQU959azrKH1vpnbQ+t8GepX9D5bHtVvFnYryXtTXJj8+tsiuO5caYC0Xp+IlcadmIM ne8+jRoVTPzXDfhQfYXJXqXoo8QWUdrPU2P3/tBoN455Z27ZT2IXSjpF+Txc35u/hVU2627cbtyu GENBbLSBPt2hvwx00xj2/e7g4pJb13tr+RHoAs5P4p9l/WL99mo8h0NzPJ7pH8cj/dvnKK5EV1e8 0k92bTP8mdbQ/q8bnR+GgYZmVzLMRybzK1H83d33mbAOGkqvQ+AOscXlojpYw7cgq03F8YsI9hGq 62g2Q3fI8iMpv/zyXMn20F3M+GAOeq7slowS58uldReej5/xxIWsv/2FbmMqbVVO0SXcmmaxfKdQ tl018oW2Ef8mTBQd3XOgSGJGn8l1ClsQOhyLZpRo6KTbRTRpUVuv1ABJn0fjbPVf7D/r9M6JlKk+ Qr+o9asZfQUOZupidtKChG8yziQaYWaPwwDn+rU+74ccNXJf3PRhGkX8Ag25axc2N93I2BD7cAS2 3MtptzxYBtFevPjRPVqYT/40ftSfblqjhfNeLUvo9fPpbMfMdogC+aoZTspY/txOTr6lrO26sMWV /TDZqxgqCRsRDEv1t/uVbbngzqaK+Dn+ZHkGyauf48YRJfA3cbvI9hP9Jbvk9GTrFHrLr5v8ERYF eXHPOSeft9gMiAWrxUpgbPJkvbIfypwFfQT5msI9OCfrzftbpstPjJnmU+/PdnsT6xiJ7czMr6R+ nR1PEvxdg/g2pdmtJQkt+UZy3/NzgnJ+IlyX7NeRW7EewQrzvjjiM9tNFy3p46IHJkDeiTyoDxft QaFCAvT89Nn8Xj3NfWHt71Ps3TjfsL20RnE5wGPfp++8bUuRB/VtTf/EDfff5FFbVpasSD1x27dU /d0437S9drvjfqCt6fnlzC1NjLpA4HYEMG9xO7aQDAIgAAIgAAJvRwDzFm9ncjQYBEAABEAABG5N 4A7vidy6SZAPAiAAAiAAAiBwRwKILe4IH1WDAAiAAAiAwAsSQGzxgkZFk0AABEAABEDgjgQQW9wR PqoGARAAARAAgRckgNjieqP6z+nrL9r5v+h9M/1a27O9cqYb8HG8hkv8Wb5rJK1z7a31ubX8dSho 35S/cltr99ryazUiyHmM/rUCh5CQ4wbDRRBOtqdParoP+vLznql/EdckO+LeEn7a721OhvVNCokv RGDr73I+8KfElqs2yR/o0y1GeVmXV7DxlTO5xdfVZjYn5LrVeWn3qvdGzVlDbK3da8tHOtbyT5Z/ jP51FQeTnXkN8yVkTPIV2+/Hjs8HBdJ5TXkqVHXtzRS+EQeI3ZgAhUgbzluYp4yPD/VYTA/z/msy JlAzv7pomQdv4YcPOsLzdPo8ewSIH9HY7MLRPJm7tCZCvRUBJKXtOV+oPKnkKmWpfC5eUzaFkWqv fQ7ba0KGUlYJ/txmmpd+zuDcJM7s/DUTLV4M10Rsl/6hPwebhapFf0jb0SCmSt11VlJSH+NsiXpt 6dg1slM4afnaapLfTk1qOsZRu+XocVFqVyTf+Uk0gcb+4N1rPG8h2X0tP0n2x4zdkw6fL1/cv3Kd qbY/1vcXNsAFN1d4KL/zuU8OfQmFxfEt1bgzpUU7xfmK9V90Ps5jfNr1yV5PScr0wBYdOn2AzvaM AwQyBDadt9Bft3fJLGyGC/NBf/+gT/9WpVxcLMXLYhx9Oml5NnGAT/IQEj5oHVjSjfCte15vXZRn nzzo8aXtlObhOYbXxnXOtNdnKeHlJX2i5zY2fSLxEeqlAcdz0LkArnsumWruLW/syxMMJJ9HJT6S HRUfk8TAaH7qeH6PJMn0c3M8BVX4bJ1sbwR0jqfOy8BzWzD1U+3SXcTlUtHWMx4SaRI9gk5+tcjS dl/NT4T+qLv8bNad+XmO2v4l9aPK/ljdXyR7eauUDjgyz+SsRTKTR6I7BLdPz1toe7nbyJwzl7YF 5V6XgPKVrWMLN/SbgdTeGllGHee/yXRZfDCKkjj5eIInAQujdTzrGLpWrt4qs+tgQvdPPUhFsUVQ 2ndguV4pVqiNLeK0WImETBHn0ZrO1ZO0yXttgoMNASf3GImPZEdDZ7Iy5aFVxBb8nicLHJkjJV/w T8GQo2RnM24Q/Txqerg3xCFcKraQ7C7xX+AnsShu6bVii6r+lcZf2x9rOeTsZePB0uFG5rlebBEe RaXQ5Mpnj9LGotzTEiAf2nBNJDN50tIKwmjF0Q/N/AGuYXuIkucpFxAlmbAGSYwYWgeqzeqSq7dq tosymZ5pmYeaQbOIlEj54qtIilmt3oySKT5b1FvFTShcpmew4xp1ehk6ZbpaL6MJ5cPyfCWS30q6 tq3zyuta0x36y0BracO+3y1Vv4x/gZ5F/bFATmWRWv1ry1eqs17xSp60Vjv8mdauB6no/KDHrslz HS19+JMs4DgcuvM5v1y7XpMh6VkJPEZs0XTdrk/uYD/SDgu9L8Ie7p6dPn++XNrOdofz8bN3V7YH dcd3fx2Pvl+I9erqzNpm4faDy+WicnLrfjtQ/JL1iHy9dc50ubiNI0xTgZtQrzodoAxHD64eQ53u prRtgeZt2iDoKdpxSa2perWc7tRReDjsh47cZuEh+a0s7tx/hr1Ef4adzu8uHMThYuIfcwzDxbk9 hc46OFIr6rPqi3Zf5CdTZaX+aEtO7Z6nXV6+tn9Vls/3l2kjsvaq8LAZnhNJ5ArRuOo6mD7vBzb1 8siln6aNZ+LiF4xIDTXU4QCBLIHt1kT8NAI90dk1/S9zzm254Irax76wyGdGfTdHJJ1ncxVtR7MJ fPOCE9/S4deq+TpiXIVbVihaFeb7rv3aKm9x2FHlqp42IV9+bjq37XuzU0LN20h8xJ+iKXw9cLiZ JGerkum56QBld9UY9m6rjfp3tF3AmiZCnW4CN3Cw47heJyitj21J+HFiYm7OXLtF+Rn+SXm0fmHc 1RwOjtQusykpHKMGqB+jUzIH2e7pJsjlk+0S+6New3INKOpi0/K1/SvvwXX9sZKDZK+4Uj7CzXX3 Jh7f5LbxKtKLymzOmBXmY+TIf5JLJSXjA8q8CwHq2u+YB5Xi9M/mN9JzF0bdtL+d1pkeENcN7Uhz z5fDlk2meQ64ZKFDohgIgMCDE6AJ/wdZE9kClH8HTG3JWL6OvoWqD1TH+Ticu6Xr9jdpx03t6N+M PvfhK0M3aQYTSi1SryHSm6jXfbLs1npCPgiAAAgUEnjHeYtCNCgGAiAAAiAAAiBQS+C95i1q6aA8 CIAACIAACIDAAgJvtCaygA4uAQEQAAEQAAEQqCWA2KKWGMqDAAiAAAiAAAjkCCC2gH+AAAiAAAiA AAisSQCxxZo0IQsEQAAEQAAEQACxxQP5AM9reqVamfycV0qevTxkaqRPqtIn/9xHUPl5L4Qlh5Tz uO737Fvvs/WHArrG5OdeXRmFqfC7qxX11hblOTh5KtQV/YGpZKlwJePPLtaqv375G+lzG57rN39b iQl/2FaBJbVJ49sdx70lzXjpaxBb3M287LZrdWgP9kOl1+tEougLcFJGlSr5Uz0zl9NAtae0zvr4 6gZKH20Kj877DzkcKK8b+4RkN3yaT1nTGOETw5zUR9SXHPQVwvF3D0diFKbsx44Lqq3iI8kzXzr0 LIzaK/oDq9d9Fjc+dbsvvizgQyper89N+1eBX2xdZAFnrWLCH7ZWvb4+aXxbcdyrVwpXRAQ2jC1M SPnxYZN0+K8UGX34s1v8BaHwaPtBR8i5kD4fno5HT6z+h4/jkT3PyvWmPUWU30h6JuToSvtzkBU9 O1+8JHa6Vk/Jz6v0z+s5reJM6b3sB93NrdF+2ZnOX1SeWHMFnT/t+uR0ASVjOV/GcvVnww+zHZdN gcSyA88wh8HnS6KZDZkzn3ex6UJq+QhtUDFE/DG36MQq/sDaxenIz3nV/SXh//V8Ms+d2/cvO8+x 1yNWcWqhhJ9ou4/9Ux4PzUBphil9WA/l8y6mFv5DejyR/Fnwh0wvm/Yv5iJnm3xJ65QZz40QUtvV PzdrKI9XswMCCtyZwHb5RNxztEsqYTNNuGQi4Rv16mnbfeKeZ69W96a589+nE8854r+fHxIs6Gd5 XxnPQ83rFT/7LsiX9Mx8Pj6ZY5prx2VW62lmDqZptuv1r8iFLSQlT6mh8tFrHaN5C65vmHIY58hN QPU5XKxId4kW4qqapNkwhePkMmk/5AlGYg+iqZGydBgFmQQiFs6CXv8r/IEE+3bZ/DBcnamBavtL xv8X8Jnqc6/+pW1t7Ztw44lNJT9J+6eX7i6jEyy5kvMr5re+QMp1E34ojBsz/jB1Val/RUyY++bG K/OMYXroqZvpPMJ4ZWdGp+ObNO4V9D4UWZGAMvHWsYVzKdNhbVdJzN17l4uSAvm4gWc6ijL8JHM4 6R7gwYX+kKtX4JyUb29oPkwsutlIsUW42N/2Fugp9bF6/SvuDQtjixBeJ5Mgzcd80YgbjbqjpF2T gnFsIXJWDZM6XgWfub6bjC1W8IeRXeLukIhBl/QXqZ8uib1Sd3FRfpVd0vdmuX9l7uWpegU/kfzT c3aG57EFH0T8+brYQmrXnD+Mmyb3L/5sEG70+fFKGCXSdhTHK1U85Se583P9D7+vRoDG9A3XRDIT NO1uNx67/VDCutipYXv6kucpx5Rfphd3G1BtVpdcvUl1M/IlPdeYl6rWU14REfmsof+ubYY/07p1 3vno/DAMZHJXMlSdXGWnjNDd+bxsywU9H82ku+fqrsZ5DaMv7C/rV13WX9bwn5zut5T/iHav8VuJ 2xbt6g79Re2HGvb9zuUdWq3eovF8fY+HxDUIPEZs0XTdrk9u6LcL276pLixInz9fLm1nV67Px0+3 kZBW+OnmZjYJ0nE8+vuUWG+arSRfLabG6vvwJWeky8WopNYU8+uOlXpKlS7Uv1hPigIiO7qG6fO+ ierlkUuf3UIZvyhAanc67bs4hh66y9Hbl4AOF+cGzbn/dHt0lEvssoIkzqPzI4NJfMxa8dyK8pJu XOkPqnhw+uHoO4ZQd31/yfp/sf/IKJ6jf43HseD/sn+KfTX4bdP8GYLfWpr8FSwrY8pZ8JMF/iD2 LxpcDzSkqh1VNMrao9I/68erJZ0G12xMYLs1ET+75TYm0wS4OceWGH3r7WNKvM8/PLtI59kUWtt1 QTifxGjpsIv9agpIEpWcHpLkVwmxksPdNSzomva7LSnq32xrCHeN/LLL9MY9roIEcz45/Sd65ifO uCiuZRDD5qhYYW6Tkf7JpZJYi9TcqdlZYJqpj5ScyQxtictF9EU+5oeiBTJpKW8lfxgtIer4SllB 9JPa/rKS/4j63KV/8REr7ERmQ0eyI6T9f2rg7HhI6wvMb5njBjlt3xszmn1L3JiRy6XRRUtM3h/k nj23NjF181S9Y/vO9g1hvJX8RPbn1Sb7IaiIAHnmO+ZBpYj/s/l9/UtuG0eBqO4WBOAMs1SBaBbR 6gVongZD1OpUIXAzAu+VB9W/Q6W2HMSv/G1GHBU9BgH2niCcQTAJ+su9fJXI9+dzT69rxm/j30sf 1AsCCwi847zFAky4BARAAARAAARAoITAe81blBBBGRAAARAAARAAgSsJPMh7Ile2ApeDAAiAAAiA AAg8CgHEFo9iCegBAiAAAiAAAq9BALHFa9gRrQABEAABEACBRyGA2OJRLAE9QAAEQAAEQOA1CDxW bMGS3t3kc4a3tln8OckltWXyQC4Rl7qG52nkH/fj5/11PF9oyLuofw4/7ffsW+xrqQk5IgFtqeRn bJ8M2l37i6XIkV2vT5UBeF7Tqguzhe/frvXaEtJjv4K7r8jlGUQ9UmxhMnG7I/tN6HuipS9WS7kt 6DNzV345w+QlT+T6WanFNPDsKQ26Pr664cN9/Xl03r9YT+nQO/bJvW74NJ/WpmHRJ2450Te2V1Lv HcRk/Kew+eRm8UcPi667vt58NQvk37W/uM8Ds1Zdr08G0ZQPdfYb9PT7t6vIHcsK3Xo8LNMCpZYQ uENswR6Fw01aBdt0ozv3KgODfiqbaQ2b4pgNaXWNH8ejTu9gpLvcIjqXx/SsfSincm4iQauq/+jP 4RrfgMx8A58PMGkR+POK+XW2CXV6SuwoeqPAwkVtpt+qv0xUx86fdn0ygKKkY+fLWLr6cO/XQbSX ae3Hh02uYXE48R7cxOjBTz7oCP6QPi/6g//BOoBFLdc7bYhkr5xfJXHI/kPFk/0i1wsu4etWPuDz +Usiv8rWK7Z377tG5AsJPSvlu5409nzLWah32o9kN1ceZ5Qe9y9md96qZP/N6iP4Vb3dm2BHplGN f9pg341js+3SOlb3i0S/q7Q7q/LM64/UKRgMc+NnLbclN01cU0Zgu3wi+lmZnreiD+Dz9KeT1M+5 D5efTj7f+iiPtvyRf/f1evWw4P6dkWPutS4pvP/0fSan9jTnr5LBq3Wtz+duTuQOrtczwWFhDnSe xiVYLzw6y/nHrQ766cwlSdGhiIMY8jKb2RonihNQDOfOfwt8gqW1Diw5S2gIr1dyOcleLB+OacBs hoR0zvFcv0jppOt1TWD1ZvyqKhe8t5iZReNJbaT+WyXfzpxx85u5NOcpo3qlfpSREywR3J7EePVN tpkwUTqq0Uv2HXjEgWfoKUh4k7Y798pYfpV/Vrertl9I/VEP6fM+7104Gtn4lGh2PJ+Oh3J/rOJW lBoDhRYQoL617bzF+TjsTmHVoDuddiE9aVks5ErtLkcXp89ldbSXUG02T197+G3yAtORlaP81DyR h4ur1KSEnNF8gHrA95mzqiTdVs+8KuGJceh+e/31rIddW5mfZ2pd4lOe0ZT8wXzb2MwmkSFdLnWT UdWc3w8dOY1RUTqftiPJb1y9yugOvVxvlU1M4bRfVQla1C8UFNMg7s9V9WYL+3aFHOuL9KzVKFGv Smy7Rj9SYrwDE7+ilaU0h6Rf1TbV+o+1Y8RZ6BfpGmrbVd8vxH5X2WQtx6bkjVKn1o/niZpX7deV LUPxMYFtY4vV+A/7sNxfuDuhbXfT6hfIWa0NNYJW0nPXNsOfab0tLXXE54dh2FFhe4TnkmRkRONF 52KCmkbRTZEqiR4cWTJH9jB0athe0eT5Ij5h7M7VW9cCakPKr2qFLCh/r3oXqPrilwS/Wquha/rn vE5l/ULqj/Py4xLdwTzXDft+d3APKkX9d76mbbnN6/PeJbaNLdpDdzmGvQ7qcaRb8hx/vlxad+H5 +Fk0cXHuP8Oa/Z9hp/IKL5FD/nK5mO0a6nle3Ndpnkk6evqON3f4C6wU/qqG5IsL9ZyIM08fU330 ed8UpdHFPe6nVYo31JN6fDaiokeN+IQrzcaUcOxsYJg+L/Ehf2vCxNjRPi9N7VKksWCvlF/NyJv4 z5J+wepVXUD7sz5kvyr3W6EBM3peLV/klutH0kUJDkpMcILhWDRwJOSLfpU3fDkfsV+kK6htV32/ kPoj97iC8VAVp8GmOdJx6al3mmPR+Jby80puRf0ehZYS2Hi/xWiSgW1iiBswt4THpjPbrlNP2Pkr aGHXFDOHX5QT5IxfUomEhx/96elLLXyPQmgamwHw87Ft35uVX1pjEOUs0VNYJeMTwbxdoW42l8AK 8zXlkZ7Z5WavutvATqXNOVN7PDFtNUqelAq7dXpr28gfOLg27BvIiEpjC3K4vUj5tF9ltwq5IZX7 bDw/n3dms1OA+TPjL+ip9En47Uxb3RYZ1mUyehbLl/yce0rYWaz6xdhP/G4pj9L1sWhzk+3roX/F NZuAWHl7ut/l9JH9SjT9hE95e+eGt7p2+Y0ttsMU9AupP1b5Fd91MRqvC8e30ea1hH2F8WTBjgFc cg0BMs275EGluLv5vXSvw9K4Ddc9FAGaj/lc2wngVw9l4rsocwu/2rIhz67/lqxQVyEB2ie37ZpI oV5rF6O3p9TrrbQ1cPbV1rWrhry7EwhvatIXOZaswIktgF/d3bh3VOB2frVNo55d/20ooZbFBN5l 3mIxIFwIAiAAAiAAAiBQTuBd5i3KiaAkCIAACIAACIDAlQTeYk3kSka4HARAAARAAARAoJwAYoty VigJAiAAAiAAAiAwTwCxxTwjlAABEAABEAABECgngNiinBVKggAIgAAIgAAIzBO4T2wRf9ZxXsvy Epl8pCSEJcuc+aBmskaeY48nT+V5+cpV3aqkbvS2L99eyTlPhufD5B815ee9BJa0c5x1M/y037Nv im9llkeqZ9ofpX6U71+P1Ka761LR76T+cmu73Ggcfuzx8O6O8S4K3Ce2oI/nTb80QF+aNunDrjlM 3vB0EiKTSdwd00/xldRrvoDoE/iZz9VRpWVpj0pqWL2M+xzm6oIlgWtwlmTTaLinNPEuR5pKb6aP 0XkfSx2+eLLF72749OnI6WsXRs6Jvj2/GZyHrGjaH6V+lOtfD9a0VcaTK9pU3O/k/nJruyTH4dom Tzk/9nhY2z6UX0hg69gi/dyjz/bnEL7zKCM8X37Q4XKC8DmEgodyJZpuROfe5dwMuUXKyak+E398 KTpx8Zoy9Sv1JGXK22ufD/ZqYsJmDPWNYfVGIZugj6mUcni43+fjPDYlEApXc2aPbHEGkZRZaBSm wCKks7VxXmNGZ3b+tOuTDaCkbOfLWLJO+m7zrCZqNUQ+PjTl/WAVduJl+6btKNlX5OB/+DgezQyU Dqdq/Mpq4lS2EnWv2WAegs8n8bQUY/+RORsDmOabjLmcgWmWqYX/kB5PargFubxWB41muyr6nTDK SP3l1nZJys+NJ0n9s+N2s9J4WD4+o+RjEdg6n4h54qQ0DC5NgJ9I6NtEFgVeUt07XKoLLkDNGcTp NJPyTa3XfCOdz3mMdNXzFrZNvPa8nlNlatur67W6sGsJlQdssk/Yhuf0MfdmU/LUzeVnCRWomzoH W8X5dLKzEDoRwEwamVOXzFySMHcoGc1b8OaHFAmzXuEpK0Q6FHHOKvGU7Cid/xY4BCbcwxSrQGLq /2O/8uqGSbsIZLq/CP1U6r/JnuWA+RQWtl7dZe28UfCfHGdyTZ4rJPh88JnYPZLjSR031RHS/lnb 73LDjtxfbmcXO/M3GYeFduXUl8btVcbDVYZrCNmeAHXXrectagMrk7nTPZV3J/N8eT4O5hve5nmC JsaX5fiu1SZbXilnlkhc0s4Fei5ob3eyD+yhXsov2/92Myykl7uNznFTw70h7IUKzyvDzrXWFN6F dKN1UHeXo3v6W5qVcrbC8OQ8dB5Lo1fP9D2vG+b3o7QuMSzP+CrzTNtRJ4FM+DO1IMmB5Deu3vbw 20dDc3YcE1H5S9W6j5oAUNMVS/MPz5IeF1COGM8z6T5C+kv+k+SsxQaXVCh0e2qPWm6SXWJ95vtd rZ53LZ8YTxbps8p4uKhmXPQQBB49togSAJ4au+eOevP4WXPZ9okb22CJnuzRffX2LtHnpoiG/Yff 9iDskuH179pm+DNVqKWljvj8MAzkIq4kyz6byidC9/tuWWya45myo7lFhukv5880o1/AIdzD6u24 21FK6uFMkQpFgcPl4sPfm5p3TeFtu7taXDW3IrtcrdbbCKjm/zZkXrGhDxVb0PCnGavnTLs4zBdo 1U92TOw6evozi64rHOa5dn6HQX1V1Xqu015VLT3y2mM4+hmBan3STVbPwUeGf+lz8PlyaTt7uz8f P2cnLsxTf6jYOYo+7w2oXh65uMf9dAPiDfKkBp+NqDCzyFOwI80cxG5r/FniQJybMCF0DCattiNd QA/tl+5/9A8KLnY6u/jtj5GewV71/nPuP8MeqT+sBXbU4K8M2YZNx5NKbrX+Kfa725O+Zw2JcVtQ p5L/PRuFuq8msO1+i+nsAn+M8+NdOBkWxVVLo+X41E+i/LjwSJK5amat369QMuRh0decVH/7HYVu OTnThOkyWFV7/VpHol5Owtw4w5YL7jSmCWNu8yziF2N8+SznxKofE9N2nZppmK2aV8ELhzawOS1W mO8wGLU3uYvDacsp270r9rUgU3vSZJIdpfMiB/5DG+1SqvIrPSnkX3KK9+JEY0jaH5xZsv1XWNRN 22vqP1nOtDHAuIc54s0m7lxv3Jxt47DFZ8cNcT06aZdl/S5Zh9BfJM6156V2peXk2pVZsQ/C1h8P t98ogBpXIUA9D3lQr47OIAAENiFAT+afze9108RvovgKldB8z7s2fQV6EAECGxOghYCHWhPZuPmo DgSegIB/V1NtyUjtF3mCNlynIhFQr4/bjajXycLVIAACmxBAbLEJZlQCAksJ+PdZch/hWCr8Ka4D gacwE5QEAU4AsQX8AQRAAARAAARAYE0CiC3WpAlZIAACIAACIAACiC3gAyAAAiAAAiAAAmsSQGyx Jk3IAgEQAAEQAAEQQGwBHwABEAABEAABEFiTwB1jC/01zDiFafy5xDXb+Ziy7tVelnRzyedIbb7E BQkdJmbgmtzq46j1tt/YLrYnZD4zq4jf4ruxdWh4DlGeknRFf6hTaGnpje07q+aV/TEvn+eh5R8v 5ee9BJacluWV1T+HnygDbEHq6dlWo8BrE7hjbEEfcUt8DvJ2b/DTl6DXuBtW+0OmXkJwu/aKipqM 5O6YTcQy1V/lmh9/ULAai7nAfMkv5Huc1UaNcTe3Y9Iut6uXqpvBScQnnaWW+Cr6+0978m+SrugP tY1aVv4+/U7StbI/VjWZAoh9YzPYUE4+ldZRH6Pz/hnv8BXlDe6GT5/O3if+OVGuuyolUPg9CWz7 zW99G3GgVcI993lmf3ry+WV/t2l7/k1ffnOL85ax3NnqI8n23hVbN/9haS3BVqevi5Rit4Hxt8mp nNNL/zS5A/sL5Pby20z0DV2W8mL2u9ijb1GH8uN7dz69eFb/rvckmD6yXTKfkh3lkjYyEu2V9YlQ R41K+49RfWwvZrFxDvKk/1h9bFn/V/6juYL/UAJQ/0uonMccokqxEfm3z20O7Qy3RR/4je4/Jpcs Zdpewx8ku8j2ZTEXdVn/VXTBD5P9jrkIC+GmQ8fkW/JT/8ngTNq9rj/GX+fPfqneWyWkxgu66f7G VWUGjWyrzDqK/hc5DC56NwJqvNw2tiDHjXMZxC4+useYZA38BusvDoOIuR+wGCWqIBoOim7JxgnM 3c0F/EELn5VBFdKtCU5jxglz5tSxFBtivcn2RgkRotgrkJgdVnJ6TkaWuXthQn89Rod76qxd8lVM OWj56fa64S4SKfmD5D/WfCl7RfMorJJkvWRobot0mUhInPAiSvLiJKnGT5iPK4pTajg5yge527La ZnUrH/6SscVq/pDqR5J9pfZK5U0bk/4W9TvHMCdH6O9JjKv1x9PJBwspL4krj33G/zZtPnPjyLa8 +eyZLYpLyt0GJd+HwOaxxcjXJze5sdPHBcKvk+cwluIqStLFg/aqsXXUb2387sN45yNRg4SenKk3 0d74nuJFRjULFQXHzeu5UmzBJ0PiJ3f+jF8UzyXH+oR8G/ZNZEr+IPmPISVjTAy+KtxMtyWcv8Iu aX/jQxEXLvp/mAicjmJV/p8fBNPzFr6zca8dzwYX+MMUY217c+NDOrbQDwpWt/Tkh20I03/W3Pxm LvRrr03pXSdu2gzNhbFFsFnyGYY/y5WqjXJvRoB86I77LarXoFqbYJ0ekHa78WS+Dyl452+u2HPU tjr9NY4KAjm7VIipLlpWb/Cf6gpyFxwOjck3fzw2h+X5Pmr8ray9q7ZykbC19KyVU1teNa479Be1 j2DY9ztnxiVyFoEqvWjYq6Qy9jaViKBGcnZtM/yZym7/143OD8NAQ6orGYbQ5G6w9nDozmdsuSg1 2ruW2za26Lpdf/ROORzdziKJfnugTmA2E+mx21+qBH34H9jllC8xOu3DEVXmcjGi1A7p2f2A5/7z 6AX/GXYqTznpczH3EXMMw6UruJsU17tQ/gTfWnKs4GL9aY+EYJdV+9dUH6Fe0X+WqSNw6E7dcByG /dCRu2aPnF2Yv52Pn732N/GQOI/OjxxdsqN5Y2C2RyyAtpY/1LZ3Sb10y6QhRu1zDmZcIieBaa3+ eL5cWjfgKCfJvFmktaAmRf3R+YM+7w2uXh659Nld1PGLNaQG2wy1wC1wyVsQ2Ha/hZ569IdxUDUD MXXsaNHYXEE7M+O1bW4gP5+ZOGnj/FDJ/MQszYt2nQ/k2ap1ek4y8cJLmANL1FvUXmqJ30hlWqX+ dJfObLkQ5k7H7yPMk+DG4VtfRH3iKmZnbeNepot73dPtFeyYrpdxYP4j2Uu2i15DcbomNkOwVbns 7GfKLlow97eUbSfz2xJnfj5SVNTf/FDiCqPdyav7Q64f1bY3VT5rX+N4EwwlcubZrdQfuTubAWq2 askfAovJHlUz3PZugmQyPs9u93qzBQA0d0KAHOgHxRY/f/78+/fvr1+/HjyYovj6s/m9zUubNP+x VVUPTv111Luh/9Bc9eVwU8+8ofKvY2G0BARA4CEI0ETotmsii1rtv9milhoLViAWVRJdRDX253P/ Mf601/WSIWF7Ajf1H/sBov1A7nKDRQX2faOtnH97A6FGEACB1yPwTPMWr0cfLQIBEAABEACBFyPw HPMWLwYdzQEBEAABEACB1ybwBGsir20AtA4EQAAEQAAEXowAYosXMyiaAwIgAAIgAAJ3JoDY4s4G QPUgAAIgAAIg8GIEEFu8mEHRHBAAARAAARC4MwHEFmsaIP58nZJMnyVQ3zxUb7NGH9GTzldpY4Tc 4NXHKi1etbB+//MjfJuV2jm176s2vqpdT+eHq9ox4SdV9F69MPi8uoWF9iG2WNPw9I280Rc42oP6 uN30y//S+Yw29GXe0Tf8Sch8ToE127eprGl7N61effAw8ZnI231h5d7tLaX7An447aeljU+US/jJ FdJe71LweT2bFrVow9jCPN18fNjkBf6rQ0ZP/yA/eVj03z6iaylbiG9W+nz42tBoqsD/8HE8midS PZEg1zvlZ2t0t3grUau0yjyEaDEtvT+HtkVRxsWTYKdT7bLPl3ttgeIUEuz7TUeeriXwN1Mnsn2N 4Q12PonDn3dNLdwo6fbW2EvxFP1BgM3kc8iyfav9KuG3efsKmo75s7YqjEyvjJ8bIVTeNTA7C7aS H2YDaEEf2e5p/xTKJ+3IUJVy4+PGzMTh8497Uj/KjSdCPyq6KaHQaxDYNJ+Ifsp2SSLU//tk4CGv sXnKd5+459mu1VPk3Pnv08mneubJAcK/tQ7+g/hSvekvxOdzl2vNpazEVeeTtSdzZPPW8NozPH0K AknbOLN3yFjA69ImcvkGyDDGLjn7UnfhOWJCKoqQECFOmZFsb529VBKQtD8IGQB0S2yzTJYP3S53 TInV+pXkz1RDVQ70NP+RB7JU6DluZnbGtPTUFeSnSBSp9cNcBoaUPpL+qmyUesiaL+8nUztGZ+a5 zfjJuHXPPu7J/ci3zPR+13kq+SAfx8sRUEPK1rGFG8LMiGBv1omZfT9+RcnNfNwwSnoWzidzAmmv T9whcvWmrW1uACY8UTrM3XuMlNqYoyq2SNyb5XZF0dEk/dWk3nEDbQEpxvKc3ejMYscoqZI/n9En ca+tt1c6uZbUk0dAYrdJ2HGJX0n+XBNb5GLccGMMQ32e27wbRLykGLfKD/OxxTgQF/WX/XP85BfF Q6n+WMNtzk8SscWTj3tSP0r331o+L3dnRYOo/224JpKZ52l3u/gmzUIHNiicmn1YE0mep5xRlHch 3AGTdVJt9nyu3rS6ux0lqh7OTX/aUV7tyyXK4f4wM1n17bq96m3rqC+vq7pdRf6wXJ/4yjK/kvx5 LS26Q38ZaI1q2Pe7g02/U81tJWXWqrdWTm151dx7cHuacW/TfrSS80HMnQk8RmzRdN2uH71JYcDw BX71t7uXp8+fL5e2s+Pp+fjZu1cz2kPXDP5FjePR74kU65XMQhecKabo/kf/oOBip7PEb3VQWKOr UuvD+UXe6nYJTRjJcRUTz8uRvfgyEJG5LHLn/jPslfnDyNlW0QLtuE3T9la2S/KHjHX74BzD0TuQ cEG9X0n+rCsotm+Wf3s4NEc6Lj15vT0quc04dLGecr+u7DKS/oJ/Lqq3gpuqtsZPxNY+ybh3635U 6Q0o/hwEtlsT8RObbuMwzXyac+ZRTv/TH/bxLnlSKmxmrZ2ItuuC8OiHNtoVIVWRntdSFZgp28ma YmRwo//4RQPXVul8di4tXBQ2K5g63RYW9W+2lWTMk1vAq5bcCML14HzCQ/d07SlrX5qfN+YwR6g0 yGn73uxwYNs43K2RrYWl/UQCJ/qDvCzCfFBHjmbxa9ybo0V+26gCv8o528S+OW9Irv25C9SPk00R qaoTL8LMT+de7YdyFTl9SoYC3uiS9obNGm7tsozbaEnW+0mqZS8x7iX7UW48iZb+snzmHQ4lno8A DYnvmAeVnpA/m9+3e5nwOYLKbbWk5/WXRw6/2tanUFsdAfhnHS+UvoLAe+VB9e/sqS0ZczP4V1DF pWMCRL4/n3t63TH+FNVrkIJfvYYdX7UV8M9XteyDt+sd5y0e3CRQDwRAAARAAASel8B7zVs8r52g OQiAAAiAAAg8EYEHeU/kiYhBVRAAARAAARAAgRwBxBbwDxAAARAAARAAgTUJILZYkyZkgQAIgAAI gAAIILaAD4AACIAACIAACKxJ4LljC/pOZPJrniz55cwHLPMsJflrWuAKWTyP6BViqi+9Tb3aaPFL qo/G/0b63IZntVnLL1iVQ8LuU014jy7O4FveoIUlV+Uwr4Ml5b42nLhAedJMWtb5alACBFYhsN13 OTf7ttgkxdS6NVflq1xQdZX8SdaqBRXOXDKfm2q1OoXUU6vJjwRVcV5RhQ15rqj1TUWV2l3K+ZdU 7qHsuxY+IdHyWuKVnHtxW7MNkHVvAhScbDpv4R8+1GQD+0MFSebZzRzs4dWcpfLudxuV++KjeQsl 9UN9qCkSZUvbsv6vTHCWlq/P9ufwEJV7RjAiPj7U4zg9TNiL3BXsQSw0ISs/XPFxjNJSXDw6po7A k5ocQH/QEXJ8CI9Bcnsr603TZnpymJJ9TTIV6yVHM9Ohn+Oq2ltlR613Uh8737B3Gs0+MubrXYOn 1F8yfNJ+JfBMcljQr7k+ix+0Rf4ZzqKfpP2qbvyR6q0ff6J+OvKr4Cdh5GCjZzyVK/eLhN3r+8Uq z7cQ8poENp63iJ48QlpjCpbjFBM8Lar5NL1LUsxTBqSfY5LzFnHa38LYPCm/8FoVOOoP7rtkH+r/ wzTD6eRzZIySPyTlKwZRCguLS9cQ/s2SiaR58hYpmeP0s4lwV3rOrqpXCKMnOVnmctYHVrzl6mGr ur0VdmR5OkbpV7yFjbVnk7NIz4W1dsw9lqT6i8RH8qtcf0y1tLJfz9hdat2UcIZ/0r5SuyS/UppU jj9pv6ocf3zWIquA6xc6SYrzsmTamHFF6X4h2R3zFvd+4H+R+tUte+PYQvdUn4eMd5JR6MZTUXfS kF0RW/C5vrj7ZYy5QmzhQiLT6BBbyLmmUmOTOGkcrYn4dsXCNVnPM0oixHOASRzm5/CL6k2JHxli EhSO+ccFwq+L2rtWbBE8tcyvbsjTMJ6qIfIR/CrH08bMky5Z06/n7F4VW0j8E5yldkl+JfGUY83M vTnoM+snUa+OTDp6DpkUjK1fa3fdrgX94kXuh2jGegS2XhMxN7lDfxkoyfmw73cHm9aj3e3GD9DT zJPXzhvp1NNq/vx4bFzF18pcev2wV0lNrCUTI8BSufa6HE8etDX7dRN8bGJHz4Zqu3N7rzTT7OVr 8ayVU1v+rv16lmIoUNau4FcVoueLrjT+tK3z+vkqy9o7LwclQKCewKb7LYx6re5kx+OlP/jM1V23 65NvfNS3SL6iO3XDkfY9DF2oeJH8y8Vs1VYrlosWi8+XS9vZuOp8/OxHO7+n8kd8ZisWeUYbNagJ /vacA1He3ko7quJHijPNMRzHIMZKtWS4weyvoOMYLl3W3vJ2LXIT8aLyeit5ijVKciS/WlJvRb+u tftC/LP9yMkV/WpZxYJ9y8cf0udinoNszxgubrhozv2n2yOlho6dzl8uHbV2N3Ik/zQ7NBaNeMtA 4qqnJrD5moidUw2T9G4eRi8l+sM8Xo9nL9xD93RWw6+zxNbguzOsvNGp5DSQKD9WKivKT0dQKS2P ppHNOTrB5irarrMnrSqh8kg+52N+4DV4VGzLxZQnTXgmTs7MhE30WVCvWEW0RKPHSTWDJfPn4Npo f0Oyabn2CpzTizfjTm53z5jTbkuN+vf8losb8pT6i5nrTpt+6leGQEl/ZGttVf06tnDn7V7kJo74 jP8zJxL70WgTkwFEbuWMWD3+zIwPfJtDvtel1kzNKGKGC6Np7+Y+g7DJgkut3SVuzmYl4+d6c+uQ 9JwEyDvfLA8qrUVcDkiw/tTRsFeedrV/Nr9hzdew5uO04oZ+dfvx54bKP46FoMnDE3ijPKj+DdBz /4FJvYf3zJyC/nU7tWXFLiw9dYOg/EMQuKlf3Xj8Ye+TolM8hDdBiXebt4DFQQAEQAAEQAAEbkng jeYtbokRskEABEAABEAABAKBO7wnAvwgAAIgAAIgAAIvTACxxQsbF00DARAAARAAgTsQQGxxB+io EgRAAARAAARemABiixc2LpoGAiAAAiAAAncggNjiDtBRJQiAAAiAAAi8MAHEFi9sXDQNBEAABEAA BO5AALHFHaCjShAAARAAARB4YQKILV7YuGgaCIAACIAACNyBAGKLO0BHlSAAAiAAAiDwwgQQW7yw cdE0EAABEAABELgDAcQWd4COKkEABEAABEDghQkgtnhh46JpIAACIAACIHAHAogt7gAdVYIACIAA CIDACxNAbPHCxkXTQAAEQAAEQOAOBBBb3AE6qgQBEAABEACBFyaA2OKFjYumgQAIgAAIgMAdCCC2 uAN0VAkCIAACIAACL0wAscULGxdNAwEQAAEQAIE7EEBscQfoqBIEQAAEQAAEXpgAYosXNi6aBgIg AAIgAAJ3IIDYohr6sP9hj4/j+fixH0QJpiSVohJU0l9VXeWqF3CtxoJD2zLNWlUbCAMBEAABEHg5 Aogt6kxKN999c/rWx1c3fPQqbpCO7vR96tpmOFL40R6+vr/6tu2/vw51Va5aWgVDpP+pm0pV0Y9v W7LEqppAGAiAAAiAwKsSQGxRY9nz8chuzCpc+J6/CXdds49nAcwchjkXZhHM2Y8PPdmxH+wUQm7+ IMyFuJkUP00itUrpnAosaF7lc+gKWlODC2VBAARAAATekgBiixqzX85Nu6u5QJf93+nUHPXCiD3o Bk9TGOYPmtuwN3tz9nxW0yInCkfU/3/1l0FeczHBzej4OljJdXpS03bnsGyTm46pE4zSIAACIAAC 70YAscUqFg/7FNwMQjTf0B264fNYVFPb22mFjuY7Zo4F8xaSxPPlcqYoptfBCi32FGo7pyF+BwEQ AAEQeEMCiC1qjL6jzRN/Uheo2Yf4iBce2sPvbtgnL62pf1R2zXkLEt32ds6jPXS0SQRTF1eYBpeC AAiAwDsTQGxRY/32cNj15r0PfajpisIXKujSpo92ftJMgZKRf9WkRrtrylKY0je9a8twbrqwtGIm ZQrbeY0SuBYEQAAEQOAlCCC2qDMjTVDQ2yF+4UN45SKEHvvh3H+Y11C7E5vLaP/XNfSD2ns5dH1H hT72+w967eTc+02eJohRb6bIWy7qtHdbR0miUkvv/PQSDl+0y8O0bN9QJOQDKLXjo+1pLgMHCIAA CIAACBQQ+PHPP//8/Pnz79+/v379KiiPIm9HgF5fGbqvhVtE344WGgwCIAAC706AnlAxb/HuTjDT /vNxOHeHZe+eAC0IgAAIgMBbEkBs8ZZmL2+0+EGMchEoCQIgAAIg8F4EEFu8l73RWhAAARAAARC4 NQHEFrcmDPkgAAIgAAIg8F4EEFu8l73RWhAAARAAARC4NQHEFrcmDPkgAAIgAAIg8F4EEFu8l73R WhAAARAAARC4NQHEFrcmDPkgAAIgAAIg8F4EEFu8l73RWhAAARAAARC4NQHEFrcmDPkgAAIgAAIg 8F4EEFu8l73RWhAAARAAARC4NQHEFrcmDPkgAAIgAAIg8F4EEFu8l73RWhAAARAAARC4NQHEFrcm DPkgAAIgAAIg8F4EEFu8l73RWhAAARAAARC4NQHEFrcmDPkgAAIgAAIg8F4EEFu8l73RWhAAARAA ARC4NQHEFrcmDPkgAAIgAAIg8F4EEFu8l73RWhAAARAAARC4NQHEFrcmDPkgAAIgAAIg8F4EEFu8 l73RWhAAARAAARC4NQHEFrcmDPkgAAIgAAIg8F4EEFu8l73RWhAAARAAARC4NQHEFtWEh/0Pe3wc z8eP/SBKoF9dUf//dE11jdtcYNp1lX4OjWIS/j0R7E6EQrriUTPLOccX6utiaXTqqnZtYwDUAgIg AAKvQgCxRZ0l6S61b07f+vjqho9+JlJo+y8qeeqaTl/Ut3XVbVZaBUnULlL0mqM7ffUttVSJMf/X nU6dPtuc+6ONwobh0lKpr4MuRBz7tu1Pu4FHXbWcmda2ft4OOvV1uBX6bHh5DU1cCwIgAALPSgCx RY3lzscjuwG3Bxs3SCKowOiWZk/YCQ37LO3/0tMcH8cjnxhxsvkcyOQRf6RAar5k5sFdteXKwCIP sjv1l0EFF4rhgYcw5z/D7nDout3wxwVqlZxVzazNfCbJn57MW/hpEQs8NoaeZ4o5h0moDzr0LIuW 3p/DDEtmEqvGz1AWBEAABJ6bAGKLGvtdzk27q7lAKEt38lPX9r/NszT9pZ72vw50f+/bc9/ziRF7 tzp+Dp2KZOx8yXQFgddkgp7RcbsH91Ej+Z22ZbgOh+Z4PA/HftdFsyMUWqgTOriwoqo5D/sPz+fU 7MMt3qBQ8ybxYaZpLM1+oOklw0fiTFFEqGB3tkGQlq5nauxx0/BsBceDCBAAARDYhABii1Uwh/up 21gx9wTbnbrBLxLshy48yqtlBKNUe/htHvbPx+F87t3mDbUQcz7L2zz4M3zY77HZhgPxTkvRQ/+x v/TRDXjYu1hD/TxHTTAWrbK4QE2ts0xDidF1xLNxaijILvKQObeHAylvaJK19IIODhAAARAAgTQB xBY1nrFrG/9sHV0X7qflT7DmOV49K9MiQdgNwB/1XR3tbtf28TxE7gn5vvMWMlCKmk6ju/JAoRPb Aar+pEPkXGOs4rJE15bNcWYmppmRuWWp4spREARAAARekABiixqjmqfXsOdQ3RUXPmpTtWbqYogm LWiOov8Mb0zY9QK1YMDrrdH5+rLm3r+8nUyDLl4OadSEA4+Z7J6MWs4Kj5sEopdPjrM7bGmWKGwd PYZLRc5H2mHBt+36cEQ17kJrOOq4zh2uNxQkgAAIgMCjEPjnn3/++++/f//9d7pCjzNJAnztfjpf Md7lEK30T4rbFyrCRfTKRNeFzQHmNRNzxHsGZmuus954GoRNk+ifuCKiZL8WoZTzCzuhPVpIYsHC v0xjOoWtq4pztBHVRDCqCdPZHceNqdHSMcc5Bz9UsrJR6kyI0iAAAiDwGARoAP5BscXPnz///v37 69evR4l33kcP2oN4OfBdlvR83PzebNtlEWh6F4K2MT6WTkWKlxaifZqfjwa9VHeUAwEQAIGHI0Az 3VgTuY9V7B6D/UBbNP1qA93Fe7Nn83GW89X2xo5tB7kPrlvU6t8pVW+A3OzrF7fQHDJBAARA4MEJ YN7iwQ0E9UAABEAABEDgmQhg3uKZrAVdQQAEQAAEQOApCGBN5CnMBCVBAARAAARA4GkIILZ4GlNB URAAARAAARB4CgKILZ7CTFASBEAABEAABJ6GAGKLpzEVFAUBEAABEACBpyCA2OIpzAQlQQAEQAAE QOBpCCC2eBpTQVEQAAEQAAEQeAoCiC2ewkxQEgRAAARAAASehgBii6cxFRQFARAAARAAgacggNji KcwEJUEABEAABEDgaQggtngaU0FREAABEAABEHgKAogtnsJMUBIEQAAEQAAEnoYAYounMRUUBQEQ AAEQAIGnIIDY4inMBCVBAARAAARA4GkIILZ4GlNBURAAARAAARB4CgKILZ7CTFASBEAABEAABJ6G AGKLpzEVFAUBEAABEACBpyCA2OIpzAQlQQAEQAAEQOBpCCC2eBpTQVEQAAEQAAEQeAoCiC2ewkxQ EgRAAARAAASehgBii6cxFRQFARAAARAAgacgsGlscT5+/BgfH8dzY87vh6uJDXsjXokK/zb/UhXZ w50IhfTvo+qdAH3p8aNEPbqEVXN1c64WsLE+mlgWgLJ0CcirW762AO+6m9r33v5sKB4/bKND/6XO woisDdvIs96UE57mU63O7Phz634UhppVhsHRMJcY96oR4QIQqCbwzz///Pfff//+++/37Y+vvm37 L6rn1DXdSdXnTnzTT+bMlUckx1dDZwmMq+DUtS2vTatFJ7Vq9qBLffn46isVDJev1OJqfW5arzdo tVrFF9xU/7wW3oGLlb224P392Xci3RSuD+8j17Yzfb3qlLMWCeNGrGqVSmuNP1WV2sLaq5ZcOHtN ftybvRwFQGApAbrfbjpv0R6+vg7qLu+P6MTFT2uwR1s+1zGZWqiIpLpTfxnUzMj5eGwOFDn44/xn 2B0OXbcb/rgIX5U5qQhIH6Q2EXZ/petMPtfa56G9nU0JzyT6h/4cHldCg8X2+sIfx2OYHzDI6LnS XWclpZ+zpXpt6fjxdI42m4SKpyKCHcNDPp+xih79ZfvyeSP76JzhJrnCVL458/GhrbIfbDWqCeYH g1cfRZMUCQ5ZnqH8Bx3j2bJSl76xP3s1jseh63h3sb+oCSjWR8I0Bp8CzHCQ7M7OXzXBxaYCRlYU +afGn7p+7adbjPOwfiqZVan50Z/Pvfe4QD5M8gYSUn8X3UbyE7nfSXzS50XO6fEq7SelTo9yT0Vg y3kLPiswmqXQEbadOeBPh/w5WJWZC/BNpO6PIJHq01MT5tmGP/u6f7OHpNEkRnHsNn2u1frYto5+ TT5/S+0lMUGKJ2UUM1GPIXPqONjkc3b6uT9u8uzcgDaFm+chBZxdNH73i2r8ZDZqXFEQw+07mTcK xWZ14+ZK8/RWcdX4x9Zogmui/5SnxME4m9fE68wlqMof25/ZDGN4xu5ORnE2y8cmIM3cRmiXwEHw c+1JVrB262V8VEc4+WlQ7oUSf2n8Mc0u79e5fioNI6l5C9Gvsv19XINx69S4J40zGT6RYbxdBM4S h9rxvHjoRcHHIqBuSY8TW/C5zRATjAO1mZWT0RxyFFuYm7DuFeH+xOZRwz9XjS0S7dJukLhHjiIj 1XZ9dTz6jEc6WduK2CJmMrpzpMcsdtarMIomElPNXFupvXo4lPpKRWwxy9OZnMcWo+AsF6tNmscb x32M8eTzX/PLgPf1Zx0mREoaojo6Z+GFaMfYzz0dqfzIk4PbTycNQ6Sd7l9xFawNaf5pzs4Fk7FF erxifpvsfQmvnsYWWb8aha25W4qVMxn3cvaS/FM4n+QsjVdZP3mseyO0uY4AjRKbrolUT+i0u934 HpNfmsjXQE9cp9PXgRcaaJ2E7QhTf9Kxa5vhT7W2119Q1l4qdX1VUwmHQ3PU+13VolG8dFVTXduW a1fW3pra47JL5Nfon9VM4Mlvc81+8ZqIiTvv4c/6SbihdcJuONrt11nOCQ7VdpkGYflxYNh/DJ2b WJHDjCv5zzjmjfppfXeY+EmOv+SfyfMZzmzy2I9X1XavbyuueBgCjx1bNLQLoi9a9C4EOl46HoZL 9Hxs92S0h0NUr4o+rlr9Tat3uZgNHkG80N6WNogM/j0XWgIvbK5QbFqvLtid1N1i2A9dtB8lIYT0 uZg4xByEsXPRyLn/dHsIzsfPfpdarPcXSvYdnR/xF/RPKLrAf5j+TUNbcXL65zikefp3LqyyV4aJ t/bn7O2Rgoa97RVZzgm/Esqr08G5h2MfXKzK48+XS+scUjlhELMy/5FWa/XTvF9VoTCFx34i2kvi kz4vcRY5LOiPC1qLSx6DwMZrItIUmu0CtADgd1C6ddd4B0VuGtkLV4W8nK5zWzD0zHRiXs6/vGK0 sBPYvN65yev0nG1aH75NwfpAJD7dXqY2veXi5tjH9YZXYcbelZwVTmyGCK/H5OfEUoY0c6+B93hR XkucrOBI9hX5h0bPmcWuPXEW3Ylbxc4Wf7Gpfq6/b4A4Jz9yp7FCfNtIUpks5Pv5c1BrtFnBorSz idGWiFw/nXDQa4KxXUyd0dS7juvk1bFM/+LdxTikMU2yUllOfb9O91PRzLE+rPOlJ1uk/p6SHySM xj3rpEkUJZ2RDxESZ94v2HglmuC6CXhc/XAEqMf9oNji58+ff//+/fXr12NEO9BihgBt8f5sfo/e uFmHGs1xXg43kez0u6HyayCg57M10d6e5xqNzsqgOaOhm3lLalaJF+Aw28ZJgQd39foGLbwCHBaC e+bL6L2n++zlfLgo6xkUCo8Uc5vnF7SmbodhdQVM/A2Ur1ZHuGBFwjfmuVaLi+Rc882SV+JQBItP jTywqxe25ZpiK/ama9TAtXchgHmLZ44MoTsIgAAIgAAIPB4Bmrd48L2cj8cMGoEACIAACIAACGQJ ILaAg4AACIAACIAACKxJALHFmjQhCwRAAARAAARAALEFfAAEQAAEQAAEQGBNAogt1qQJWSAAAiAA AiAAAhvHFlHWvMX0bX7RK79OWVA9qbvmV0EnNa4gn1jUfzf6fGzo9WP6z35bc7B/qq8ssn/veRlS 3vz0oZphfvJ/8pYN+/ATVeS/Z2ouqVe2wE7rFUnnj62Xv5ac+poTV2zWX1bRdisheiyK3XGF/riG 9lazhR8lrdUgwaFWxO3K29TEG6G4XTveUfLGsUXIvHXahY9Y58EfP8af21a52scftFtuvKl8L4vU vf5DUreVrz9PvuB75G3ffH839kPdXfPV04cLG/35xOb7pP6X/n36auiLhr37hDflWmlbdZKO03fz Tb/SnzsXoGhqFFjsGyWZ/vvqmo8+2IUuoVrKjwy3ciG1Jcm16HXw671rgZy12nvr/lKL9FHLm7wo 0bFKf5faW25fkwpuqyPBYauq5+uh7rghinl9UKKcwMaxhVLsTEkaDgf6svzwx4aj/LnKzGzY2QL9 Q38Osx3RTfSig1p1sNP+gZE9lFj5ey2al5flZ547gzYfx/CZ/WhGxoXZi+T7Vvl2ifprO3eHnpJ7 lJu8rmTX9BeasCCzNVQHH4vPf5rdgTIVsLRuuowKTfTRHlSEsSS5XNbuUz75FlXYKytoKkf024yc Sj9pUv4sil+pv6TlG00+PnQv2lPemWlXst0rngwI9vqgIzhq+nySj1LI/0C9zsw46F5WxScuzwcT ub9X15toV94ukjnD+MYmT0U+TZqnxIedL3wyqR2X0s2S9c/34rG+yXbZk7FrPPhMad1w/FSlN84n oj/pbz5oH+XRzuQ4TubU1k+WIYO6z2HNvyGoyrhP4+nyIS8zzyGeydk9zZLMEyNwHb4pI6X7/tko L3WV/Ch1NVVWoL/OwTCTFH30abav/nv0zUA6Q1GB/8/++vXddiReFT513/pxiv6yh/9317pTumTm mNabKZzkJvGR5Cywl5m3GAGV5GT8Nimn1k8kf67lVttf0vJ9L3I4fPMz/c6TVBcxf06el/iEPhX1 OnLIYCje3wU+vKdEyVBM+anda+vlEnh72bhX9JlE/bDumqYa5jMFpccZqV6BzwyHqYqLxqVUS+Vx UuJimsAHcA1TsHucrigz9haZAYWWElBB0NaxBXk1S6jlczstiC1CXijvT4m57BBPJMprcDX3/ige irCncwtVyo8oqGt5yyT9dRM81CJfSMYWTL4LEUxs8f1N6ySNDiBCbEErHPonraQKO/S/bhxbyHyE Zi+xV+oeI8qpji2q/ET254yZpVi8qr+k5es7mDG5cTjb/Jye0le/hfNJPr5erVa4j9byGeXJi8Um 7L6kXvEr51X3uVGPDm4m+k+qXonPHIex9ZeOSwkvkv1fcmm7JsKfWrJ2D5wnaRGLBkcUWoMAhRZb r4kMtGjvpsVoLk79ueJBKaHHD85LpuTrNaJcTEOnVurt2Fcv4aGvONFWDL3Nwh/KbmzXpzXjTp18 huNe9qqs99b+vJb8nByegLfZhwnq5PkiPiHx+1r6l7lsWb1Se8vqCKXalnrT+MjwSdW7LZ+CFhbZ dypHpYg/n8PQkm3X4dAc9XoZLRQf7IayAtVQZG0CG8cWw3CJJs37SwguLhe3gDpeALS/6KAkvzhI uzj6+jc7Fst3Cp0vl7azbnw+fvajbc3F8ttDR1snwtWEy4nNGX44n5Mj0XrOQo+psbDhYjdsmm2b dk9G2xx20Zsg9G5I4WpuStcJt2o+I38otFdqcIv8KnJE2W8ncqr9ZGN/Xuwwop5hQ5KRvbM3zPR5 iQ/ZvQlbv49Hf5ep5KOKh4uH47ijjttfX6/UXi25eBxQhc/9p9ubooaUnco3L/uPUK/AZwGHJeNS rf9L7te2B9p3S++m+bEka/fu1A1H2g80dOQ2OO5HYLs1kTCRZZbK/IyC/pP/2iuXCOtpYeohLHAY YOpv9yvbcsFpqiJedrI82y3uY//pbEd4LOD7lvmajqu17Tq1WMqnoN1PBfJTc4Yz+k+mdmfntEZr In6zheZjd13QakjrdmBoA4U//bYMbUe9YqL/M3/SuokvwB6mzIzOzKJJpPnE7tNJoZH8ZMNr7FVt d8FvRTnMvCV+YniO/XnGvlf3F3FBxPc6u1fBvq5lrJDUU1JeOi/y4T+00W6YOj7R0oG6X+stILLd K+vNKZP05xRrQ9cMI/qI9xa4k3ycydSb/inNQfasBeNSSljO/1Pl/b6T+G4x1y/49qjZ0RAFbkCA nPQHxRY/f/78+/fvr1+/7hfhoOblBOgheugSo2NGIn124rNpvg7LK1125b3qXaYtrnpMAvQ2wGfz +/qXw2tbd696a/VEeZrh/rgctvcQkPcEkAf1+Z3hfDxe+gWbSs49+3bWJhhofYR/7mKTOlHJ6xDw 70CqrU0brqPfq97XsdyGLfFvRp/7yWeRNlQDVWHeAj4AAiAAAiAAAiCwJgHMW6xJ8/Fl2a90+891 3/sfj08MGoIACIAACCwgsPF7Igs0xCWrETDvdDzOf6s1DIJAAARAAAQeiQBii0eyBnQBARAAARAA gecngNji+W2IFoAACIAACIDAIxFAbPFI1oAuIAACIAACIPD8BB4ituD5JG+PVL+mlE2OZ0uMvq55 e81uXcOKnFlSxJC3lucmHKXETJa/TXvn7evrpaL1X3Et0jrd3jGg8M3SDfkU6Y9CIAACIHANgYeI LdqD/cDfNS0pvpa+IjjzPQid8LNYnit4fLAXqqf6rMj58MWSztGnOYdP+lS5kZ/8iGCyfDXiogvm 7evFUNHplxJWsWO6vQSIY2OfMd6QTxFEFAIBEACBawjcIbYIj2gfdLhv5lMjLv4XloPCJTbTcw1h JsEUpTPuUdBdwh8NuXB2vjTDRdCH1ZyUr0/256CrqcK2x9VnfzZaFejpJ1fsfMNeTbjoY64Fgj7W UZKcJX3KnOt/lEvowovSh/GOOtZIf/tzUn5STcruOQ6V9vXFo3mLLDfRbwsQpdvbnb76KE+DlzTP p6BSFAEBEACBexHYOrag0dsnDD3tznzZYejtL/GAG1JGdEOYGThQ6opTRx9fI3Hqa+gnSqmqb+ef LB9pN7jbM8+/R0+Lc/dmffPvKdmNSW36FWpOy6ebaJyr3UyMHH7rfL9ulkT/s+1/q9utoGf6vJkP oAaaTObSDSn4kKCPKZDkLOlT6Jd/hsanbSSjzEY/vLxQRcLuModq+2pCLBmIUULmlvHbEkRSeymh 4zkOyoy0Aj4l1aIMCIAACNyJwHa5ymxClChJjrlZmlGeJ/dKzqsToSg3lbpRu7zmXsoYo75iVLIg uRetifC6rHpxwh5dFc9hlsicZZqlVlhMSiSTAl6SI8sX+chpZjhRXyotJ9suoYZoXckbwq2JuJaG i9PlRfVTuZFEP6m3r/eXsQvFMSJTL+23Mn6hvdFSkk6SZb2mks8N0gtBJAiAAAisQoBujVvPW0Th Ac0gZPdU0jP2PkxzpO7Io0iCHgPNzVu4pdXEb6ms5fXydztKrDycm/60o7y/l4vJMS3JqZdf0yK5 7MJ6Qyw12bVA0/3T1ZBM+ZFulXZfh0JeCgsc5/3WiJpvr0qa7Sd8Cspv0VDUAQIgAAJXE9g6tjjS Dgu+EGLutdKhht7OpiU6Hz/72Tc3um7XJ3b+q9NHvWaijuE4L0itiXy6vSCq6p3OxyzIt4IpjDAV 0MYIu+xCF5wppuj+R/+g4MJIkeXk5ddaO6GPIGLdekMlC/dF1tp9iX0zMBPc6vy21FDkibvDfNot s/ekZCGvtGKUAwEQAIHbEth4TSR+/8I+2Pn5b/W3mxs2k9VsarztOvXyhl3kiKnw1YhkFdGrIZ2+ w49nOEZzHbY6XU80cZ6Wr1denFJMHdUAczn9XCRnKj/DJzd/NdEnL0dsV6oOVlhavzIwLIpk+Yzy Sbvn9I+WLGbsy02VMFnKjlVwqF3p9k7WnryjZPkYhRIrbqvMXkIICIAACKxLgAasHxRb/Pz58+/f v79+/bptFAPpIAACIAACIAACr04AeVBf3cJoHwiAAAiAAAhsTmDr/RabNxAVggAIgAAIgAAIbEoA scWmuFEZCIAACIAACLw8AcQWL29iNBAEQAAEQAAENiWA2GJT3KgMBEAABEAABF6eAGKLlzcxGggC IAACIAACmxJAbLEpblQGAiAAAiAAAi9PALHFy5sYDQQBEAABEACBTQkgttgUNyoDARAAARAAgZcn gNji5U2MBoIACIAACIDApgQQW2yKG5WBAAiAAAiAwOsToHwi//d//4dkIq9vabQQBEAABEAABDYh 8P8DUu16K/x+eMQAAAAASUVORK5CYII= --_006_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=27729; creation-date="Wed, 06 Mar 2019 04:41:12 GMT"; modification-date="Wed, 06 Mar 2019 04:41:12 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAtoAAAGtCAIAAACnQ0SAAAAAAXNSR0IArs4c6QAAbAtJREFUeF7t nb+PK8uV33ueV9IuHoRn7SYzDgwKhqFoN7AVkBkTY0PekMwuNrp2vsDwLyAB5/ZEi5uR4WVowAEz MpA3kBP/gCHCwc4ku/KD8CCtpNX4nPrV1d1V3VXdTbJ/fIknaC5ZXXXO51RVnz5VXSdJ8AEBEAAB EAABEACBuxJ4oNbf39/vKgMaBwEQAAEQAAEQGC+Bh4eHr8arPTQHARAAARAAARDoBgG4I92wA6QA ARAAARAAgRETgDsyYuNDdRAAARAAARDoBgG4I92wA6QAARAAARAAgRETgDsyYuNDdRAAARAAARDo BgG4I92wA6QAARAAARAAgRETgDsyYuNDdRAAARAAARDoBgG4I92wA6QAARAAARAAgRETgDsyYuND dRAAARAAARDoBgG4I92wA6QAARAAARAAgRETgDsyYuNDdRAAARAAARDoBgG4I92wA6QAARAAARAA gRETgDsyYuNDdRAAARAAARDoBgG4I92wA6QAARAAARAAgRETgDsyYuNDdRAAARAAARDoBgG4I92w A6QAARAAARAAgRETgDviN/55+/DwsD2PuHcMTvVbmfRt/+Hh4cP+zQNQiOH/uXXs3F7nOvKtbBFH ky13Q8vECYfSIDBoAl1xR8T8HXb3F9NYm7OrblsIID+tzN1SUPsj5znfvcouXzojWnczKXvH5888 4Cq6FTfzlgdk49uiZbcqzdoQPVZeKj9bL3Yfp6LxAdvCM958vSlDwhjucb5cHFZPtzBkG50BdYDA gAh0wx15239aHRaLRSVYnnFm68picQUel1/e6XPa0GWbE//5/izn7maf6TNX9bojtRa7V/77y/LR VyVNjnzTEMXKS6oaDvsj+TaXy6GZkLe4WgC2OLRCt5bgwiStNi9u9qrXnDbrWZAnK8Qo6Qy1dHNf dN7SeNmcTGMDtkXUeDtvn1YHZbdMnyBANBOsZ3BIWuyFqAoEQgh0wR0Rzsjm9LKsEvhtv+WZX/gN N/scdYzDzE/2Y1Vrk1aEX/F2OSeLzSYhf+R8XG/oL/1xSuZ+CkxcsZjso7NTYSt21JCDuHy7V2Ex FeERUtGNIknoETUTqLLktYJBuSdi8YuKt2vxVOm0ZE4v4d6SH8EfUTYbfigP1ZAByNdUkYfpnEyx PprlvctnGfLT0assXrcWmUBXTmd5fUHekqHAIyaVz1+QG/qw32e7eqQtnHGXhraIMUXUjMBjyPuZ fqRHiPXWu9YW1RIKgwAIRBBQD+R3+j/x1MyPKeaPKkHsMEZV2YjfC9VKt0dELKxHe/5WRTHswIe3 oWIh92XiW/lJgyTOWrnkYrfbJJvdbrE5sUDiMc8pmUfGSoZpAcsuVgvu1kpwFwRRChvRdWQqG1CS Ndp9wxI9lccuIFtabNhwOT1dfayIwv6mvFfmfjU62ro5LJD5yqNbXnSDttJ0qRF8HbTwvbur54N7 Zbbw9JKmtgg3hdba3c+KQ8p6qEmDJN5KIuYRFAUBEKhBgO58d4+OnD/TMo1+vIzwoW5VdPOcXWDh x2H95C6e4tv6yCUjMUlyYKBiO8h0spxv1qvVdG6WldySPU6ogIg0ZGqcTOiWLUIC2fiOeR6vWhJr iUOY6d+OeyKtIhhVkkmDHKZzNlyt1Rn5dCyiHE26p9JNWuBy8XQUn26ZuEuTTjadeFcIs9Xmu7q7 0dvawmuKhqE51TOk28gdKzsMKmzWxBy4FgRAwEPgzu6ICCaru7u4udPM0PF9mQzSfpxqdwuAuH2y TyK3hjg/al2HPYrFZJK7pci9L+IjJZMr6lSlXP1Q0650fng2Fjd5s8fW7F9JHx55c59yBfjXF8s9 ux4Hh+KZB1y5/4NXR6RaYiOAvSmkQCZmCnhcPtP2AfJH2CeovEufL9pSwjLBt39LoqJupasJMbpc pWxR3pJeUuylETL5TKE2fImOXn8zULqTxlpjY+mEu44PCIDALQnc2R2xJxUd7k3v7/JRPcg9UQ9L rW3l8NpAhhWuuq4s70SVdzVmx6xYIr4jlkrGTklxzw1XYS0SpXdT6SbKDwcIjN9hjHMDDqkNVIjn c269n6VMb4z1b0oOY7OjQ44abwNN40/FcuJmeVhJwdwbNSRKfy0e3cTtXdfcaEZIvaVG1eiLPfK6 e0kbLQaaon5Totvn3Ff+rpFHW18cXAkCYyZQY5nnGpcUV+mtFW3ZYP6Gmt6L7MX6msK5947IG3Fx sV93mIp9Ht6NEFaHS3dPmC+Lq9mWUmaziPxObiURr+RYroXegZL5Kg3rZEgaHdLCvC1FR4GyVeS2 eIRwyFWgarCZ5tk7FvYzEms+2Q5RtqUnL4NlN+unwreV5s1Ad4BkPgVr5vc3OHXLmrNSXmevL24e cdvC4u/ZVyLs7MSuvnT3EufulVhbyPIBpigM1cKg0EpkRShUbW+Sqjmd4DIQAIEYAupWEnMJyo6N QMZL9O2NvA+UzE0jYodnkLRF7zjosqBCN8TYNhaPflftJdc0hUufGzEL6iooBAIjIUDuyJ0Xa8Yc lOqJ7pk3kCNeR76+epntFW3vtWiyh9WjOi3byHdH5W7QytW4VghOn+nmup4FrXg2aPCaveQKpijT VJ3U0uraXwOyuBQERkVgJM4X1KxJwL2wU7OyVi/zrEQ1bEPpG7g4ENNYKu8VKi8RJLe8FyNycNmr 9JLrmcKnF5uodKk0GAgKggAIRBAgp+uB/kdXjMr9grIgAAIgAAIgAALdIUCvrWCxpjvmgCQgAAIg AAIgMFICcEdGanioDQIgAAIgAALdIQB3pDu2gCQgAAIgAAIgMFICcEdGanioDQIgAAIgAALdIQB3 pDu2gCQgAAIgAAIgMFICcEdGanioDQIgAAIgAALdIQB3pDu2gCQgAAIgAAIgMFICcEdGanioDQIg AAIgAALdIQB3pDu2gCQgAAIgAAIgMFICcEdGanioDQIgAAIgAALdIQB3pDu2gCQgAAIgAAIgMFIC cEdGanioDQIgAAIgAALdIQB3pDu2gCQgAAIgAAIgMFICcEdGanioDQIgAAIgAALdIQB3pDu2gCQg AAIgAAIgMFICcEdGanioDQIgAAIgAALdIQB3pDu2gCQgAAIgAAIgMFICw3VH3vYfHrbnkZo1TG1G 9PBh/xZWun6pClPcSgxS4Lx9eOhGr6jsniTqNUxT2W59M9/pynoa1bvqTioOptkrderB8Bm7Iv13 R8TNLPNpaRYXt67MR3o3nonMlqNcglzFVT7TbYdw36bpvsl72wnnGnSyA071XueX2v/Tg6ilgRmP 8BoYxDyQfswozn6tVM4M+QAMVxrzzTlE1XAlLeLtjyt6QqD/7sjj8ss7f06bZLF75b++LB/boD99 FvW+7hbJ5iT+fJ566z1vn/ZL0Xq1BLJiI29JrW2oUVKHQNcSrQai3lAMgf5+wBtA6talakBQJ17P zN1Vf/m6O8+sEJQalTSQktVTle/dLTUrpXFySPR8kZmLhoyhkhMKgEAIgf67I6VaXvQTjDUNpk8q AY8pIQw5YnJpvCxEYm33Wlz7oWq2Tg6rJ/kclqrh1CIXKRKl6bsP+3OuYrVska1SXP20OiTrmWxN SMENZZstv6VYMlh8F5OkIEJGWrtSt4UKFbvl9VnMXJ6zuvXgWt4f7AfDzEOip4ZyCzHnqs90ctER OoknxhZldFzDwsIb7jNM55vkcLlkFXlcvuwW62N+RDzOl4vkfClZGrRjCFoG17AQzRl5y0mWdpLr cnCbtwqDgOAa8+6B5elDhT7p5+Ci7po1ooabVwuS96g6tT3crjEpVw0v/N5JAvqZvt//n0ZHpB4c 1dDPKelv9K1+TOES5m+/7lZ0JK1YPxWll8nm7AejCpx5eenfiYrvZJvMF5S6ObTgGpRg1jVCMFU6 r0tBt0wwSClgF3LIklGTyxrJjDy2KRxNikiRIerWTVRRpO6St5S7o5cE9IF8mMwOmbl7kVMLm46T gy261R/SSFqMLXKhPcuaxWGRsYBtDQfMnAzSKjl1DOZcR4xgrYq6h0UUSWcncU8PjTnoeUdP9KkW aXTEGiK+vloYZ+6B5bvcN7NVdDrrMt+sUdltc104Z3CvNSMn5X7fqiC9kwCNmWFHRzYnGZifTBby Ge7tuD+YUAM9VhWe7Gr7i2rN6JRwZKFm2GWxexHrTI+TaeljZJAWtmqbZ7l+xUJGL1U8Lp836ln3 fFzrqtygLpdDWoAfnc3TsDYFPxyWPSK7deNvdQ21TeS6kFBzf6hpMMHUVYNTC6GEskSQEro/JERS mjPGFv4mCsMiIcOamBg/mpcGMahiHT+bJafKDqXHG69mlq8Mps//maFZHBbRJN0srsYh9ZtThcMx uIT1D6zGvdpDnXzWJrOGt/e5rXmdSTlolKFQdwgM2x1xcc7669E35wrT8eYEXiT/3HjxprwhlxZ8 +1f3idl599qealTxeksLN+yNzP37Z9rq1de1UE5KuZHnJfmUXbiK0MVTw5W0uJotMqGnqg1FprC7 k/Ha5XSidnAZEBWVvu0/rRK5+0uFNiOM0F7RNjnYUoViaEWT8F7dDepXGiytsEQltyMwMndEPMp+ uvKrrfQk06YBTWjHVOrW4m2/JSdEhcGq7ideAZ2RmenHXbL/vKX6P5Z7IySrcFz4Q/KsF8t5blvx +fMqKXxpSePWjWMqpuKM7FWRpDBLcNiI4tBVQQEVNeApPG/ibA1OLVhUHWbahuwd0bIzSeMHBtuC rw6lw3abhW8ZKYdK27rJr6joKcUqeNgoH4Y6SekQiiUZioHDqO1xCOt6zlKFMV89sBz1FHq1g0ME 9ZgOJaQpzlxOZW8yKTcwBi69GYGRuSPJ9Fls8Ncv6NWdgXWwWu8uzbzIVxXBloXNbrUqGUSAXm0u VWWdWlC5aapZxYqRjNCm+1ZTIfh2p6pJlzDIHUjW61I/QnRZmgBPWoin1fSUekVWeL/cVXJbyK44 q5pTXsf4yVEvvoFJiwlyrczzYTvImPLT5VksgouPZXqrBqcWU7pMcthOXtMavC3a8f00DBFqC1Ft IB3GazpZ3cVGewWnhjtMopIvIHdsT3aGr5NOLMlADKL/NuaQrmXVJSkX5ewx7x9YLj7uPunsDjHU IzqUmg0KM5fHmq1Myje7aaKhaxF4oIrpgfpa1aPe2xEgD4Puk3opn2akKrcoRjSuvHLtP6ZCu2xW 8rq1jOa6q9piNBShKAiAQJcI0HPI2KIjXcLfsiyZNSJevV9MJm01wdHzqF2YMQ3zxsQWZY1puo9l r2qLPgKBzCAAAoMgAHdkEGZkJdIAtliGsVdKGugoV3Xa3RorxbEOjmhJ1gZq9uLS69miF+pDSBAA gUETwGLNoM0L5UAABEAABECg8wSwWNN5E0FAEAABEAABEBgBASzWjMDIUBEEQAAEQAAEuk0A7kin 7CN2BzQ4IlTtyGhUQ/tAytKANte4IG95IlHxEmTVy9XtM+AayzgEtujLvGMur2qj6vdAOeT7zXUx VmrhliImQ2xbegpJzIuzdRUWtVyhq7eqpQ3db6EraBHa51Bu6AT6745YmaXUaSL6Zuyevezyd7tt N59Gmtdwha7tt8UVGrtHlTE3xKvIJ3MRBJxZcpXW26q0b1qIQ051Vqq2IETXc7Uh75gSr2ehq2kR zRMXdI5A/90RlSwmTTP2XnYEE50YScdn6Aw+NQ5ruq4FhTKNpGpeQwMN42whGrq5vOLW0t4B+g1o 9fpSYIw23827epCE5GHza3jBU2I3tQhSFYW6TqD/7kgUYT6OI/hDfvyH/T6b4l1cXJ46XsZoVFjX Oh9RfSMeRdLjUNO1GXdE2JH+O7IG+9xQE2z25m0PphNb0JHM3RMDtx/WqqLjVlk71DWdXPJ2s0Ha Ra0aMo3lLVeWMt3FwqeFK6l9sZeITmbErA7KWG9NV2YoWEwS8fZ2Ntejj0NRN2cg3ztYMufWlpnT fmzOPEIbOnSQcfpxyxvDwUG9RIs8B746VSf7ryIzZ1cPb8075LklV48KtibloaKEMYHuuW/RyjEh unQr1SJ2PkH5ARIYmTvyuHxRR6BX3eekrQ+rFeUsFeFxnTKFxhQd8S0fJl6Xe5UAh/N0qEcMmRyc B7g6GVUlBTvPxO1FPF3Yebp1MMQdEZbJsGRasbNMBxNVg1MGodt6JeNEt8j4x63RibEZkHxSiisG Tsd8pQ9rpfMkmSKNdfHh9MaolHhE2ii1mwGZCbqT3aRcXDYxaVuYWpoASAghrrcTv5dP4T4tihz8 Fgqdb2wOAUsKh9VM6mxZ3sPBKYEvkO8YLHIM5EiGqqVdfz5dWBooPTneKW8MBy91pxYOkcXp6kf1 dCNu6mVZenzLPYGteYe8GMeFkRVuzUyyw0rDOLVwT4iuybNMi8q2UWAEBEbmjqh7ubj1ZB8OPbYu 5CB3po7PXyyzwdNQT+coTgInv477pI85maTroZWUyFDM9B1aaZ1yxWTuvlpEGrOgbZL+rOtat4QS 4JZRp9uIToIssgipHHri7lKawKYSgU+LYodq3Eu4S0Ydmatl4D4pNfZwqNQyW8Bh46YkPfd5p7wx HErGRWhPFXllpD/Cqa6fy/Id+UGGthZTQ4Q1m6f7LJkQw3WzAlV3288X2dlR/AoERueOKIbs59cN C7iyYdNtT9/X2jzBtBvpv6/Q70qqVBtQ5sfcasKVpIhKKB8uw421CBfMV/JKHJoL5n1Q0GFD+v9G 261qi0iDXsRM2RuZl6e6rt1GzQtDrUles/bBa7ZEl7kmxLja0hjwnUwZJy5KX4nAWN0RxlnrycCd DZtSwKcRaT03iqKfdTiXs76YOSs047k//XdgDSUy+HqUeFK5/zMKz1Cn0tCGSAcv16/4LcrterGc 5zLy8rdldwpPQnmOqRjL2ZwCU6anl1RrUWIhFdc5bzObJgp2466gH9NpzbBy74ipgBaUVJJmD4fm k46XpLtqGathJ1xpwcD3R/nlhxSDU94YDjXGhUNiThS8/7ylsV+2UNOcoqwhcMgnYlyYdcfy1mWa arXiXEtQ94TorypYi1rS4KLeE7CeMnr8p72sX1hq1i589g3JzCNEUXV7g0f+b2N0XUe2Zv28YK3k Zx8hrNcG1Q/5RX9ZcfrtYkdJ122J7Z/EPgl3DfbXqQw2rRw5oUlO2sh+kavRA7JKYxKjwkKZ7QSm rG0Khx7UrP2tp7QtnC1FWrxUtoxuumRAh7IkM1Usdicjcu4VX11cf03/pj/LJHMKltuYUWF9pww+ 3bLdUklWoQUpkGphBN6cMpZz2i2cQ0YuQ92thWdgmTFXPVj8Xd3VN7yjzTnknTVUjIFsC47CXhvb dzu75fyE6O8PxakvcnZB8WESoC6EnDWteJO8iY42lKndjWqbXOB29VYEQCXBBPilosnrfcL7wUKi YD8IqN2z6E39MBek7DAB5KxpyziZdR/erb6YTNqqG/W0SoD3+U0nuUWdVltAZaMhQMtdcbuIR0MG ioJAPIEx7x2Jp+W9YvpMb5Tyuzr84Vd+8bjUIt02qkoPr6BNPohbtYF01HXIN97a3LY+apxQHgSw WHOPPvCf/+09Wu1Jm//+v/VEUIgJAiAAAiDQGgEs1rSGEhWBAAiAAAiAAAjUJoDFmtrocCEIgAAI gAAIgEA7BOCOtMOxhVp+8fbwH/6W//sv3+VqO/8X+v4tIttOC9KgChDoAoHqdD1BUoqtHrUP0/Hl aqloOpN5p42yzbQIAnXdQi1Z87pCova7ERiGO+JJpHY3qtUNCw9D/bf9hSj/48f3//RvXv/qm+qL Y0uQo/PyD/K0sIDPd1sSLKJ8QJXeIr/bv/ytUr9JNUO81k75l6ZkJE1Dp3SuQN+AzX0se4e0/2W3 J3P/2EkACxn3cshlWZ0zKJ8NT+3xVtLkNMso101L+jLOdFPazkgV2lM7IzAEuTOBIbgjVvq690wi tTuz9TXP9+DZLyav/+nfkP9B/z3/uELQ6V9SsccbnUL9i1+d/+onu+SXx287im8kYslzs82BcnVe Blpsphd5ounxMt0sSsDxkac6UR21KhtT59xbeQPL3xdbLFSOR6sh19hUJ4JbB2XVUS6uGwhdev+6 2zC0iLMcSo+IQP/dEXEO+ElPaGmeTZHh+uzIpO7Ihs0nY+0dRd0dwRmL4SrOQUHdb3+1//m/OH36 06CjL779hw8yiJIPV4gYhvjvw89+J+WkiMv2Z7nyoth//Lvk55cnz0pQTsfz//pu+a+/nv802f9v VS0XMGJYzckWdYwnXUtKv9Qyv/3s/3z42XfkhInC/2cvHB368uE//PfVz5P1f8x872Ke2kczNrl7 HdbMPtdnk8Bnn9NZBT4SX32sLM+5yID6xZ22/Xb5v0RLdFT6YfUkRS7JS82n30zmE/ZHyBuhv8pm tVr5EvIVTp+fp/JAd/3xjc24CXY6uWgjuS1UkZ3bOSrF9LB31GsHhUpXd/IhICOF6SWZA/udHTVt rPJw/0gtHIjtPm00c3LgtrLjphSxY0Is66lHRd2m66LjncHjug9K94dA/90RmkntM8fslAiOTOre bNjr1X7JR61X5dWzk5jnYjHr2XGuEqGbVCqOnvAPvz38xfdLbw7WRd/86ReKoPz1v8jWQ/GVt8lG Blf+fPmz/ytv8PRZ/80vl/z9n++Sy2deA/r6WV7+FzoY85dfl3bO746/+NH8m+TxX/8o+dmv1J2F fJH1ZfrXKpbz5affkzWQ22HFeFTwhpyM7Z/9uYz6vP70l5+0q3T4m/954RgPrUYlqzNvjnn86b9i Of8i2aia/9WybJ2K06jT8zTl4pjwOeg6uckH+qc8Mvl1udepN+hwqqnKSa+f9EVSm2JaoSRJk3e9 7szDvfVML8MTwtt1p2331HuVKUAIa5/AXxVWEP7Imb2RKSVQ8ieUNufm1N5eIfSdzqeZVD8lYzOC j7C5DBWZceW2hbtS31LLYbWSESGrXh7eaeepEU6x54f0THf3tOMu6yETo4W7Ch3tYo1tOxU5pA91 3O05vbU/J497QvT31MNqL6xpTbTeSZn87m3yIg/jT5xJpCK6EYp2n0D/3ZEyxoVM6v5s2DqhfFWG J39Se7ptqUFLY9E/kb39fX6nanQv4fjKt6u1DCpQgOHbyz+oOhZ/9S/FTf17kx8n57+3whvFNszO WSvg8fazt/WPf8Bhm29+uNTrNW//+5eHxU8KK0rfHQ/f7Fa5GM/vjj/79vA3/12GTJ7+5tvD3/9W S6ZqIEdn8Yt/DN7IYuTWcO1E7j5rihRi+dCBSPX1VNjOmD7Z0fOp+4atM9nRca7mqDsKUUiPiBOb ueqNNup1Lnhczi+zy3xZGYqTbhn5dBx3qQg3+EWl+1hxwaapZnpokrejUyry0boOW0S2pKeHNDEi 96g01BpZHRcXFTzncbs7qrtsdKNFLXxVpCGItPty2WINnFlPZ2WkdMUFhawWSiZEpxzFidY/KZNo qml2pap872hyuKBrBPrvjuSSrHKMuvQM8ObZsJvZ8PHPvk5+/ttLs0rSaEfY7hNHa2LnrPxPBzzY mUgO/9N4OZn1mlCBv9mpsI2ovCIYE1qpt5zTmuoxcH7k9QzzvC9vuC/JJ2uVg3PHJjsZX7HSnNF9 T9/tMuduOtO2u+ptrFfzCug2IcYBiVc2j2ezGQhyVrAgWgy6j9GCje7dsWMzpjmnLWIquG3Ze087 HNyb0aq2DCXmMuQ5UNAQEKEocvzKUmK3BPH+dFpSBNU0ItB/d+RxvrTTzPPtpRBZNJnUY7NhF9lW J7WvsseP/2z3F383K7zNW3WZ9fs3P5j+/GLWQaov/NPvL0IcILmpRfso75uJXK/heMbhzawH6ea+ ni++lcsu1oeiMt+udmVv8ZzPl+SnP9QP6wFRnBL1KqzJfsJJP0/raviGS46HCm3wngnlvHL6EVXI vf5SnrY9W6+sSDyNNlv+cGifu8dXm98uwcE/9dhL8pHKRdedHfoGH16w2e5lBSFjM7wpsRNlLnbZ ltsivMp8yYzAAdXoNcNPuu9YfHnFT/Uod0d1lw1otVYRK5MWg6ysgwJdyf7zllY4/Qs12hTst/CH K14s53p0B/bU5pNypTIo0A8C/XdH+AUAfp/GlS5Gx3PprQG1ejKlDQiJ3ghYJypd0lqoxb+3/PTn u1/IIAT/J990FVs7eYFDxSekvyKXVMxeVLU59Otn8hX0mkj1kSTf/Onz4u9mVVtZxaLMD9P3d4TT wxtQaP/KX3+t14bSnbPTv7S1UFtZ+ctEb5vVqrEiKujyt7PkJ2b3CX09nRpF1BbXUIpczm1Ne8se WT5Ns6y3rD7tly8yni4WyWWuoe1kt1Ft8yN+2ke0R8GWTxMTGTfD2sia1hujhKesrNfsW03XT0Qg XeVHiltV4ZsnIzurq03kJ7Nxl7RolO+Y72MHfR/2j81wRHrjLgumjOmxhbNOqRy7BpJaKTN7eBtX 0l0D20GKRsm8TbghzV4lNznJj7ujusu6wURp4aoiFZfkXe7K3rOSl5NrlqzXSepduAUrmRBDe2rj STm8L6Fkpwk8kHQUvOu0jPWE4y1Wl/JAdb2Km141vpw15Gk9/f1j0MJNJ3LWZLsO+QX8EixWrpt2 fFzfLwJqk2qN/bz90hPSdoMActZ0ww6QolsEMq+9WkHubkkJaUDgmgR4Ka90E+s1G0fdoyQwgMWa UdoNSl+RQBpEF1H+qV7pu2KTqBoEOkNALgxlNnF3RjYIMmQCw12sGbLVoBsIgAAIgAAIDIcAFmuG Y0toAgIgAAIgAAL9JYDFmv7aDpKDAAiAAAiAwEAIwB0ZiCGhBgiAAAiAAAj0l8BQ3BFnJjTrS33Y QCa5uXVClTO9VH/NCslBAARAAARAoE8EhuCOsCvB28Dl+cc6aRp9a77kk5+M76EPJBbnoUk3hQ5Q lAn0xAcv2vepB0NWEAABEACBARAYgDsi017lfQg+F36nzt6kg1vpAMVs7nN5grXMgxZxLHaaj/vD /izehzNujjODuDv5vB2LKeYlz54snonnVLQ2gA4JFUAABEAABMZIYADuSC6LubRiPpOeI30CuzEy wcLj8kWdHB9y6LbIkE25UFYzkfJe5nv1ZRB3JrUnV2mqclnpWA5V4cr/bYV4OMOb9rr8GbnH2Ieh MwiAAAiAQO8J9N8diQhtSGvZKTB0TEW5AqeEs1pUJT1TRxXqlPfC+yHXRtfL6TFUTnpP8nmRAKyY PMOX/zvtZCrxW1lG7t73SCgAAiAAAiAwQgL9d0c4L6a6+1v242/VzVt8a4VQTDLr4h4RzgHLW0o+ 18hp6syR7U4+r5yf+ZEzemnnx5n/mxeUlJuTPR0UGblHOFihMgiAAAgMl0D/3RGVlTW/zDKd03KK divErf5ZJnGt+mQSllQV1r+X58h2JZ+nK9lXoUUfsdgjVpcWk4n4M83/7VnWmUwPq08qqXdOxOsk tQ/lgHIgAAIgAAIgUIfAANwR3nSRJk03GcSdmdTdiDK7Retlb3XnyHYnn7c3slJrMlWsO/83JWvX 2eA5kqKToyMjd52+jmtAAARAAAQ6SwA5azprGhaM/Jnt5FWtKiHhd6dtBeFAAARAAARqEkDOmprg bnVZdpsuLyNNJ0ErTrcSEO2AAAiAAAiAQBsEEB1pg+L16uCIyOqg6qf9qzii7XqsUTMIgAAIgMB9 CPBuBGqZDiK9T/toFQRAAARAAARAYPQEsFgz+i4AACAAAiAAAiDQAQJDeLOmAxghAgiAAAiAAAiA QH0CcEfqs8OVIAACIAACIAACrRCAO9IKRlQCAiAAAiAAAiBQnwDckfrscCUIgAAIgAAIgEArBOCO tIIRlYAACIAACIAACNQnAHekPjtcCQIgAAIgAAIg0AoBuCOtYEQlIAACIAACIAAC9QnAHanPDleC AAiAAAiAAAi0QgDuSCsYUQkIgAAIgAAIgEB9AnBH6rPDlSAAAiAAAiAAAq0QgDvSCkZUAgIgAAIg AAIgUJ8A3JH67HAlCIAACIAACIBAKwTgjrSCEZWAAAiAAAiAAAjUJwB3pD47XAkCIAACIAACINAK AbgjrWBEJSAAAiAAAiAAAvUJwB2pzw5XggAIgAAIgAAItEIA7kgrGFEJCIAACIAACIBAfQJwR+qz a/3K8/ZBfbbn1iu/c4VKt+Ep5uP6tv+gjPlh/3Zn+LdoPtX34WEcGt+CKtoAgRERgDvSFWPTdD5L Tu/ic0pmQ5rR+U61nbyeNl1hfX053vaf9stXtuXrLll9GoFD8rj8Ijuv0Pjz4Pzp6/cZtAACIycA d6QjHeD8eZXsPk6FNOfjOjnsj4N5puY71ZflY0dI30QMUllp/DhfLg6Xy01a7UYjl8thMZl0QxZI AQIg0BsCcEe6Yaq3yzmZTuiOLSMJp93IbmHdsMI1pHg77g+bufQzh/3RyzWz8+5lXM7nsO0K7UDg RgTgjtwIdFAztMHi6fJMkQQ8Wwbx6n6h8/ZpNT09j8EbSfRyzety/zSktcbu9zJICAKDIAB3pBtm fJxMk/WMNli8i1sX4t3dMEszKci75O1A43BGUlSPy+fNuJanmnUTXA0CICAIwB3pSEeYzjfJYjkX Gyze9tu1/rsj4kGMSAK8cjFGX0R3X2weiewwKA4CoycAd6QrXWD6zEFu8W7oE72UMaitn/It39k6 oQgQ/TGCSD7tTD4obYVJB6+y9Z6vXG8c1c7lrkwikAME+kzggYSnd/P6rAJkBwEQAAEQAAEQ6DEB empDdKTH9oPoIAACIAACIDAMAnBHhmFHaAECIAACIAACPSYAd6THxoPoIAACIAACIDAMAnBHhmFH aAECIAACIAACPSYAd6THxoPoIAACIAACIDAMAnBHhmFHaAECIAACIAACPSYAd6THxoPoIAACIAAC IDAMAnBHhmFHaAECIAACIAACPSYAd6THxoPoIAACIAACIDAMAnBHhmFHaAECIAACIAACPSYAd6TH xoPoIAACIAACIDAMAnBHhmFHaAECIAACIAACPSYAd6THxoPoIAACIAACIDAMAnBHhmFHaAECIAAC IAACPSYAd6THxoPoIAACIAACIDAMAnBHhmFHaAECIAACIAACPSYAd6THxoPoIAACIAACIDAMAnBH hmFHaAECIAACIAACPSYAd6THxoPoIAACIAACIDAMAnBHhmFHaAECIAACIAACPSYAd6THxoPoIAAC IAACIDAMAnBHhmFHaAECIAACIAACPSYAdyQ13nn78GH/1mNjRos+Oo3f9h8etudoTn2+ADbus/Ug OwiMiADckREZG6qCAAiAAAiAQDcJwB3ppl0gFQiAAAiAAAiMjMD7yD+vu0Xe4puTYGL/or6ib08b U3yxe9XwnN+6K7h7DX6N+6QFkw+1hVVOGU+ZLsZC7rIdrcFr415p4TWxQwuvjUc+v0F9EOgDAZqY H+h/JOrIHDC3urTKvp28flk+jobG6DSmvSNPl+f35+loTJzAxuOxNTQFgf4SeHh4wGJNf80HyUEA BEAABEBgIATgjgzEkFADBEAABEAABPpLAIs1/bUdJAcBEAABEACBIRDAYs0QrAgdQAAEQAAEQKDv BLBY03cLQn4QAAEQAAEQ6D0BuCO9NyEUAAEQAAEQAIG+E4A70ncLQn4QAAEQAAEQ6D0BuCOpCfmE hnHlM+l9941VgM4dGVlaInHuyKh69QhtHDsMUB4EOkkA7kgnzVJLqHrJ0updVUvAwItwPwkEhWIg AAIgMBwCcEeuasvr3evbyU1LtczOu5f0IFquVn2qwwgxMkSQeFy+LPdP936kJ4HNxy+L5KV/jwES 0O+UMfKGSG3UKiPL9GWZrW0uElCrUhSxpHJV98gAqCgCAiDQUQJwRzpqmFuI9bb/tJqerFPxz9sn +kLmNzhNV3dzCcgh2Z1nV77NlRDmOyC5aSYfUfmh8ovFebt/a9tgdNun8+wLmWf46/1SSdbeYfdc rTH9+3tJpoTps0nnpNI4tSeFgyH1UaXu6y5ZfWqfc9t2Q30gAAI1CcAdqQmu2WXpI6Z54uM1/r2O TVjPgdmnUf5BPC4+rQ7JeiYfT+2nxqN6qA94kjx/XiW7j2n6lrf9dr056ZvL9ONusT6qXQeFoEmJ DAXdxBezdXJYPeUep+0H8qzz8bh83qyvcJMPMtvbcX/Y2G5a+VXT5+fp/pj1R+xgkP47tfD2LCGV OVx82y/e6M9HMlH7aZWoWkop2MCvYH1SbdJ/iZ0rpkekJSzLl3udj8svSt3H+XJxuFyCLIhCIAAC /SMAd+T2NqOpmFL1yRjE65Ke/vSdbL2SD4L8HPhZOAJyMUWU5edkeSeiGVr/U1aS3p4Oq72oOa3B r97b5bxYzq18gZfLYTGZmAseJ9PkfCHZOO9c+uQsG/PJ4NJNPE9TulWT/ljf9sgf0rGY4q13Ot8c 8jf5G9kqB6K61el8qgxWUXa9EgGP9Yw6ABERePOrH2WOJLsNk4teRgpwOatlF93sck6mkyapIzPO q3BujJ8rlJXZl7WDSVE4SmSoonCJCoNVcRBO4nxEyQ/DbIdSIDAYAnBHbm5KnlZNoICCHOkT30Lt 4jCOQF42cfsq+1TWYF1MN92gW5CMFYQ9Oft1c0k9mdCN2RsjoF9vbhvRIN+cnR9/MIfuxkELNvou vXlOt+uo1Q+TArwi9nFYXeZmOa2lxQvqCh7Ulo9Q7vyIcJYMpnEEx9JP98mEHUwR3aACJrLHYTPZ rcs5yHXEsF54n26DVkEABJoRgDvSjF+9q02cQNxXSuZYEaCWaxw8G7cfpbflp/u/HQyv+cgcrJsK sby/z4/5Fad6VNu6ir1B56qACAmpT85odDemBRu+10Z/qqICuQrTuEPOXtENpxew5+d2dS0foarz kbchoh/sjVQGMdS2Ezu6V8KBfpolp7KB0kB5XAoCINANAnBHbm4HutsdQvfk+ZczvBGUYH3oHpS9 BbHvY/Zr8DZXubMk83Wm9qIMft1K7p18yzupB2er/tDoTbDCwQXFykPsTlpesNnurTaUR3Pe0vN/ 2ScmOmKvYLW4eMGhjeA+6dWFsCX7z9vt2d6QlJYWW5OEnyKiYoUtIx4OYlsxfJHgzouCINBbAnBH rm06sy5jtpxOaftAord1VuxnpEUAtV81/04lT/6qknp7CNh1yG7OoKd/fp9GtGQFY+yvs/tmizJ4 dRPBfKWKuhPZax90w8nFG8Q2icm1reOunzR+tcEHvePDMA560UN6NGK76uREu37iP5IO71iWPUjK MH1OLUQbjVpbvCBfwFSc2xwdLjo5rsl6nWQ2JCVmBzO/ECTl5Q5lOkO2RxUaI4ecmOqeU1E4XFSU BAEQ6ByBB5KIIqadk+seAlFI+DjvVkSYX0yYvKowOW8ppSm9Kmgejo4rpC2Frd3TwluuLHkl0aja T8lLewQr9bh/gVv26mIPzXTg28AYoY1vAxatgMA1CdBjEKIj1wTctO7spkrecBi0+TS0WXm8R73Y SmgbtcrJA1G66CbVUmcsF3Ekw97EOha9oScIgEAbBOCOtEHxWnWwv5Au6/Arvy3fouU6jHypuDMf efJVy5p2RrtBCiJXlq7QQQdJC0qBAAi4CGCxBv0CBEAABEAABEDgngSwWHNP+mgbBEAABEAABEBA EsBiDXoCCIAACIAACIDAnQnAHbmzAdA8CIAACIAACIAA3BH0ARAAARAAARAAgTsTgDuSGsDOwnpn s9yo+dFpzG+ABJ1pdiMD3KAZ2PgGkNEECIBAcwJwR5ozRA0gAAIgAAIgAAKNCMAdaYQPF4MACIAA CIAACLRDwGQpHekfr8WcIirhqP1LmoP0tDHcrfS1zm/dFVDCuPvW4Ne4T1pwdw0laZVT6JXpYizk LtvRGrw27pUWXhM7tPDaeKTzGtQGgT4RoIkZx6Bl9o6kCWLa8fQ6XssdMorcl8iVUuHcV6ny1mHj LlsHsoEACEgCOAYNPQEEQAAEQAAEQOD+BLB35P42gAQgAAIgAAIgMHICWKwZeQeA+iAAAiAAAiBw ZwJYrLmzAdA8CIAACIAACIAAEcBiDboBCIAACIAACIDAnQnAHbmzAdA8CIAACIAACIAA3BH0ARAA ARAAARAAgTsTgDuSGoBPaDjf2R5o/qoE6NyRD/u3qzaByu9MADa+swHQPAjUJAB3pCa4rlzmTgrn /tadTe22NXSF26DkYBOKD3ytQdkVyoDAqAjAHem3ud+O+2T3cZpTwv3t+bjePC8fg8peq4Z+076/ 9MbxyHgfj8sv2dPU7y8oJAABEACBOAJwR+J4daz0+fMqWc7zHobz27f9dr2Z5x2X5KY1dIxeT8VJ syd9KTiXPVUJYoMACIAA3JE+9wF3vMP5rTvckdy0hj6j7qPsdijFWsahNTvro3+wvsWSTx+tDZlB oO8E4I7014IU7zg7Fmqc31IQZOpYqLlpDf0l3S3J1zPtTVTsvJZrOOJzmq4+i23a5KLMzrtX/o6T 4m5OMsIi+pL4lj4IunTL4JAGBMZBAO5Ib+1802WW5ks9veXcOcHTxZrnwtpbVtg04jFbJ+eL45Ui /eXjZHpYPWErbOeMDYFAYDwE4I701dY3XWZpvtTTV8w9lvu8na2163LaKEUe58sFOx70eVpNVWyE fps+c1zkJfnEv+B99x6bHaKDQF8JwB3pp+WwUNNPu91Q6rfLOVlMJnKFZrtWLfOq3Ukv4RSiK7y8 Q2s4zkDKDUVHUyAAAiMkAHekl0bHQk0vzXYtoeWiDC3IyLiH3Ir6uHze6DjIZUn7RMRn+nF3NntP 0kCItZH1ab98wRs71zIV6gUBECgjoJ+Vxv7/FNBOl+W7DEPuQcxL6P6WlFqYPYrmktvW0B2WpLeD Rnfku74kmf7A3WBwPGDj6/citAACrRMgH+WB/kf1wl8jAvSEeJy/V20PBKoeE6D3Sj4lLyN+c4QA UPTjVRGgHj9LTgPr8qO3cY/HJ0QfMQGK1WKxZsT2h+qjI/C4fNklcicrL+/Qy71wv0fXCaAwCHST AKIj3bQLpAIBEAABEACBsRBAdGQsloaeIAACIAACINBlAlis6bJ1IBsIgAAIgAAIjIIA3JFRmBlK ggAIgAAIgECXCcAd6bJ1IBsIgAAIgAAIjIIA3JHUzPTa48hymY5OY85xO7IT0GHjUUzkUBIE+k8A 7kj/bQgNQAAEQAAEQKDnBOCO9NyAEB8EQAAEQAAEhkGg9dNee1YhH5Wd+6gj2O1f0lPZTXbUxD5h 2/mtu4L3e9fg17hPWnA3CyVplVOmVoejx1jIXbajNXht3CstvCZ2aOG1cc/mI4gLAmMkQBMzjkHL 7B3ZTvT52cPwNCu0oH0F49KYz0i/PA/sVPRyI8PGoxjKUBIEek4Ax6D13IAQHwRAAARAAAQGQQB7 RwZhRigBAiAAAiAAAn0mgMWaPlsPsoMACIAACIBA/wlgsab/NoQGIAACIAACINB/Alis6b8NoQEI gAAIgAAI9JwA3JGeGxDigwAIgAAIgED/CcAd6b8NoQEIgAAIgAAI9JwA3JGeGxDigwAIgAAIgED/ CcAd6b8NoQEIgAAIgAAI9JwA3JGeGxDigwAIgAAIgED/CcAd6b8NoQEIgAAIgAAI9JwA3JGeGxDi gwAIgAAIgED/CcAd6b8NoQEIgAAIgAAI9JwA3JGeGxDigwAIgAAIgED/CcAd6b8NoQEIgAAIgAAI 9JwA3JGeGxDigwAIgAAIgED/CcAd6b8NoQEIgAAIgAAI9JwA3JGeGxDigwAIgAAIgED/CcAd6b8N oQEIgAAIgAAI9JwA3JGeGxDigwAIgAAIgED/CcAd6b8NoQEIgAAIgAAI9JwA3JGeGxDigwAIgAAI gED/CcAd6b8NoQEIgAAIgAAI9JwA3JEOGvBt/+Fhe84Ldt4+fNi/5b91l3V/67rWVWcYEpJHfgqi cuv16w1rXZRyI4moQBUVAouPRThQC3Otwziy+iApBc2i0eN16e4VQRy6K353JKsHst5VGa39Q14V a6GN7mCGJDcnAHdE3i+sG1H1kAq72de25dtxn+w+TnPXn4/rzfPyMfetu6z729oCuS+cPr+/v7/u Fi1X662u2i41JXnbf1pNT6QMfb4UCFdV+rj8QtedNlXl8PtNCMT0kpiyTuGdbuxN1LxPI7ce8vfR Eq3ejQDcEYl+sUhWnwsBibuY5fx5lSznOb/jbb9db+Z5FyVxlvV8W1RG3Enjb8CVVK5Vb2XD9Qpc LofFZFK49rZaiJn+uWDgehrhqlsQOG+f9stX4cW+LvdPww5t3QIo2hg7Abgjqgcsn3fno2uBREXx VSBdPA89rQ7JepaP7ptIZnadIjDmbzqiMwriCXe4Iybub3M93RF3JUk/7PcyUnQWyxdi/UF8Lf+d Xc1wjh1PPDd9jrRXJKxvSxcqRKWzdXJYPRXXh45q0cheLPHYIi+xLGZVrG8pUVp45hBTB9Vf+vEt 94TSKTGRk0P6ZWFtKk+Xim7PWRj8r/TOawcK3TaWsUfFuc5068FQbK20l7i6v7NHWXRKHQzxgKDC lTQ8aUYoTh+V6lqNGajpMMythMaAdNs4ScoHiy2D8++mXb0SCAqMmgDcEW3+yXx53mb2ZtCQniUq iP+6O8/4ficemXmFYpON7tMcsp3IJyV+VPpU3OQR1s1okjs7Fmo+r6aOhRpnWXcNhdbdcdfDaj95 PW0Oq9nlmbQ8XC7iQvFvodquKojkrJeeI+X1vKyRzMxNn9RSGMsjA6JSWg9Z7BTiNIwgJM5KFm4L Ua9dsa43RgufV2b6TtVCjme5hyJfYXSUibbJS9ZEbg6ifyiMaWjMYyGqej07zqXhNmseH9OPu4W5 8/J9WAXt3DXYY6iKg3uEuDG4WivpJe7uX+xRriHvGbgmpkbXUO+mus6Xws6uqkEvO6A0mzX7HFYr OfEo5lRNFEi3jXkcFwZLhMZ+XyS4q1fxwO/jJgB3xNj/cfk8tRds3i7nhfEMHudLc3N29Biels2j OwVP9H2cikbF/G+3UOPp9up5L1Vcltuc5I2aMcTPuhSuMdEkjkXoGiaTBQeZGkW5F7sXsd3jcTJV 9ZbYotFY92nhqpTK5hFGtx1JRz+pc38TxvJwIFDcU7Mbb0t0M3rQrVMs7NE42Sh/xArauWtogYMT Q4wtIsDHDHlR7YU3nZM7XHeVLQ3xZCcNPd5IeTmVxIF02phqcQyWiEnO4y620NUjTISiQyYAd8Sy Lj34ORZsAs1vntzFw069+elGCzWBGrVZTAeTBBy9XUWGBd7nx5BVoBhp2rCFqz2nFjGCxZRtgY6T g3wif0k+ZdcCInSbzqU/wt6ItcspooYIDj4M12ktXDD2FETQUPRmcmSS6SS/0byiNt5DnahIVbt7 wj02DtcOJUHgDgTgjtjQ6eH/vNUP6+IRQ29vpbCFjkrbT+L6YlHWvUITvnfkZgs19fuZe+tsVX3i AdcfA+G5kxaI1MKQtzLzpFjRXIktqgQt/b1Ci8y1LOv+yLF7Mn/V3pFyqQLpFCsp58B3eboFqkBV jG7UkvTbyRtJlxDdNZRwkIGB4MhYFoNf3tBewrwKZf1D3oGXAoWJ3l2emR6E0UN0o/Ue7cNwBWX9 oFaHytrYWX2JxrJrsMvUvmSNBiIuHjQBvXw52v+315DFArd+qrQeWbIPmukP5vvM44316Ca+z17t Bm1LYUrY21Ssy5xlM7srKoyZfxhjgXVbqnL9T49irhqKL/5qEPa+AQddXg6q7n5pJap0znCVtggF 79Yt+zqvbiy3I6Kg3OZEtZXa312Drz+5dPD0kuxr2CkzM5vZYrks5O9Rrl7trMGoUeCQGWle43sx OFuT+y20ftV9qljWO+RdEnqbCtPNss9it9uoMWAb0/rbD7IoWaUt7YHj1thUsTnRn5KkZ1jESFY9 yFFirARo2D7Q/0j9QbtbvVCOHqh4u2dukYffbJi85t/FdZd1f9tc+WvV21wy1NBrAmoXZb11zY5r PmTdOo4e4vWUAC8ewx3pqfFuJjbckZuhHk1DfLde8zP3AH2RIes2mg4KRW9PAO7I7Zn3r0W4I/2z GSQGARAAgV4RgDvSK3NBWBAAARAAARAYIgFyR/BmzRANC51AAARAAARAoFcE4I70ylwQFgRAAARA AASGSADuSFes2ji9qFQk/JiTqyvekkZXl9PTQIdI3gsB2gUBEACBmxGAO3Iz1GhoqAR67ncN1SzQ CwRAoFcE4I70ylzVwkalyKmubsQlQHLExofqIAACNycAd+TmyP0NTicXnYw9m8JdZWivOlE7mwne tGNnMX9QudP4fLW9OMqaPlY6NSttu/lWZDw/Owo709fHJJR3teaTzImNC58darslczWnDvQWHFK+ LpJODDFJ7TvU0yAKCIAACHSNANyRDlmEErtQdtBcXnE+q1V+TklJ4hdWQyTOyp3kzDlTVEJ5eeK0 OeJ1vdovubXXXaJS8/AJI/I7bm26ejL358MqMH19RB50f2tFyUqMtJ4d51LgzXq7V2liFEdSbrlX qYS4udVUH0WvKbgS1XtI0tcyZ5rNLCapfYd6GkQBARAAga4RgDvSIYvo/N8JpUw1ecWT9UwFR+gc S5XxrL7MVgXFbOOU0kunqSffZr6xmgtMXx+TB93fWlGyEoUXu49T8TN5BjK56nF/OKyeJDSTt52/ 1Wnb09piE9XrGijXos4+V98WuBIEQAAEQMAQgDvS9c7QMJE63zjVzZmDA/n0N020d6avb1Jha9fG SNaQb2syoyIQAAEQGDUBuCMdNP/bfruWqcsjE787dKHM5WaFoipDCLcm1zv4heHterGcU7TB/XGn r4/Jgx7TWoyR3JKxW2aUM9XV5UtUkxSOL6m92FhibcyJ0QJlQQAEQGBcBOCOdMjeeomBN3DI3GL0 dgdtidCrNRW3NrlTk5Yn1PqO2Pkx/bg7m+sz2zWLinNrtGNErXJUhFKmz7zpRK2J6G2gj8sX9SVt ecnnI881GNVajJWckgmUWjnjJHj4OkmyCNoUs8SOMz0un42RqrYbxyiCsiAAAiAwHgLI6DtwW/O7 J5NXtUajdo+2uWIzcHyWekglOB5bQ1MQAIEbE0DOmhsDv31zbxcOkegP7R5NphPvAsztxUOLIAAC IAACIMAEsFgz7H6Qrp7wEgy/8itXgfABARAAARAAgQ4RwGJNh4wBUUAABEAABEBghASwWDNCo0Nl EAABEAABEOgcASzWdM4kEAgEQAAEQAAExkYA7sjYLA59QQAEQAAEQKBzBOCOdM4kEAgEQAAEQAAE xkYA7sjYLA59QQAEQAAEQKBzBOCOdM4kEAgEQAAEQAAExkYA7sjYLA59QQAEQAAEQKBzBOCOdM4k EAgEQAAEQAAExkYA7sjYLA59QQAEQAAEQKBzBOCOdM4kEAgEQAAEQAAExkYA7sjYLA59QQAEQAAE QKBzBOCOdM4kEAgEQAAEQAAExkYA7sjYLA59QQAEQAAEQKBzBOCOdM4kEAgEQAAEQAAExkYA7sjY LA59QQAEQAAEQKBzBOCOdM4kEAgEQAAEQAAExkYA7sjYLA59QQAEQAAEQKBzBOCOlJjkbf/hQXw+ 7N86Z7lAgViH7dldWOjXY90CEaAYCIAACIBA5wnAHREmOm+l3yE/+vb9uPzy/v5+2tzXikq2gk9h ZG7VoShzX+7LAa2DAAiAAAgMlwDcEW3bxe6VfA/xeZ52xeDCOZi8Fjwi/n6WnKS4X5aP9eQV7lbt q+u1iatAAARAAARAoEgA7kh0rzBLONlVHPvrNMJihV2yQQzxg28VxcjEDoPDX3g77pPda6jXtJgk xVUnI1gqg9DgaXVI1rPcGpVXi2h4uAAEQAAEQAAEHATgjmgoh9WTWqupWPyQSzjic5quPst9Geft 02oqoxUUyqBIi/AV3vbbswm6tBeGIG/kME2OamNLpVNzWM0uzyzZ6y7R8iZT/uZ1t7D6hFCMv9pk wy5X0gLjEQRAAARAAAQ0AbgjmkS6WFPlN6Sxgtk6OV8cu1wPl4uo9nEyZS/H5d8IdyA0vuHor+t9 8iK8n9fdeVYRZdmcZEOP8+XCKW/5eCjRAgMJBEAABEAABNogAHckluJ5O1vr8EG6p2M63+g1jhkF RLSfIZyO95fkk71DNrZFZ/nNs9oxQs6C2ydqpRlRyfW0aE9G1AQCIAACINBnAnBHIq33djkni8mE r6JFjLW6unw9g1dBaBEkE5gI2zviFo6jHOujenv3fFwvlvOgzaznz6ukqqjfu3FpEQkPxUEABEAA BEDASQDuSEnHkKsytCIj95WINZfH5fNGbTN5uiz13gv6dmr2nqRbXK0toE/75UuNN2CMCDL2opZ9 HpcvtEQjt7rQCzZVq0t6a6pVVG68Tfetpss904+0w0Ruo1GtNdcCgw8EQAAEQAAESgk80K+0nABK zQjQ3f2JtouqNRq6f/NbuA12hjSTBleDAAiAAAiAQI8I0AMwoiOt2OtyOaT1WOs5rVSOSkAABEAA BEBg4AQQHWnJwBwR0TtJ+E1ZhEZaAotqQAAEQAAEhk6A9wdgsWboVoZ+IAACIAACINBpAlis6bR5 IBwIgAAIgAAIjIQA9o6MxNBQEwRAAARAAAS6SwDuSHdtA8lAAARAAARAYCQE4I6MxNChaqaHjFTm 96NEPSrLTyZtjsolWJH5J1QeU846/cRuTuQ8VifCRdcpLqCKs7LmkiFmDmBxaeWRrJ40uAoEQAAE xkkA7sg47e7Wmm7EfGCKzASYzEo9CndZujXTASzZ1HwtELYba5brJ0AYnSNR5kJkFiXnzN1UsgDh UQQEQAAE+kkA7kg/7XYVqfkQ+d1HkW0vobPnk8P++EZH4dP5rdoxEf8QwQhnWZne5grvOGfOddG6 C2HSg2VzUubTM1PpD/uzOIzWxDtEXMOcukt/x8dZnJJdxTqoFARAAASGTADuyJCtG6cbH982nVD2 G7EAMjntFpyZmGIFr3Rs/Cc6If9t/2k1lUequMtGtVdYEynxBabPp419Sr5oSEQxOBCjMxrqIIYO b3CMZ7r6bJZyDqutTIPMCvHXIjdgGgSp40k5JYvigMIgAAIgAAJJAncEvSBLQC630PrExHxPt3e6 rT89UN4dk6tYhlCKZcNxWk6DXB4qjarIrMKvyz2n06kKYqS7OSj0YWUu1GmQuenWYjhRkoXjQUkQ AAEQGBUBuCOjMnepspzMdz3bTl7lrZqWIVTqYnnVYiGiJfJTUTYEakx0RNcnXBgKlGw5m6Hvc97O 1jpgQqGP23yCJLuNKGgFBEAABHpIAO5ID412LZGnc9q8uZzTcg0v2GzX6d+8w/XLF04jrAMTvrLh ssVFR9J6eZ0o/bBfZMU/WHL6XflRrESlQJOJ5WZVli4rkJWsUVW4GARAAARGSECGyvEBAbkVQ37U SyXyGx1sEP/I/JIpa18va9EXNmObfVNHt6/qLIqchkQ2u91CFbc3meSkscqr14rku0XmzRpVPhtq EfWWStZMaVwNAiAAAqMhQLcL5KwZof8JlUEABEAABECgQwSQs6ZDxoAoIAACIAACIDBaAtg7MlrT Q3EQAAEQAAEQ6AoBuCNdsQTkAAEQAAEQAIHREoA7MlrTQ3EQAAEQAAEQ6AoBuCNdsQTkAAEQAAEQ AIHREoA7MlrThypeljM3k9AmtMJcuXxeYPPvqrNXa7Qn6o6rN5fwt0YNNeRs5ZJCquJWavVU0jyz crvS3Uye9DS/6BzWN5OxXbSoDQSuRADuyJXA9rDawjGpJnPeFZWhI1TPMm2uPiVeHLreek7gK6oQ VfW1fITm9cbUEFM2Ck/fCqs0TqL7luR9JrXge/TNtpD35gTgjtwceWcb1Mekpsd/lU+wpIi4pLJU icYmFd9tqAhXp1G2muY13EZTtHITAvlMCjdpFI2AwDAJwB0Zpl3b1upCSX7FJ13p8Cyq2DGWsmUR We5pdaA8OaLm8lh3uqSTWW3JRXRKGjQl7Xboyw/7Pa/gZHUT2QHlh5LwqY+zBv7NEsJUbgumvhRV UnUHykaYbc8qbGkQStJfL8l2VHqkWjtIltaQ60plZR29xCJZHWyzRLOslH5r03XbzTDjjmU+jhrY aB/2Z92tKxZaHBaWdVrm9Pc9cbXV0zMgXMzc/aE4pkmG7V6osD1LebQQzho8HcpJ3T3ePMPNxbft GQj1jYTAaE6hhaJBBHKHo8t1E3nae+Hc9MLR61Qi5mB439HtJUe600/6mHg+tV21VpDMrWqYbla9 BZXzDWUO0Xc2mkHikNP+3fo7jqS7Xn2ivxunRdJl25LOUmzN00vsJrLNFWt3/u6uwN0af2tnMJBd wyOCne+gpLephUOTmMDuGlHQHG14mHn6g8McImvB5qRVMVZx1+DuUFVWsfi5h1uMiYPmHxQaJwHq y4iOjMTnbKbm5iRXOKrTzVEJjnbEbRcNEC59LqPHzDSzsH2l+9vKuou6nY/rxe6jULjy83bcH3QN mcLpEyM9QWeT/GUrpdZ0gEg8beuybZBc7F6WnBHRTjQYQLJSa3eBIkmmY4JBXsOp2khILpsJVJRU UGhNmOJZ6Gt9ykTQpXnN0b+ERwsyabWcOrLMmrHonL3P2R/cNeuOaivu6VHuDuWiTk1V9xI13KJM HEsH5cdFAO7IuOx9dW3VBpT5sXr9JUIW3jGYqB2v1i5XvjeopR7eENtoU0iENAFFaYfuWkeJspn3 XBdn4kl6K85NSQaoVLNINuFhqYnEvpz3l+RTZuUsogKPiM1rqKl73cuc/SGqMlcNng7lou4eb77h 1ju+UShR+HYE4I7cjvWYWuI57rSpGa8ogqIH1GQ6Ec+9589mV8Dbfmveymm0oTbXIMeA9sc3+YyY 7h1x2u9xvlyst3subH14h+5iMuFvSEiz+4T+WYwviYdWfzQpkGR13EqK5ybJv4TWEFNWPHp/ytMp Hwh81ySXU4YgYirgEND6eBadZGv2jsTU4BaMDaQtzNZcLOe5CEzIyLYDVKXlK/pDQFvlNbg7VIa6 u5e4h1tzvgEaocg4CMAdGYed29cyvxVV3lDtvW6zRC3xRDXurHf6cSfWgHiz3mTHK+b8eVw+T/W2 0MpgTG7rYdnexcflyy4RFT9dntNgjLsGmsdPqRSqWpJsoxYpni5LsfkmlXmjNFErWlyB+Srd0RtJ klvM1uum7iapaAbVEFV2SvwkysJm4YJ81u7Jp/1SrjIlMRVMnzXI7eTVxKRianAysy38tJqear5J RuQ1idKNs57+EDGI3DV4OpSbumu8eYZbY74RmqHosAk8kHoUIB22ktBumARogiV/Qa/607xKDlCz 13iHyQlagUALBDDcWoCIKrwE6IEF0RH0j94S4IUH87HWR3qrEAQHge4SwHDrrm0GIhmiIwMx5DjV 4IiI2ZlB2/c6tJl1nAaB1kMmgOE2ZOveWzdezsVizb2tgPZBAARAAARAYNQEsFgzavNDeRAAARAA ARDoCAHsHemIISAGCIAACIAACIyXANyR8do+SnPxPmD1WasdT/UaqIUgI16MDEwaH1NvFPYOFmYu 1R0hVPCq2qI6VFThUAlRDgRA4DYE4I7chjNaaUygC/ea5jI0ryEQZC7bGTmTaSY/l5PlzpkW2BiK gQAIgEBTAnBHmhIcyfXiKOnev7gSo4U4UzvwyKuYem/UYdSR4FYKwBJd+PRZOrNFf3pv5xsxRjMg AAItEoA70iLMnlfF6crF0arqI1Kw00nd5jk791DtyVfuSmpvn9ZqteGtIUfSn9TekfndYwWnFkLF vUjNnlmLMqGCVFifDB46tmppWCKTkT6lHZpQnlS7ThAjc6RESDe+iLT2bmb2t9yn9rqs1X+MxuYw d27Vmeqevj8qC1kVVHCQP2vrpYUDF99CEKAMCIBAuwTgjrTLs8+1UaoLkShEuyV0jxJ5YuRzdiER HCWPmZoHaut5+rDaT15FXvZk9Vm6N5RChE5PlZ9TYhK0+GooQBTBBzupvWyOj4ncL7kt/plOai/b 0uDRIjmsVjIuQAeMm9wzokErVx815pHBR0cHJ6RkgoOvBg8dd1eSCc/487o7F3Ll1O1+5nj1wNv1 eiXtWWDmkGy9kjZK+4NtNwuyLwWRo0MpmB4O6nxeFc2j1ujMeMVsuY/MoFOXKK4DARCIJQB3JJbY cMtzMqzLJXm7TDYJZSKjY05VFji3yu585UlSTGrvSXjOSds4zUrtfZHtZH4vpnhvxcTpEzkd1FaW kt5Hxy1FdeL3etJLN+d1uef8MpUWcTHzSVboD5ySfvMsU9LYH0+qe0eHkq6oimlRfMVK1ciZgtj7 MP4xt6bSB1EOokzZeqRwFQiAwHUIwB25Dtde1kruAc3zx0vycU7+iA6O+FTx5Ct3F3emTI+qoV9E z9vZWutciCsVVAlOKO9O/N4eGmERO+QRXHUbkrlS3fucsk+rZCdDHtkgFiW7L8TJ6DsdUqL/x8aY YKOiIAjclADckZvi7nZj9Hh6Pn6+TOaPk8n5eExKgyNaFXe+8oyiFSnTA2rg6qgW6ylYfdNC5vcY mxRl8NwuL2dNj1PSW4XcWpj1qwpheI+HWECjBbDPKytjT4wSFWU5+U/8J0Iy6mbJmsJvrMQ2s3dE NJtNde+WpLQ1TjF7nullJxFz8azQyBBLZSwongauAAEQiCcAdySe2ZCvOKzXCd3uHufL83qtb3xi WyAtOciYt5rnPfnKXXA8KdMjapC3qecNr+2kexSjMr/LxZO8Fh5vQtym+E4pGzQ3rKIMavtlrl4u p1YIni7LHQWd9MethVGs4qQTSlIv1rdYpsluU7cnmsUL1VzmpWDejhP4QpHVfoxkZqcKL6uksSNn qnu3ihWt6Y4huip7J4noubm9t3Xp4ToQAIGrEEDOmqtgRaUgAAIgAAIgAAKBBOhpAdGRQFYoBgIg AAIgAAIgcC0CcEeuRRb1ggAIgAAIgAAIBBKAOxIICsVAAARAAARAAASuRQDuyLXIol4QAAEQAAEQ AIFAAnBHAkGhGAiAAAiAAAiAwLUIwB25FlnUCwIgAAIgAAIgEEgA7kggKBQDARAAARAAARC4FgG4 I9cii3pBAARAAARAAAQCCcAdCQSFYiAAAiAAAiAAAtciAHfkWmRRLwiAAAiAAAiAQCABuCOBoFAM BEAABEAABEDgWgTgjlyLLOoFARAAARAAARAIJAB3JBAUioEACIAACIAACFyLANyRa5FFvSAAAiAA AiAAAoEE4I4EgkIxEAABEAABEACBaxGAO3ItsqgXBEAABEAABEAgkADckUBQKAYCIAACIAACIHAt AnBHrkUW9YIACIAACIAACAQSgDsSCArFQAAEQAAEQAAErkUA7si1yKJeEAABEAABEACBQALDdUfe 9h8etudADDHFztsH+SnUzk0+fNi/xdTW97KGxnVg9x3P3eWP6ZPCllcZM1kMZUOzfRmoxrIx2X6D nbD5Dcx4dz0hwNAI9N8dEfNt5tOmQ2DXruqdPr+/v7/uFu13hUAP6roaR6l13s7Ou1fiQZ/nadSl KFyTQMXttWat17sssFdfT4Ar1hxoC3Z59KyU+odZMPa/Uh9fuYd3GPJpk23Op1e0BaruP4H+uyOP yy/ibnjaJAt5Z/yyfGzHMDQrPK2mJ3m3DahXiNJa614drqhxJLe3yzmZTlqiHdk2igcRiOmTwtG+ s1d5cxlu0+BiM70cOWz6drxMN6WPMuQHzBIz6Uh73HzIn7dP+6V8znhd7p8QawkabCjUkED/3ZFS ABcdOrHGU/roUeH2n49rcnACp2fPEo71WGNEoKLbvRZMySDKPa0OyXomIz3RjyRcQ3qR+Rf98WF/ zrUmmAVzsIvqWL7UyxK4XN7C454SwMnBoYXTyEK1PS8waA3NlU7dLCEsaZ3fOoJiWWS2iVw29vZK q3AqhCVDaS8R5Wbr5LB6yq4XOvmmFrZ6fwots95oxMrY0dVT/RyKOpf16uLQdMuQ2LaovC26SCbk Ml8KK6w2MltpjzULFXtt4cBAXvtkPmF/hLwR+qt8zrocGk7qdPlikjjGfOiQf9tv15tn+VT3dtzT rHS8xrJ3czVRw/AI6Kf/fv9/Gh2ResjllI14zEh/o29VDEWUMH87dOcK5OXBP+YvoXZNDenf9BfN FyKSk72gtMWiEHmNrX+nNdkYrPojOLC4WguuwWIWKbAyi67AzcGphdcGLI2oZ3Mywrh1c1u7og/I viO1t3S39Xbb2N9rCn3Kw9fbS/JmzzZVUChnI/ewUHU4elSxp3o4eGePYieJlcE7CnNtuklaIK2J IL00Q8w/Yp1TRbktdBuyhdfdZnei/73qLuUd/EJiDT6jY3B7ZurLzAShU59pRhINa7Xftw9If3cC 1GeHHR3ZnGRsYzJZHC4X5eqbR0t6tpffuj+Xxk8pFF4x0Q5+qD1f9C7Xxe5FPHs8TqbWty45Ip4N px93yV5FhPfJ7qPZy6ExPM6XCykDP/IEcqAFmYWpi2soY+ZjmWqRhe7g4NXCWbd6hksl9OpGqFnj XBTH/a0dD8rYzZJBGdNv46K8TF3bwvxawrdOL6no1KLZwrAoecSqlCHt1FEPasEy0NjliGFlXIQM 7+2pWolkOt+Udl+3NUWYVA7YBp/H5fwyu8wDqhHrR2KRpP7W4sKYjxjyUkkOX20nr/devWtAHJf2 jcCw3RGXNbJPOSVLMTQPVrgKAcbOPNjV2VaiV415gqpaNyJnIVl9PrOzkSznFbNnMIcALSuKvO0/ rRK147V6D3CUFu6WnbrJSf4l+ZRZpXB+Szt019py6lGVXEd2xeQqCe8oSo3Z2MZNCcfxbdqal0PT it3XqwEwP9ZawoyX6QrWpAcbscOK+lrpEF5MJpa8QvHTZr1t7VW94CHPj2+r2eVZboTDDrH4XoQr ahEYmTsiHoY/hY3vx+XzJriwE754sAt4rNMXV8dKKmzMIq+P28+rqVr4zZY/f14pNyWCgyhKPo74 UA2HzTz2FRqOM6kdr1xBVUet0KLy8lIb8yRPLlHumT77Lc+/6tbAq+iqQRI93dZsbisxNuYbeeHu Es3XhPoMiEi+VQArfndz8F/UuFeLqtltPJWHNqpJij0RZd3XbU2OqZghkFG0aIsIuAzGbMrggVHc Fc49sdnHjPmIIS8870SDyo15sf8kemdbMyVw9UgIjMwdoVntdZfojYBVIWCaAk/TtLAcg/lNnNLd cH5LNzl6ulF7U0PGMC9UqPZqDniaOdfr/JSrRaAN+/qZPoIDFz0rJfi13qoYTXHkkFoi4M6h58lO LoyXfpxaVF1kfnfrZu1FpJcGdOjd+a10RGUc5LLUr3STFhqDdexMlI25cNqhzIvjcXyFt6bsITuf h6+7p7oxSg5ml2xZ73NzKLFOaK92ymAvVlL/Le183p6q1yX5bZHSGjzWtCvOTBpFWwT2UuEOO+XN vNPLAteJqSZmkTgd8xFDnt/kOSV6zNNrPvFjPpADioGAReCB/qYQNpgMhQDN6fyaoJk/aHZ7oqhr z+aTvBZdsA6/ZjLRNwfGWvtW0QVt6sswNA4ZfepjwZUgAAJNCNDz0NiiI01w9eBajkbb2zp7ILJD xE5qkY2bW+sj/WRcW+qhceDdqzg7p3Z3wIUg0B4BuCPtsbxvTSLUnd1jeV+BarXeXS0ely/WMl+9 VataSDp20UA4mFW68VqyYx0L4oAAFmvQB0AABEAABEAABO5JAIs196SPtkEABEAABEAABCQBLNag J4AACIAACIAACNyZwIDdEU8KDAIufqn5Ju2d7dVq8x3iQEv5wzNIh/i22m+6XZnYFRJx2k+ANp6E VAFXlhfxT1GNq26jgiuQrCkWg2rXpDUFwWVXJTAUd8SRQ0we52gO1WwRY+DgsGXKZjxrUZZsVWmT wxu83fVYmkvWvAZn0j9Hvr7MsRb2FO/Owne1ntq84ubMgmUQR/dWnyccXJ8ueL0pKlqUwAsCp77A 2lAMBDIEhuCO8BDh/fE6B1DlGRsxSdcb9Bd5/ridJq9SsgatiaCPyUxOhxhVRxtuxKGRUn2++GZ8 6c7M71TpAaAOzqIk8eZLPn3NeKjp+fdr1UvsrhOQjaDTRhHD7rojrdP6tyccSLbHEjWFErh7Kr9m ApSnlXUmKWUyuTShaRQlm/bSHCKapnXNcC3LCSz1cqRUTS9K06OKXKJGilQ666GsPLOpramdxdRN 19GSFlbrF9WcTc0AqtTCjl2VkCyEuEzFFp1yS4isqjljGvMogS2Fc4/C6hdLjuI3spJCqpsMRVuR qhrsyF65bs6Mq45uxy1mvjYpcO1cuCGj0Ym9SEfmQ97pc221FpG2sCOcJkN3dnJTLI1YWV4uab0y eNV3zDPFsZkFmcv8rGTOGzMwYa7dJd091e5qRZ1z80PGGCeHiaS02amqOPVZ+Z3VXFfaV20lTEFn J8nPRv7s6iEdFmW6T0B1ru4LWiph+WgOmap5jnbk3vbmQS93gPLCFkpbIlm/2R5EWkI4KapG++8i EVOVnCB4gqlMzO4SrfKiVBp7PtF/O4V0a2FP3QFTcrFIZiqsuKN6jFkpWcYUhmh2EvYKX9JR7C4n 7tr5WdzdJ10jwd1Kvkr17/wdMuc+VXvXatUi301s/BYdq1enLUfbwimVl3r2B08n8Q7ucHfE2Xds vhmNHROMYyT5Zzr36Hf3X6Gcw0KuASvKqh/yPck95IoPcpZrUz3paBVT0Z2dRDjOtSru+f1stOKT O9L/xZrmWaY4A+5Bp7WgqPfBykEenAc9sdbeK5ZJOIfH/ijy31Dq3d1Hk5GumAc9Jn29cC45bC8y cU5CY2OZcuHZ3H3Vu2ooSdueKl9DXjoadWNyBVKem6oEzEVjBvGV3cGfvj5C8nTnRrabFauIyAfP J8RGfawcRmZVIzypPUumSZpmS+joXp1NpRdqC7KQGRZRSurCJZ0kfHC7Wnb3HZn/UeaxMqM7wphe HZ1D0y2D00Jl8PQo4tXF6GUu73TmbDGdJilBUprIsthJhBLOTKC1ugEu6gOB/rsjPMtZ/kNN6MG5 t731q50i7NtWJb2ihJkJZwjl+Wo5pxTepVOF2RJQXrPIDzqjrCpyQqFZOJuvPAhM82zunhqukLY9 SKHqQi7J2LVR9+w2D+18239aJWqPkx219ggZ2ifpRuVwxHLJZu0s8Ublwq2n/aT21QawSnS3l7jV cMrL+R/ZH8mO7lBjenn5hub9mUVMZ+ftbF1YzozqIig8ZAL9d0dUPtMmb5LE5N7mztA4Zbp8hNpS xnqn+5/mQY9JX8/30IXybkTWl0pPp9S1qsjmztcqL5DnmHxVmXzwbi34fqmCRLQHt1BDQbhiMneu dyvSLPM+3joauyWjutKd0dq3LElfH5pm3kp0w1nbLQ2LNUT0SZmA+JMCoWvlJPEWHXaEwkJRVeHG TMWmtcn0wB62+ORS0gfOn25bUK9OK87UFEi9eSfxyO8dm5zy+Hgmb8SM7ghjVsHKDKzELYPTQhUD tqpd9btz6quYztKquWuphyQer6VtiscrGWbiPdmRAcBAdVCsewQGsFiVedZ07xGUjyf5h1Ltqrsq cC8D5/Y/Vi+2e5f2s8u7YgFVfexKfd/7dhHIKqrEcnNwUShdS1dt0UYVa/XZqGE9uDm1MM1tTtmt FJ4200rs/TS6ufJNL15jOiWzv0xhWnhyfAuSVfEV22ptiR26RVmjSg27oxdIZaWt6jtkHas11x7m tAZ794H5O84WmTHr2RhcNuQz0prrSwZ3off5Jo3MKQI2NXs/hqrNacxsNysdtN7O4JkfHBYyVYid ZeXbMvySpYIUZqmAbWdWN98ZGZydxOpl1JB758wA7lxQwRCgiRw5a+7kHtIaKr+Vm4bLkef8TpYo Nks7PHgDjrJNwVKdkROCgEBHCGCQdMQQPRYDOWvuZTyxtBAYPL+XjONtN7M31Aowj5cINAeBEgKY ztA9WiEwgL0jrXC4XSViazmfT1W14fV2IqGlLIHp82mj3z6BqdA7QMBPANMZekd7BLBY0x5L1AQC IAACIAACIBBPAIs18cxwBQiAAAiAAAiAQNsEsFjTNlHUBwIgAAIgAAIgEEkA7kgksKjijROIdy2B ZpQ8DVKuCnDVOQCjjOEqHKVP49buUcGtSDbXzWMLc4xn8WQh8VPlgUMNumFzpUpr6F3vK7HFlVGh +lEQgDuizHyVqaF/CcQH3em7e2Nqjr27ujUcWeK044AzbJsjrFFDd6nXUMa6JE1mQA5f6vF12hbN NMbVXSAAd6QLVoAMOQLCj8OrRy30iyGTFHfH6BwrLUAdRRXpYe7r2Q0ClaNgCiXLCfTfHSFH/sN+ z2HbD/szx/hVkN9+KMv/zS5/6vaLRwE+hli/3Fkx+KxHB1OSDzHbi9aNAB7wfHXaQPZfrksWk8RV b5qKqlxaHwY6VV1Jmw14O+s1ZUMOazY1mIPffTIwtHMhAOyKCKdGzjyt8dnwqRZlkXtRKQlkMiVa Mf6LrsOO+4fyZZO5OoTrS7cWXt2srIy2jQuteXXzxNatZI9aY78Mzl5siWAxKyaR9I4sq6i92uLp 6w4ZjAS53u9LZHlk+1tDMx2vugdaKLLTg8hLWRzcZT2qILC7p4tijt7npuMZsG5btHjf4+QTFUnB nIMlSouY4daibqiqewT6fU6tPpBZHD8sThuXh297ToH2nTbsPsq9iMZOey0OiZYPEe4c2fLyfJpu 699VrcogtWzCKmsfqV5xvLrvMGwnB2e9tsZV8lpELL1LZDAH5ecg5RqyOVglU/4FyK5OnTeEXgQw JrQOzvbng8/VLETLH4/t7iVuLTy6uW3sbM3VyYyUOZIWMiuFu0cG98xgd530b28/LO8z6WWevm6S MjiOIM8b1CmDc2haswWfzW4qcurmH9zFHuVFZnINpNdUU7cUck9cbls0ntFtm9k9JjcPadtUDJYq LSKms8aaoYLOEqA7Xf+jI+zeqUTUIeecOvN0R7iI/nzl7kTqjqrjMnLTrU7GozkxlszIfa185c56 oxJ9i3TwYZnaJBhTmgLvFYszlenga+Z1LtYbw9edzN3fS9xahMoQnTo+3/3ojNnUQNyjUmiVfFVd 7qT2nFeSQ09hYf30kZ7ibZbdin09YmiK3JZOGZxDU3Ows9h7dON++rLk1Nv1s2fqGhJOCni5aL1c 1J10nBOXV94obO7COlaczWVRKOsdLMFaxAy3FvRCFd0lMAx3JIKvL093RBWNi0Zk5Pa1da185Y3r bQwnpgKOI6tZc0Y5eFvcRtAFDl2QwW0NZ1J7sZPj/SX5lFtPK1bxtuf8wpzRsu1NquEyeLuZU7eY Ttm0rIeOb+K6mrym4sph5eqocVp0t6s3tSaujyEwbHdEBRNo9svnp87m6Y547GklX3lwRm7blJS2 PVnO1SNaMaF8idX9GJIMB2ce9KhE35z0fX8UEZz9B7N3hEUrkSGmv2bKUqoMckJU8DFg42tgSnr5 kP1pz2pUftzJ3Jv3ErcM3tTxnGo+JDokqv0s0raTTT6vDpu5CL1FfNxJ7XUFfNek4Ls0t/gUAwqc E2g64Z4sRHC0nfb1CMFM0aIMobWU61asJZC6fSHndymFXk4nO3GVyCuDE5WvQYeS8ZbzDJYILWKG W2NxUUGXCQzXHeFbvty4SNlZTV5rez8YRSEtx5+XUETx8gMvaKo7TVW5yswzcoOW2UFpBbLpuX69 Lp+WdLexgqb6ljt9fjXCVsw5bgyZLaApB2e9aQaX7YQX2cs+j8sXJRhBl0vjfENymsJTj7RQurO4 ZEKlerUpKu2m5dA0S+fpCL6kXNohTNeJ6iVuEG4ZnK15dHOS5GrPM7lZs15EiUVIU/qY1Rlr5+LT fimXNuSnMLLoi4Wyw3ays3tUsa97uoN7ZPllCJyDPbr578XUs4N6VGI2UROc8jCem4574oqVNxBD 1NB0d9QYLWKGWzMNcHW3CSBnzZ3sQzNnxaLsnQTrUbM0RZPXo1/1BNEemW5kovKbNZPXgADeyLhA XRAwBOgBabjRkU7bGRm52zAPB4TNhzZpJovJpI16UQcIgAAIgMCtCcAduTVxEVCuXOa5tVS9bC9d RgLSXhoQQoMACIBAGiChv2gvIIiAAAiAAAiAAAiAwF0IYLHmLtjRKAiAAAiAAAiAQIYAFmvQIUAA BEAABEAABO5MYKTuSPpG4PVfzL+zhUXz5+0vHx6+VcdNdEGgejK8/erDAylC//2/8lNB3vb/TxT7 5cP2u3pN3fSq87dK2g+/CjrsJH3rM+wQ1JsqE9eYnc8o7kpfaTG2nemHxjHW26GIWkDg9gRG6Y6c t3zigjw+q/LIwWCbtD+xBjdtCvJt+LY3YHnjr57o1R23iUv0m/2n309PP3p/p//+uXWuhQfT5vtc 8vlr+XPqoJCPkt71f7P/IP0b8Z/tDRgXwfJphFeX8XIy1Rb9JOk/pRbJNJdCm37Dop4CByMfeDkV aYzGkfW46cASR7WaQ3DiBxWuAAEQuAmBwBnwJrLcqhF+JVQdCnmrJu/dzvSZbuHfxJ6/WS31+dun /cNGnXbmLS6cpK9eQ2+3vnr+6XJ4aPQmr3RQ3v9kl/z+0/43ppmNcnF+9P7lh/LwLhZ49r57la6P 9mnO384SWcP3N+vfSmficfnPVRn6/vWPFsmDPG1UfL7bPv3TdMNH+2iX6Df75Z+o8qev1sd6kRt6 vxlvNPv7pvA+2nvKqB4EKAECINAKgUG4I7703YXc2/kjHq2EX64M1yLt+lmnny+Ji3sTqVs54qvP a7YfndMogvX8nQktpE/qchVGPIg/rd6T9W/lE/wHecc1Cxy5hYB04UOXFGs6271eEKleOPhuS/fs lx9Mqnoi37P1nb6qLP1ucVAyfLdljX67Tt5XT82XYP54MqWM6f/kl+Q3x/375lQIwFAMQ8VavqZc OedL6tDIqs6ff5/sfmB8vvP2t+fdH3+06DxOHg6rX7NdCD6h+6giNwFMVAvZU36tNQnrPNI06FKS 1j7bJBfcq0PFZU26EmsImf7vGxYxqe5NWT5+1/LX+ERe8ZECBA2sdGSZWoPWsCxmQeWDzYSCIAAC dQgMwh0hxdez41xEr+n86q3cV3De8pGd8nNKZjy/yTRUVvZsdU4iTWN0aKIs+rrcW+lKDqtt8iJT fSUm10cBtKjXTsot61XnhKpUYedZ+aR3/sfVVD58W5EMCj9cvqefp0kJ9TxNfsPs/EevduHHH355 /9Hr7iFRMYAffVn+MQsqvs8vBNDt8Omflurp//vT1a/NPWy9kt9zCEHnNnF3LHm7rV40ieuW5Iv8 2oQQTtPfP7HKXz/LmETyoCIWegkmrm5V+rvjOtnMU1dgPcstwVSGYaiGh+Vc4E1vpb/arr96lszZ 9t+SgV7MP+WXvCjDtB+efn/IxFEC9ZAZ4qys9jIIUNLPHOPC3dZ6JU71X89kJgCRc4ZPvaUjzdUQ ovP4TS9xDAvHcPNpZddrLaL4BmxxYDFKPbRp3J3ViFfjuyKRgZIqNuFRoIlQDARAoC6BobgjxUT1 Ebm3yzJc6/Tj7HFERoBLkrm7zDX5asGBjWwI5PgHE+14mP0hOf9BeFp8O9y9qJWFOqa//OGw+Z72 JDLP+gvlYXAIoRgASNsSKxfK46kjge8acgXSm/p0/pVWuY02VNzot8npR7Yp08Ua6eW8/aF0zy85 TA4/LBsaobhRcioGhHg/yu8m5O3xss4fjHPZULeyflYcF57GdEHd37kYrQql/+TsyWlivMKwiBxu djNKooga2Eg6aMnpjUKSB+b1Fonbnqz4aEMr4HIQAIGGBIbijjgxROTe7kCGaxnGeP+jY3ZHZHqz pF8jljwadozyy3+z3xo/6dcUbucAQ/XizlVFCqhcxI0ogLSelb6Y8/jVNHm/XJwVquBN3g8j58wK jbztf7cmb0MsmenlM27xfPyD8vbI1rSTRjmXAZL3okjEcPPoE1yDJ319FCYZX3lJPtmLU1E1oDAI gECbBIbrjkTkCm8nw3UhkXq9ZO68MHHaqNvhZEL3zuLbKBTPeF99dmyEpN0JQTc5jsT8Tr0r+0ar DIWlh4o+9sfLL3qbJy3rLBL2mVJXSWz1qOmd/LPJ4g9btc+UnZ7F8nvp3tA2ev7j8nub5H1/zO/8 sOr++iO7LEXspBcvJBViQkJOa9eIvb9VL5+pnShmz8rb5T2ZftWKavX6WQBLHkJ6HURkWVrOvQLH DbdkfRQRKFqfMXtHvDUUBpaI2+jd6OfP9u6TAK2yRTjqSatBadxHB16qXxaLbgsXgAAIlBEYrjsS k3u7nQzXxUTqMcnc7VdGaR1EribQje20Uc/Z6e5UXjn/k91ZbVnNrO9Mf0B7Pp7srazyhVVa6DmI 76WXwE/nD2pb6BO9PRvw3myTcWRkkDGDMk+FHB2xu4JV+DVtprnCetDXz6evDqt/LFmRIeyvu3cZ 3jCHl4iYB+WJl7JZ57jQph9rgamEk221p/0/e220A8Zqh7vveSa3gPIr7JGLil6JeQjRjhFRb1WW pbjhRju8hLxyo4r8+GsoDKzEnb5ebRyfrclKLLXcq5Xfv678DGsjK22QeWl7D1ST4YJrQWCcBPgt RApZjlN5aD1UAuTb8Rbgtu73t8FEThu9Dt2V9bjb6IxWQAAEQIAJ8PMJ3JEu9IV/9+9+9V//6++7 IMkAZKANIjl3hIIZndWLpFWyaXeEglj/439885OfDDdy2VljQDAQAIE7EYA7cifwaPbKBNgdoSNY 6EPbV7sfIyFHhFbT6LP4I0RHrtw1UD0IgEAXCcAd6aJVIBMIgAAIgAAIjIoAuSMICI/K4lAWBEAA BEAABLpIAO5IF60CmUAABEAABEBgVATgjozK3FAWBEAABEAABLpIAO5IF60CmUAABEAABEBgVATg jozK3FAWBEAABEAABLpIAO5IF60CmUAABEAABEBgVATgjozK3FAWBEAABEAABEAABEAABEAABEAA BECgQOD/A1chizN9hxV0AAAAAElFTkSuQmCC --_006_421CE35A2FDF994790546C7F50F875455E9E3E19dggemi526mbschi_-- From nobody Tue Mar 5 21:34:33 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 561F6128AFB; Tue, 5 Mar 2019 21:34:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <155185046430.27676.15996642632717108907@ietfa.amsl.com> Date: Tue, 05 Mar 2019 21:34:24 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 05:34:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Transport Options for UDP Author : Joe Touch Filename : draft-ietf-tsvwg-udp-options-06.txt Pages : 31 Date : 2019-03-05 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-06 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 5 21:37:29 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B80F12D4E7 for ; Tue, 5 Mar 2019 21:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Kk73JsvIBO-g for ; Tue, 5 Mar 2019 21:37:27 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 285C4129284 for ; Tue, 5 Mar 2019 21:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UoA+Xv282hnRBVhbiJfgRq0tXUEfvsA3el93UH6tji8=; b=6BE2IYR0Fq4RLuJhCqR49qFT99 87SGnR7GL7LtBin3yiqnVMNNbGIoSUhs/1bWYxq/nXOYl0guqEg2NqYjX6H+e+T1V2XBL+CacxiDl BpEYiuP+Guv9jVF31an6kRJO+jCbFfX+vK3Y7NvglJ3WytjaxfaV+T2Us/q9J6ZRRbWCqxL3EQW+2 0/hdxpTj5ndQZeIpAhcQoiOnpIz4I+TiS76Z/jj72iEmxCtk7Wbv1fnWp+VXYY0NbHr1Sb0p/L9ji 100x/fvfJ9aKJlS+0Nl9CvzpM9dE92YXYjLC43u6vR+2a4ijBUPh5rZbAlF9vKp1ZpQK6sjmK1J50 6lHxa71g==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:56049 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h1PF7-001XwE-NV; Wed, 06 Mar 2019 00:37:26 -0500 To: tsvwg@ietf.org References: <155185046430.27676.15996642632717108907@ietfa.amsl.com> From: Joe Touch Message-ID: Date: Tue, 5 Mar 2019 21:37:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155185046430.27676.15996642632717108907@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 05:37:28 -0000 Note that this version is intended to incorporate all known pending issues since the last IETF, though it does not re-open some of the issues that were recently re-raised. Comments to the WG list please; I will not be attending the upcoming IETF meeting in person or remotely. Joe On 3/5/2019 9:34 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group WG of the IETF. > > Title : Transport Options for UDP > Author : Joe Touch > Filename : draft-ietf-tsvwg-udp-options-06.txt > Pages : 31 > Date : 2019-03-05 > > Abstract: > Transport protocols are extended through the use of transport header > options. This document experimentally extends UDP by indicating the > location, syntax, and semantics for UDP transport layer options. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-06 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From nobody Thu Mar 7 08:37:00 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1713144E for ; Thu, 7 Mar 2019 08:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 zusdPPe23HTr for ; Thu, 7 Mar 2019 08:36:45 -0800 (PST) Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E76713140E for ; Thu, 7 Mar 2019 08:36:45 -0800 (PST) Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 28B48624BE for ; Thu, 7 Mar 2019 11:36:44 -0500 (EST) (envelope-from heard@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=LsE HeUP275Rg4DUE4JsincYQTeA=; b=pY2gTMBtug4fOGkSzoYTIpnfLoRTtH0ILuY knA0CfnFgviWe5I3LR2oLJElHhbMCKNqX953wyISWieh4Aa9YZl6KZ60GejxB/bi 0o5tFcHPdc6EIfdbUxvV8F2aJ7WErGZHO30Fjo3wPYlTYnH9LX5QGgKT/G7odqOG MCIfYrTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= wnD9n0Ze17dykyCATCh/rCYQkMDmrcFTPFFyoTCBm399cnNs4ZIaWA3u+fF6jWrP jqhIih2QMCUlvqadcvhul2j1PA8GUR9jD8Gv6dsOFlc0rVmPheaXEGK382FoTvRt Wggqa+DQa8MhWo9fYBjw0r9R0/VqrH5Xs8FYyocXANk= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 20A79624BD for ; Thu, 7 Mar 2019 11:36:44 -0500 (EST) (envelope-from heard@pobox.com) Received: from mail-it1-f175.google.com (unknown [209.85.166.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id C5BD2624BC for ; Thu, 7 Mar 2019 11:36:41 -0500 (EST) (envelope-from heard@pobox.com) Received: by mail-it1-f175.google.com with SMTP id v83so16771763itf.1 for ; Thu, 07 Mar 2019 08:36:41 -0800 (PST) X-Gm-Message-State: APjAAAUJxH0izMgXWs/k5DfQtvVL26JNAw5G19bfiXnF6DRq3Nvq/LDp 70iTUzb6W2YP6ZGaPCgG2C5z+W03TX6NrExFJdE= X-Google-Smtp-Source: APXvYqxdh0Ih21KK8aj60WUJmrWtLCZ/LBgYgu0Bab/0FUG8wWEXRqagbKIXAMTlfmpignRv/U2qqm/aSebsQTZr6Nk= X-Received: by 2002:a24:7d88:: with SMTP id b130mr5963086itc.163.1551976600583; Thu, 07 Mar 2019 08:36:40 -0800 (PST) MIME-Version: 1.0 From: "C. M. Heard" Date: Thu, 7 Mar 2019 08:36:33 -0800 X-Gmail-Original-Message-ID: Message-ID: To: tsvwg Cc: Joe Touch Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 3004F1F2-40F7-11E9-BF33-D01F9763A999-06080547!pb-smtp20.pobox.com Archived-At: Subject: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 16:36:59 -0000 Greetings, First, thanks to Joe Touch for this update. That said, it appears to me that the edits to the description of OCS are incomplete. I see in the first paragraph The Option Checksum (OCS) is conventional Internet checksum that covers all of the UDP options. and further down >> OCS SHOULD be half-word aligned to the start of the UDP packet. This is to help ensure that the option, together with the other options, result in an overall zero ones-complement sum, which may help the UDP options traverse devices that incorrectly attempt to checksum the surplus area (as originally proposed as the Checksum Compensation Option [Fa18]). However, the second paragraph (which is consistent with the diagram) says OCS is calculated by computing the ones-complement of the 8-bit ones-complement checksum (i.e., Internet checksum) sum of the options area. Perhaps I am missing something, but it seems to me that OCS cannot perform the function of the proposed Checksum Compensation Option (CCO) unless it is computed as the the 16 bit one's complement of the one's complement sum of all 16 bit half-words in the options area, subject to the following alignment requirements: - if the options area begins on an odd octet boundary, then it conceptually prepended by a zero-valued octet for the purposes of checksum computation; - if the options area ends on an odd octet boundary, then it is conceptually padded by a zero-valued octet for the purposes of checksum computation; - the OCS option is preceded by a NOP option if necessary so that the checksum itself is 16-bit aligned (i.e., is on an even octet boundary). This can all be achieved with an option that has kind = 2 followed by a 16-bit checksum, without a length value. That actually has better properties than CCO as originally proposed, because it is never required to be more than four octets in length, including any padding needed for half-word alignment. If I am missing something (which happens all too often these days) I would like to hear what it is. Thanks and regards, Mike Heard From nobody Thu Mar 7 08:56:25 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA081313EF for ; Thu, 7 Mar 2019 08:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 yHcwdSNg4KbS for ; Thu, 7 Mar 2019 08:56:22 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 5220C1310AB for ; Thu, 7 Mar 2019 08:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2XZblejQInGLUlByLjohV6gPYiBoT0HwERJqT91o+mA=; b=spFUaZSfY5iyYcMWrXBaFt2n9 v+FvFqoAuEGCSb4vuWNhsPwPLMQUp/B5ae7v+NgVEAuM6fAkG/Ga8Zy38IIiTX2An5GoiSZVGff0T jvnpmWKvMkL004eGbdjpKc1G8HvwBUjDbx2YfYmxmmGJONKTm3r+zk/+ip+OA8Th0TU8QcaJd9RZt MZvII2EWJuYhtPXv599CEkPa9wMVeO/5pCtvb8MOmtL5Cf1z59cGBCDFlbLzu3eodGmocnoyQf0AD ImMEisUry/j9RkTjlNqBdzou6J31EWL7XufXwZo0uywl+hg0BPxKycLj+hfBxPlhRbiLsRsrRm6Ic 516fvaLvg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:55887 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h1wJf-000Wt4-Ps; Thu, 07 Mar 2019 11:56:21 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Thu, 7 Mar 2019 08:56:19 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> References: To: "C. M. Heard" X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 16:56:23 -0000 > On Mar 7, 2019, at 8:36 AM, C. M. Heard wrote: >=20 > Greetings, >=20 > First, thanks to Joe Touch for this update. That said, it appears to = me > that the edits to the description of OCS are incomplete. =20 Yes - sorry about that. I wanted to get a quick update out for initial = feedback, but there are probably more than a few rough edges where = things need to be made consistent.=20 So I appreciate the feedback - comments below... > I see in the > first paragraph >=20 > The Option Checksum (OCS) is conventional Internet checksum that > covers all of the UDP options. >=20 > and further down >=20 >>> OCS SHOULD be half-word aligned to the start of the UDP packet. > This is to help ensure that the option, together with the other > options, result in an overall zero ones-complement sum, which may > help the UDP options traverse devices that incorrectly attempt to > checksum the surplus area (as originally proposed as the Checksum > Compensation Option [Fa18]). >=20 > However, the second paragraph (which is consistent with the diagram) = says >=20 > OCS is calculated by computing the ones-complement of the 8-bit > ones-complement checksum (i.e., Internet checksum) sum of the > options area. Yeah - in my rush, I didn=E2=80=99t fix that. >=20 > Perhaps I am missing something, but it seems to me that OCS cannot = perform > the function of the proposed Checksum Compensation Option (CCO) unless = it > is computed as the the 16 bit one's complement of the one's = complement sum > of all 16 bit half-words in the options area, The intent is as you assume; the text needs to be updated accordingly. > subject to the following > alignment requirements: >=20 > - if the options area begins on an odd octet boundary, then it = conceptually > prepended by a zero-valued octet for the purposes of checksum = computation; >=20 > - if the options area ends on an odd octet boundary, then it is = conceptually > padded by a zero-valued octet for the purposes of checksum = computation; >=20 > - the OCS option is preceded by a NOP option if necessary so that the > checksum itself is 16-bit aligned (i.e., is on an even octet = boundary). >=20 > This can all be achieved with an option that has kind =3D 2 followed = by a 16-bit > checksum, without a length value. That actually has better properties = than > CCO as originally proposed, because it is never required to be more = than > four octets in length, including any padding needed for half-word = alignment. These seem complete to me - I=E2=80=99d like the CCO people to check, = though. Note that the trailing =E2=80=98virtual zero=E2=80=99 is already part of = how the Internet checksum works for odd byte-lengths. The new part here = is to force the virtual zero on the front - however, that=E2=80=99s not = really needed. We can compute the checksum starting wherever we want. If we start on an = odd boundary, then just swap the bytes when we=E2=80=99re done. So the simpler variant is: - precede by NOP if not 16-bit aligned - do IP checksum as per RFC 1071 - if NOP was added, just insert the result - if NOP wasn=E2=80=99t added, swap bytes of the sum and insert = the result (we can explain why this works) >=20 > If I am missing something (which happens all too often these days) I = would > like to hear what it is. >=20 > Thanks and regards, >=20 > Mike Heard From nobody Thu Mar 7 13:04:15 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946F5130F36 for ; Thu, 7 Mar 2019 13:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ldd2MbmhL34q for ; Thu, 7 Mar 2019 13:04:11 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id A7DF51311D1 for ; Thu, 7 Mar 2019 13:04:08 -0800 (PST) Received: from erg.abdn.ac.uk (at-www-1.erg.abdn.ac.uk [IPv6:2001:630:42:150::5]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id DEE1F1B00108; Thu, 7 Mar 2019 21:04:03 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 07 Mar 2019 21:04:03 +0000 From: raffaele To: Joe Touch Cc: "C. M. Heard" , tsvwg In-Reply-To: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> Message-ID: X-Sender: raffaele@erg.abdn.ac.uk User-Agent: Roundcube Webmail/1.2.3 Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 21:04:15 -0000 Hello, I am Raffaele Zullo, former researcher at the University of Aberdeen. I have previously worked on CCO. On 2019-03-07 16:56, Joe Touch wrote: >> On Mar 7, 2019, at 8:36 AM, C. M. Heard wrote: >> >> Greetings, >> >> First, thanks to Joe Touch for this update. That said, it appears to >> me >> that the edits to the description of OCS are incomplete. > > Yes - sorry about that. I wanted to get a quick update out for initial > feedback, but there are probably more than a few rough edges where > things need to be made consistent. > > So I appreciate the feedback - comments below... > >> I see in the >> first paragraph >> >> The Option Checksum (OCS) is conventional Internet checksum that >> covers all of the UDP options. >> >> and further down >> >>>> OCS SHOULD be half-word aligned to the start of the UDP packet. >> This is to help ensure that the option, together with the other >> options, result in an overall zero ones-complement sum, which may >> help the UDP options traverse devices that incorrectly attempt to >> checksum the surplus area (as originally proposed as the Checksum >> Compensation Option [Fa18]). >> >> However, the second paragraph (which is consistent with the diagram) >> says >> >> OCS is calculated by computing the ones-complement of the 8-bit >> ones-complement checksum (i.e., Internet checksum) sum of the >> options area. > > Yeah - in my rush, I didn’t fix that. > >> >> Perhaps I am missing something, but it seems to me that OCS cannot >> perform >> the function of the proposed Checksum Compensation Option (CCO) unless >> it >> is computed as the the 16 bit one's complement of the one's >> complement sum >> of all 16 bit half-words in the options area, > > The intent is as you assume; the text needs to be updated accordingly. > >> subject to the following >> alignment requirements: >> >> - if the options area begins on an odd octet boundary, then it >> conceptually >> prepended by a zero-valued octet for the purposes of checksum >> computation; >> >> - if the options area ends on an odd octet boundary, then it is >> conceptually >> padded by a zero-valued octet for the purposes of checksum >> computation; >> >> - the OCS option is preceded by a NOP option if necessary so that the >> checksum itself is 16-bit aligned (i.e., is on an even octet >> boundary). >> >> This can all be achieved with an option that has kind = 2 followed by >> a 16-bit >> checksum, without a length value. That actually has better properties >> than >> CCO as originally proposed, because it is never required to be more >> than >> four octets in length, including any padding needed for half-word >> alignment. > > These seem complete to me - I’d like the CCO people to check, though. Yes, an implicit length of 3 can save 1 byte without changing CCO benefit. (Actually we also explored another scheme for CCO that doesn't need half-word alignment so it never requires padding. The computation is a bit more complicated so considering it saved only 0-1 byte it has not been included in the CCO draft.) I would only add that the checksum has also to cover the 2 bytes pseudo-header containing UDP Options length other than UDP Options area bytes. > Note that the trailing ‘virtual zero’ is already part of how the > Internet checksum works for odd byte-lengths. The new part here is to > force the virtual zero on the front - however, that’s not really > needed. > We can compute the checksum starting wherever we want. If we start on > an odd boundary, then just swap the bytes when we’re done. Yes, this solution works. Considering we have also to include UDP Options length in the sum, another option could be loading UDP options length + the first odd byte, if present, into checksum value before applying Internet Checksum from the first even byte of the Options. > So the simpler variant is: > - precede by NOP if not 16-bit aligned > - do IP checksum as per RFC 1071 > - if NOP was added, just insert the result > - if NOP wasn’t added, swap bytes of the sum and insert the result > > (we can explain why this works) Yes, the simpler variant works. If I am not wrong it assumes the 3-bytes OCS is always the first option (excluding NOP padding). Are you going to make this mandatory? >> If I am missing something (which happens all too often these days) I >> would >> like to hear what it is. >> >> Thanks and regards, >> >> Mike Heard I am new to the WG so please be nice :) Thank you, Raffaele Zullo From nobody Thu Mar 7 13:23:14 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6513312DF72 for ; Thu, 7 Mar 2019 13:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnj5u98aX6kd for ; Thu, 7 Mar 2019 13:23:12 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED8C12D4EB for ; Thu, 7 Mar 2019 13:23:12 -0800 (PST) Received: by bugle.employees.org (Postfix, from userid 1736) id 6D123FECBF3F; Thu, 7 Mar 2019 21:23:11 +0000 (UTC) Date: Thu, 7 Mar 2019 21:23:11 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20190307212311.GA95604@bugle.employees.org> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 21:23:13 -0000 On Thu, Mar 07, 2019 at 09:04:03PM +0000, raffaele wrote: > > Yes, the simpler variant works. > If I am not wrong it assumes the 3-bytes OCS is always the first option > (excluding NOP padding). > Are you going to make this mandatory? I don't think that is necessary for it to be first, as long as the 16 bits of checksum are correctly aligned for how they're swapped, the checksum can be at any offset in the payload. I believe the result of the CCO experiment was that it, or this new OCS, would always have to be present in order to guarentee a packet passes through certain middleboxes. Except possibly th the case where the UDP header checksum is zero? Given that wouldn't it make sense for this option to be both mandatory to implement, and always present in the options area? DF From nobody Thu Mar 7 13:23:47 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA54712DF72 for ; Thu, 7 Mar 2019 13:23:45 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 EXMtikTwuRmJ for ; Thu, 7 Mar 2019 13:23:43 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 1B49512D4EB for ; Thu, 7 Mar 2019 13:23:43 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id v10so18927043qtp.8 for ; Thu, 07 Mar 2019 13:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GdkNP/Twl0ffB+lDILZaa8R3Zg3fWdlTJ/RMZVy4QIg=; b=PQ205jiaFJjXvBkbqGLlVgYqvFGxeIVpgkNXGfYGxyrOQ7UjYbH/lQYLdBJXDf8WqC BW8zbH9opmE0dqWmtgps7wMBElg8tMkKrZ6b/MBBOXICdL/2dBPCh3rw/vXSXdLvuJl2 U/ZEhLO3CHK9tZLNTa1dzbx79V+86QZo8aJtj46ZB5okCBMloO69mbvz836/dFXWp4s3 aJiSua3iIRTkWZkeVA8b+5WDzGXbDl0e+WKBVy9dBpy2r4rqC/rFmDJCoZ/a0JqRH8Ua rtWipcJS0pzUFGDjLaY9mI9FtCxarmXCaIqx1zDNtBOlmAQf8cn+RhGEVY2SfcvJFZsg /+sw== 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:content-transfer-encoding; bh=GdkNP/Twl0ffB+lDILZaa8R3Zg3fWdlTJ/RMZVy4QIg=; b=t4AWU1XOfcWyYhUUSvDVD3w7HVY1RQR0vHdZWcJhhL5Gl6p8q4N7VGFYyOaeht8C7o evL1uagjhel/RjLndrlOpsqeN4SII79lndsglB1pOWMJ38AOgkPyiNb88ZsfkzrRzw90 pvbTDWR/Hr8TCblak6I17mBsJ5qRRg6I/O7brVoCt/Bm48YH8tJzv99YOREpRL1xKSYi qKlC3wr9V1Y1owprBJ8ChOOeVA4dqy1oHZD3OZ4QtKGZo/2MwaNDDrMjnbehjnunA4L1 clBEqlTAeVek3Kpj0Phm2ZNkZF+3nZeAL5jE1hKMt01JPSqkVbdhMrcdFBDb55kNElBX iOog== X-Gm-Message-State: APjAAAWHRBmePi8NpfP109eOtIWnu52sfVJd5r7Q2B4wjG37r6aUe70O twioMvLMUfwXJXgk66QoEjFhElZ2Gey5uSvggWJu0w== X-Google-Smtp-Source: APXvYqxp1k5MtAQ5TBLg+dCjJ8rzTfW8/njWQfiTK1wwTIIpViMYR5vh7N+UJ/uMxBJx9MWZJXpSL8oE+ag883df1kQ= X-Received: by 2002:a0c:ba13:: with SMTP id w19mr12004486qvf.179.1551993821798; Thu, 07 Mar 2019 13:23:41 -0800 (PST) MIME-Version: 1.0 References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> In-Reply-To: From: Tom Herbert Date: Thu, 7 Mar 2019 13:23:29 -0800 Message-ID: To: raffaele Cc: Joe Touch , "C. M. Heard" , tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 21:23:46 -0000 On Thu, Mar 7, 2019 at 1:04 PM raffaele wrote: > > Hello, > I am Raffaele Zullo, former researcher at the University of Aberdeen. > I have previously worked on CCO. > > > On 2019-03-07 16:56, Joe Touch wrote: > >> On Mar 7, 2019, at 8:36 AM, C. M. Heard wrote: > >> > >> Greetings, > >> > >> First, thanks to Joe Touch for this update. That said, it appears to > >> me > >> that the edits to the description of OCS are incomplete. > > > > Yes - sorry about that. I wanted to get a quick update out for initial > > feedback, but there are probably more than a few rough edges where > > things need to be made consistent. > > > > So I appreciate the feedback - comments below... > > > >> I see in the > >> first paragraph > >> > >> The Option Checksum (OCS) is conventional Internet checksum that > >> covers all of the UDP options. > >> > >> and further down > >> > >>>> OCS SHOULD be half-word aligned to the start of the UDP packet. > >> This is to help ensure that the option, together with the other > >> options, result in an overall zero ones-complement sum, which may > >> help the UDP options traverse devices that incorrectly attempt to > >> checksum the surplus area (as originally proposed as the Checksum > >> Compensation Option [Fa18]). > >> > >> However, the second paragraph (which is consistent with the diagram) > >> says > >> > >> OCS is calculated by computing the ones-complement of the 8-bit > >> ones-complement checksum (i.e., Internet checksum) sum of the > >> options area. > > > > Yeah - in my rush, I didn=E2=80=99t fix that. > > > >> > >> Perhaps I am missing something, but it seems to me that OCS cannot > >> perform > >> the function of the proposed Checksum Compensation Option (CCO) unless > >> it > >> is computed as the the 16 bit one's complement of the one's > >> complement sum > >> of all 16 bit half-words in the options area, > > > > The intent is as you assume; the text needs to be updated accordingly. > > > >> subject to the following > >> alignment requirements: > >> > >> - if the options area begins on an odd octet boundary, then it > >> conceptually > >> prepended by a zero-valued octet for the purposes of checksum > >> computation; > >> > >> - if the options area ends on an odd octet boundary, then it is > >> conceptually > >> padded by a zero-valued octet for the purposes of checksum > >> computation; > >> > >> - the OCS option is preceded by a NOP option if necessary so that the > >> checksum itself is 16-bit aligned (i.e., is on an even octet > >> boundary). > >> > >> This can all be achieved with an option that has kind =3D 2 followed b= y > >> a 16-bit > >> checksum, without a length value. That actually has better properties > >> than > >> CCO as originally proposed, because it is never required to be more > >> than > >> four octets in length, including any padding needed for half-word > >> alignment. > > > > These seem complete to me - I=E2=80=99d like the CCO people to check, t= hough. > > Yes, an implicit length of 3 can save 1 byte without changing CCO > benefit. > > (Actually we also explored another scheme for CCO that doesn't need > half-word alignment so it never requires padding. > The computation is a bit more complicated so considering it saved only > 0-1 byte it has not been included in the CCO draft.) > > > I would only add that the checksum has also to cover the 2 bytes > pseudo-header containing UDP Options length other than UDP Options area > bytes. > > > Note that the trailing =E2=80=98virtual zero=E2=80=99 is already part o= f how the > > Internet checksum works for odd byte-lengths. The new part here is to > > force the virtual zero on the front - however, that=E2=80=99s not reall= y > > needed. > > We can compute the checksum starting wherever we want. If we start on > > an odd boundary, then just swap the bytes when we=E2=80=99re done. > > Yes, this solution works. > > Considering we have also to include UDP Options length in the sum, > another option could be loading > UDP options length + the first odd byte, if present, > into checksum value before applying Internet Checksum from the first > even byte of the Options. > > > > So the simpler variant is: > > - precede by NOP if not 16-bit aligned > > - do IP checksum as per RFC 1071 > > - if NOP was added, just insert the result > > - if NOP wasn=E2=80=99t added, swap bytes of the sum and insert t= he result > > > > (we can explain why this works) > > > Yes, the simpler variant works. > If I am not wrong it assumes the 3-bytes OCS is always the first option > (excluding NOP padding). > Are you going to make this mandatory? > If it's mandatory, it's not longer an option. It has been suggested a number of time that the UDP option space should be preceded by header that includes the checksum and and length of the space. Tom > >> If I am missing something (which happens all too often these days) I > >> would > >> like to hear what it is. > >> > >> Thanks and regards, > >> > >> Mike Heard > > > I am new to the WG so please be nice :) > > Thank you, > Raffaele Zullo > From nobody Thu Mar 7 13:36:44 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9941D1311B5 for ; Thu, 7 Mar 2019 13:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1broBAFUaR2 for ; Thu, 7 Mar 2019 13:36:37 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F96A13119C for ; Thu, 7 Mar 2019 13:36:37 -0800 (PST) Received: by bugle.employees.org (Postfix, from userid 1736) id 6EA5AFECBF26; Thu, 7 Mar 2019 21:36:36 +0000 (UTC) Date: Thu, 7 Mar 2019 21:36:36 +0000 From: Derek Fawcus To: tsvwg@ietf.org Message-ID: <20190307213636.GB95604@bugle.employees.org> References: <155185046430.27676.15996642632717108907@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 21:36:39 -0000 On Tue, Mar 05, 2019 at 09:37:25PM -0800, Joe Touch wrote: > Note that this version is intended to incorporate all known pending > issues since the last IETF, though it does not re-open some of the > issues that were recently re-raised. Joe, thanks for the update. I've only had a quick scan so far, but spotted a typo: Section 5.10: The AE option is sometimes (first para) referred to as UDP-AO. I'll have a proper read later. DF From nobody Thu Mar 7 17:22:14 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210AB130EEA for ; Thu, 7 Mar 2019 17:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3a0bHvIAmcC for ; Thu, 7 Mar 2019 17:22:12 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 14B4612008A for ; Thu, 7 Mar 2019 17:22:12 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C953FD61A008CFE72358; Fri, 8 Mar 2019 01:22:09 +0000 (GMT) Received: from DGGEMI405-HUB.china.huawei.com (10.3.17.143) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Mar 2019 01:22:09 +0000 Received: from DGGEMI529-MBS.china.huawei.com ([169.254.5.238]) by dggemi405-hub.china.huawei.com ([10.3.17.143]) with mapi id 14.03.0415.000; Fri, 8 Mar 2019 09:22:01 +0800 From: "qiangli (D)" To: tsvwg CC: Toerless Eckert Thread-Topic: A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) Thread-Index: AdTVTUw267hC5GTQTZyGvOBVjR2e1w== Date: Fri, 8 Mar 2019 01:22:01 +0000 Message-ID: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_06C389826B926F48A557D5DB5A54C4ED45BE93CBdggemi529mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 01:22:14 -0000 --_000_06C389826B926F48A557D5DB5A54C4ED45BE93CBdggemi529mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We have uploaded a new draft (draft-qiang-tsvwg-udp-options-bounded-latency= -00) that explores the use of UDP options for bounded latency forwarding. R= eview and comment is highly appreciated. Best regards, Cristina QIANG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A new version of I-D, draft-qiang-tsvwg-udp-options-bounded-latency-00.txt has been successfully submitted by Li Qiang and posted to the IETF reposito= ry. Name: draft-qiang-tsvwg-udp-options-bounded-latency Revision: 00 Title: UDP Options for Bounded Latency Document date: 2019-03-08 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-= options-bounded-latency-00.txt Status: https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-opti= ons-bounded-latency/ Htmlized: https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-b= ounded-latency-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp= -options-bounded-latency Abstract: This document explores the use of UDP options for packet forwarding with bounded latency. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_06C389826B926F48A557D5DB5A54C4ED45BE93CBdggemi529mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

We have uploaded a new draft (d= raft-qiang-tsvwg-udp-options-bounded-latency-00) that explores the use of U= DP options for bounded latency forwarding. Review and comment is highly app= reciated.

 

 

Best regards,=

 

Cristina QIANG

 

 

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

A new version of I-D, draft-= qiang-tsvwg-udp-options-bounded-latency-00.txt

has been successfully submit= ted by Li Qiang and posted to the IETF repository.

 

Name:    = ;           draft-qiang-t= svwg-udp-options-bounded-latency

Revision:  00

Title:   &nbs= p;            &= nbsp; UDP Options for Bounded Latency

Document date:  &n= bsp;    2019-03-08

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           9=

URL:    =         https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-bounded-= latency-00.txt

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounded-late= ncy/

Htmlized:   &= nbsp;   https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-latency-0= 0

Htmlized:   &= nbsp;   https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-bounded= -latency

 

 

Abstract:<= /p>

   This document e= xplores the use of UDP options for packet forwarding

   with bounded la= tency.

 

    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; 

 

 

Please note that it may take= a couple of minutes from the time of submission until the htmlized version= and diff are available at tools.ietf.org.

 

The IETF Secretariat

 

--_000_06C389826B926F48A557D5DB5A54C4ED45BE93CBdggemi529mbschi_-- From nobody Thu Mar 7 19:43:58 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D9E1312A9 for ; Thu, 7 Mar 2019 19:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 ngORDqCmIVDf for ; Thu, 7 Mar 2019 19:43:55 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C1F35131298 for ; Thu, 7 Mar 2019 19:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nigLBl5LFtu2ejo/3eOKnYWw3ONrD8MupPV6W3FUXPY=; b=SDbtBQdr+35+Nb84BY5bemtCU ZkK1gpM3gjMtNskVQNUkw6JYFSAMPjvqAOsuQ0ig8qQz7fsWRQZHIIvhXztCPvjEzCds5VdqkhWLn e7riS/3HWwzHPvSFtgG0OOGTdSvTZ6DcXikleCHh1Ha1AS3MrCzxLH7NlekhNWu5N6eHJIE2rZ7Sg IPs5TevIrOm/+4tpksn8uH8X0MN0Al/q9w3SGwGZoICHCAgiAYPlnWhVmWQ2dWhagwEXW7ZTVzr5E w/ea16aw+/FAw8xPVODxn0GV9ZSXFsSHDGjZ229B1qjQ1ZZiP34gHZb3PxTk4LF1z2xIwkmfV8KBs N/k6PbadQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:56522 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h26QH-001ev7-AB; Thu, 07 Mar 2019 22:43:51 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_808C3E37-66A5-47F8-8C87-96B172259BBD" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> Date: Thu, 7 Mar 2019 19:43:48 -0800 Cc: tsvwg , Toerless Eckert Message-Id: <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> To: "qiangli (D)" X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 03:43:57 -0000 --Apple-Mail=_808C3E37-66A5-47F8-8C87-96B172259BBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Two points (the first is useful for everyone developing upcoming UDP = options): 1. proposals for new UDP options should indicate a KIND value of = =E2=80=9CTBD=E2=80=9D only; they should not =E2=80=98squat=E2=80=99 or = preselect a value until assigned by IANA (when the UDP options doc is = published) or - until the UDP doc is published - at least the doc is = accepted as a WG doc. 2. a request for such assignment should be included in the IANA = considerations portion of that document These are common conventions for assigned numbers in general. As a result, I encourage the authors to quickly issue an update to this = doc that follows the above convention. Additionally, if accepted, can you explain why it wouldn=E2=80=99t be = sufficient to just request the next open value? Joe > On Mar 7, 2019, at 5:22 PM, qiangli (D) wrote: >=20 > Hi All, > =20 > We have uploaded a new draft = (draft-qiang-tsvwg-udp-options-bounded-latency-00) that explores the use = of UDP options for bounded latency forwarding. Review and comment is = highly appreciated. > =20 > =20 > Best regards, > =20 > Cristina QIANG > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A new version of I-D, = draft-qiang-tsvwg-udp-options-bounded-latency-00.txt > has been successfully submitted by Li Qiang and posted to the IETF = repository. > =20 > Name: draft-qiang-tsvwg-udp-options-bounded-latency > Revision: 00 > Title: UDP Options for Bounded Latency > Document date: 2019-03-08 > Group: Individual Submission > Pages: 9 > URL: = https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-bounded= -latency-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounded-lat= ency/ = > Htmlized: = https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-latency-= 00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-bounde= d-latency = > =20 > =20 > Abstract: > This document explores the use of UDP options for packet forwarding > with bounded latency. > =20 > = =20 > =20 > =20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org . > =20 > The IETF Secretariat --Apple-Mail=_808C3E37-66A5-47F8-8C87-96B172259BBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Two = points (the first is useful for everyone developing upcoming UDP = options):

1. = proposals for new UDP options should indicate a KIND value of =E2=80=9CTBD= =E2=80=9D only; they should not =E2=80=98squat=E2=80=99 or preselect a = value until assigned by IANA (when the UDP options doc is published) or = - until the UDP doc is published - at least the doc is accepted as a WG = doc.

2. a = request for such assignment should be included in the IANA = considerations portion of that document

These are common conventions for = assigned numbers in general.

As a result, I encourage the authors to = quickly issue an update to this doc that follows the above = convention.

Additionally, if accepted, can you explain why it wouldn=E2=80=99= t be sufficient to just request the next open value?

Joe

On Mar 7, 2019, at 5:22 PM, = qiangli (D) <qiangli3@huawei.com> wrote:

Hi All,
 
We have uploaded = a new draft (draft-qiang-tsvwg-udp-options-bounded-latency-00) that = explores the use of UDP options for bounded latency forwarding. Review = and comment is highly appreciated.
 
 
Best = regards,
 
Cristina = QIANG
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
A new version of I-D, = draft-qiang-tsvwg-udp-options-bounded-latency-00.txt
has been successfully submitted by Li Qiang = and posted to the IETF repository.
 
Name:         &nbs= p;     = draft-qiang-tsvwg-udp-options-bounded-latency
Revision:  00
Title:         &nb= sp;        UDP Options for Bounded = Latency
Document = date:       2019-03-08
Group:         &nb= sp;     Individual Submission
Pages:         &nb= sp;     9
 
 
Abstract:
   This document explores the use of = UDP options for packet forwarding
   with bounded latency.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;        
 
 
Please note that it may take = a couple of minutes from the time of submission until the htmlized = version and diff are available at tools.ietf.org.
 
The = IETF Secretariat

= --Apple-Mail=_808C3E37-66A5-47F8-8C87-96B172259BBD-- From nobody Thu Mar 7 19:47:30 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4CB13129F for ; Thu, 7 Mar 2019 19:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 xbpqN1_Yreej for ; Thu, 7 Mar 2019 19:47:27 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 A8041131298 for ; Thu, 7 Mar 2019 19:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2id0BZxjNZbezCiaTc8ypVfTTQ/wVLHFMXDbzKC5l+k=; b=MlCROC77WyHA69kXDCZUf88r5 Smy8FeIfw4N0DESiZLstGuvQO8px6ibHA8hpSGsiZSBX6S4kvU6e2ZaWRqAaTX/iw6tcDvXbGOeJ/ VqZQI7vXKLOMYFSui/eVU4g2polqcMdybsDkJ4NPbX5gojl2ETMjoiz8aQ1eWmcofDBtdjMkcDubc e9ZgPTf61wL04e79pCPZsr+Y4hW4h0elBChxz96W70IV29UbAGQ7b/cDpP/7WAlyZECQR0SS8MIBT Up+OEOCD6phOhZ1w8aVL9mGsCpAf7J4DEchON58D48PO47BFUxn5kzocMAEZqPLm+nC1ijcMsu2UE NZ35LqjHw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:56525 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h26Tk-001hfQ-CH; Thu, 07 Mar 2019 22:47:26 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_7F4CE0A7-9217-4A3F-9AA8-177D7CCF3C76" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <20190307212311.GA95604@bugle.employees.org> Date: Thu, 7 Mar 2019 19:47:22 -0800 Cc: tsvwg Message-Id: References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <20190307212311.GA95604@bugle.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 03:47:29 -0000 --Apple-Mail=_7F4CE0A7-9217-4A3F-9AA8-177D7CCF3C76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Derek, > On Mar 7, 2019, at 1:23 PM, Derek Fawcus = wrote: >=20 > I believe the result of the CCO experiment was that it, or this new = OCS, > would always have to be present in order to guarentee a packet passes > through certain middleboxes. Except possibly th the case where the > UDP header checksum is zero? >=20 > Given that wouldn't it make sense for this option to be both mandatory = to > implement, and always present in the options area? >=20 > DF You=E2=80=99ve already partly answered your own question. The other case is ACS, in which case (currently) there would be no OCS. = It would be somewhat wasteful in both space and computation to include = both, unless passing such middle boxes is needed. Note - traversal of incorrectly implemented middle boxes is not a = primary design consideration for UDP options. We are absolutely not = designing a =E2=80=9Cbyzantine=E2=80=9D protocol, i.e., one that = survives arbitrary attacks by intermediate boxes, whether deliberate or = accidental. Joe --Apple-Mail=_7F4CE0A7-9217-4A3F-9AA8-177D7CCF3C76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Derek,

On Mar 7, 2019, at 1:23 PM, Derek Fawcus = <dfawcus+lists-tsvwg@employees.org> wrote:

I believe the result of the CCO = experiment was that it, or this new OCS,
would always have to be present in order to guarentee a = packet passes
through = certain middleboxes.  Except possibly th the case where = the
UDP header = checksum is zero?

Given that wouldn't it make sense for this option to be both = mandatory to
implement, = and always present in the options area?

DF

You=E2=80= =99ve already partly answered your own question.

The other case is ACS, in which case (currently) = there would be no OCS. It would be somewhat wasteful in both space and = computation to include both, unless passing such middle boxes is = needed.

Note - traversal of = incorrectly implemented middle boxes is not a primary design = consideration for UDP options. We are absolutely not designing a = =E2=80=9Cbyzantine=E2=80=9D protocol, i.e., one that survives arbitrary = attacks by intermediate boxes, whether deliberate or = accidental.

Joe

= --Apple-Mail=_7F4CE0A7-9217-4A3F-9AA8-177D7CCF3C76-- From nobody Thu Mar 7 19:48:47 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D0F13129F for ; Thu, 7 Mar 2019 19:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 6J-ZhWp_ldPP for ; Thu, 7 Mar 2019 19:48:44 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 68FB9131298 for ; Thu, 7 Mar 2019 19:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mQdSXeT5+6UtaRlFIBJGGMyciIh11U3zTUZBTwP1Sys=; b=M/QWPUwlqQs3TLsuOv9cgrpe/ dHwlZWa8jaPA85u0oAdpy66UrfiVajGLHsT8gO/S8eLmCGdikSOOqaXult7DAxfBLY5w7UTEGpO2+ DNsMeZujtx//DiiyqGYSY1LUH1ovoKplB3ZXNJ6zrzcvGFesXLdbeRl6L7MtKJMWgsf9s3FEoPi2o sMvUU4tm6tMfe47nUVxOxSXw2qF6X8b0OYyFxt9QEfeu3X/2YfJCYeAaUTft/CZHs9nul1Vocfma0 X306iegJuewUt1wLT+TFK1J8fPtofO7HW6NQGMMcoR6A5Ga6uSHzU674Nea+u4bE3SpPVRh+5aauz 0MNFhQ6dA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:56533 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h26V0-001ij7-0D; Thu, 07 Mar 2019 22:48:43 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_6950F20D-C15D-48BD-A079-72BD37634CDD" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Thu, 7 Mar 2019 19:48:40 -0800 Cc: "C. M. Heard" , tsvwg Message-Id: <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> To: raffaele X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 03:48:45 -0000 --Apple-Mail=_6950F20D-C15D-48BD-A079-72BD37634CDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 7, 2019, at 1:04 PM, raffaele wrote: >=20 > I would only add that the checksum has also to cover the 2 bytes = pseudo-header containing UDP Options length other than UDP Options area = bytes. There is no such pseudo header. It has been proposed, but it is not in = the current design. Joe --Apple-Mail=_6950F20D-C15D-48BD-A079-72BD37634CDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Mar 7, 2019, at 1:04 PM, raffaele <raffaele@erg.abdn.ac.uk> wrote:

I would only add that the = checksum has also to cover the 2 bytes pseudo-header containing UDP = Options length other than UDP Options area bytes.

There is no such = pseudo header. It has been proposed, but it is not in the current = design.

Joe

= --Apple-Mail=_6950F20D-C15D-48BD-A079-72BD37634CDD-- From nobody Thu Mar 7 23:10:07 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47942130E09 for ; Thu, 7 Mar 2019 23:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4a1vqcdLwIO for ; Thu, 7 Mar 2019 23:10:05 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id E60A0129C6A for ; Thu, 7 Mar 2019 23:10:04 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4C7AE1B0012D; Fri, 8 Mar 2019 07:09:59 +0000 (GMT) Message-ID: <5C821546.1020401@erg.abdn.ac.uk> Date: Fri, 08 Mar 2019 07:09:58 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joe Touch CC: Derek Fawcus , tsvwg References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <20190307212311.GA95604@bugle.employees.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 07:10:07 -0000 On 08/03/2019, 03:47, Joe Touch wrote: > Hi, Derek, > >> On Mar 7, 2019, at 1:23 PM, Derek Fawcus >> > > wrote: >> >> I believe the result of the CCO experiment was that it, or this new OCS, >> would always have to be present in order to guarentee a packet passes >> through certain middleboxes. Except possibly th the case where the >> UDP header checksum is zero? >> >> Given that wouldn't it make sense for this option to be both mandatory to >> implement, and always present in the options area? >> >> DF > > You’ve already partly answered your own question. > > The other case is ACS, in which case (currently) there would be no > OCS. It would be somewhat wasteful in both space and computation to > include both, unless passing such middle boxes is needed. > > Note - traversal of incorrectly implemented middle boxes is not a > primary design consideration for UDP options. We are absolutely not > designing a “byzantine” protocol, i.e., one that survives arbitrary > attacks by intermediate boxes, whether deliberate or accidental. > > Joe > To be clear: This is not just a middlebox, NAT, etc consideration, there are also hosts that offload UDP option checks, that can black-hole the UDP Options that do not have the "CCO" like OCS value. As an individual in the IETF (rather than the WG Chair), I think your note is a fair point for more discussion about whether we should design for deployability. It seems that a large number of people in the QUIC WG are specifically designing their new transport to optimise the chance of working through network paths that have middleboxes. At least with respect to IPv4, I could see merit in requiring the OCS in the options area. Gorry From nobody Thu Mar 7 23:16:58 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E02130EC1 for ; Thu, 7 Mar 2019 23:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 n8EXz7HB9ipY for ; Thu, 7 Mar 2019 23:16:55 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 48929129C6A for ; Thu, 7 Mar 2019 23:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6JcF3FpCno1WWMcZ6JhfnEOImKFrriSUCbpuavkMDl4=; b=P2X/ylnIi4EBpN6peO+YFD4nJA 9Lk/IybHHqf+XmlrB+7irwpSx69+2eBkpLfTGKzKw3vG8/QGMNOmyne383ElJq5HcUclaRk+T8oUw wXFnWcd1/5woy2PEHp/QzZYjan/i3qsw0NRtK4+e/fxQAoQXIu5a2NXjw1ZfBBJtrAIaJ02kK7Xpk N+VA3MTaxauATsjBKcjpT/d859za6Ru7ol9huUJIGsTQ0k71zwP8nw61nvtkHgeRAtjDQmeKxQVPV y29GDuqnH3hPYhgc42utO3CMVHIR5oYNqntl7e7bIGc6Zmn4YQ3hfK2FUzC0cEyc/391/P6EUty1A WAIZgayw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:65278 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h29kO-000bol-DR; Fri, 08 Mar 2019 02:16:50 -0500 To: gorry@erg.abdn.ac.uk Cc: Derek Fawcus , tsvwg References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <20190307212311.GA95604@bugle.employees.org> <5C821546.1020401@erg.abdn.ac.uk> From: Joe Touch Message-ID: <491381c9-b355-5c8d-dde0-5ce8a3a4420e@strayalpha.com> Date: Thu, 7 Mar 2019 23:16:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <5C821546.1020401@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 07:16:56 -0000 Hi, Gorry, Designing for deployability to me involves adapting to MAYs and exceptions to SHOULDs - i.e., legitimate deployment options. Designing to overcome bugs or deliberate deviations from specs is a losing battle. It helps endorse and entrench bad behavior and undermines the very nature of specs. If that's where we are, let's all save each other's time and call it the "wild west". In this specific case, there's a cost to requiring OCS - additional effort exactly where it users decide it isn't needed (e.g., when UDP CS=0 or the entire packet is covered by another layer, such as protected tunneled transit) or where they decide the IP sum isn't enough (e.g, when using ACS). The default can be to include it, but IMO that's as much as we should do here. Joe On 3/7/2019 11:09 PM, Gorry Fairhurst wrote: > On 08/03/2019, 03:47, Joe Touch wrote: >> Hi, Derek, >> >>> On Mar 7, 2019, at 1:23 PM, Derek Fawcus >>> >> > wrote: >>> >>> I believe the result of the CCO experiment was that it, or this new >>> OCS, >>> would always have to be present in order to guarentee a packet passes >>> through certain middleboxes.  Except possibly th the case where the >>> UDP header checksum is zero? >>> >>> Given that wouldn't it make sense for this option to be both >>> mandatory to >>> implement, and always present in the options area? >>> >>> DF >> >> You’ve already partly answered your own question. >> >> The other case is ACS, in which case (currently) there would be no >> OCS. It would be somewhat wasteful in both space and computation to >> include both, unless passing such middle boxes is needed. >> >> Note - traversal of incorrectly implemented middle boxes is not a >> primary design consideration for UDP options. We are absolutely not >> designing a “byzantine” protocol, i.e., one that survives arbitrary >> attacks by intermediate boxes, whether deliberate or accidental. >> >> Joe >> > To be clear: This is not just a middlebox, NAT, etc consideration, > there are also hosts that offload UDP option checks, that can > black-hole the UDP Options that do not have the "CCO" like OCS value. > > As an individual in the IETF (rather than the WG Chair), I think your > note is a fair point for more discussion about whether we should > design for deployability. It seems that a large number of people in > the QUIC WG are specifically designing their new transport to optimise > the chance of working through network paths that have middleboxes. At > least with respect to IPv4, I could see merit in requiring the OCS in > the options area. > > Gorry > > From nobody Thu Mar 7 23:41:14 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBD7129532 for ; Thu, 7 Mar 2019 23:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 GL1VS3LU1fub for ; Thu, 7 Mar 2019 23:41:11 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 52D021271FF for ; Thu, 7 Mar 2019 23:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1a1cMXZaIjGMjW2e0FMYpoYqZLxIKmBkNMvGDGlIIX4=; b=fyElKukliJs/NOQj1hLuqNFe16 rZq+1uxvp5gjXqjUiAmJ5cYzOWy4sN+GeeDK8AALbnnT7lsKN0ttThzA3buauObiJrMnR42qfs3di bdW26lUk8K5aLCSQ5DOHe8yakUbfqJT26ULZ8X0gxov92a7Cy8K1sbtQ/JnSHtn1mZQ/HgV3RQkuB /yHOUdhoSb+Nr2L3yTYgEpjM3NF0Lp2/Q1XpqDJ6ixT8LefZDaybWC7jT9XnK2wsn0FmE5aG2Wad6 zNdCnOBYKHZ3880YxsDKB94FDH2dmRpBQsWYuTNA4WfM2BUETew+/yfNG5S4wk2YXG/rTiitKmCcE nk81uZJA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:65486 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h2A7w-0011q5-A8; Fri, 08 Mar 2019 02:41:09 -0500 To: Derek Fawcus , tsvwg References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <20190307212311.GA95604@bugle.employees.org> From: Joe Touch Message-ID: Date: Thu, 7 Mar 2019 23:41:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190307212311.GA95604@bugle.employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 07:41:13 -0000 Derek, On 3/7/2019 1:23 PM, Derek Fawcus wrote: > I don't think that is necessary for it to be first, as long as the 16 bits > of checksum are correctly aligned for how they're swapped, the checksum > can be at any offset in the payload. Yes - this is true. We should be able to ignore any of the other constraints and simply compute OCS over the entire checksum area, so long as the result is inserted with the same alignment as it is computed. I.e., if the checksum field is word-aligned to the start of the option area, then insert the calculated value (regardless of the alignment of the option area start relative to the native alignment of memory). Otherwise swap the bytes. ----- Note, however, there's a problem with LITE: the whole point of LITE is that it is not checksummed. We can't make OCS cover the LITE area - that would be the opposite of our goal. And we can't force the LITE area to be aligned. So AFAICT although OCS will still work, it won't fix the bug - nor will CCO - for either LITE or LITE+FRAG. Joe From nobody Fri Mar 8 00:19:23 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073CD1279E6 for ; Fri, 8 Mar 2019 00:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNHhTatsZXWD for ; Fri, 8 Mar 2019 00:19:19 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 07EA71271FF for ; Fri, 8 Mar 2019 00:19:18 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3ABE61B00108; Fri, 8 Mar 2019 08:19:12 +0000 (GMT) Message-ID: <5C82257F.5030505@erg.abdn.ac.uk> Date: Fri, 08 Mar 2019 08:19:11 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joe Touch CC: "qiangli (D)" , Toerless Eckert , "tsvwg@ietf.org" References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> In-Reply-To: <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 08:19:22 -0000 I'm really encouraging you to do a quick revision: It would be really helpful if you did the update suggested by Joe, to align so it's conformant with the way in which the assignments are supposed to be made. A few quick observations on the -00 draft: (1) Please replace the "KIND" number with the text "TBD", and see Joe's comment on the IANA section. (2) This may is a chance to fix this typo that occurs several places: /filed/field/. (3) Is Length in figure 5 really 1 byte? This is the total length of the option, and I see you have at least one byte additional. Is your length of the option variable or fixed? (4) I don't understand this: "One way to relieve in-transit rewriting is to pre-compute the sending cycles along the way, then carry them with multiple SC options." I wonder: Do you imagine the path adds options as the packet travels through the routers? Or is this a suggestion that the option field can have multiple values present within this? These are quite different proposals, and I suggest you place this text in a separate subsection? Best wishes, Gorry On 08/03/2019, 03:43, Joe Touch wrote: > Two points (the first is useful for everyone developing upcoming UDP > options): > > 1. proposals for new UDP options should indicate a KIND value of “TBD” > only; they should not ‘squat’ or preselect a value until assigned by > IANA (when the UDP options doc is published) or - until the UDP doc is > published - at least the doc is accepted as a WG doc. > > 2. a request for such assignment should be included in the IANA > considerations portion of that document > > These are common conventions for assigned numbers in general. > > As a result, I encourage the authors to quickly issue an update to > this doc that follows the above convention. > > Additionally, if accepted, can you explain why it wouldn’t be > sufficient to just request the next open value? > > Joe > >> On Mar 7, 2019, at 5:22 PM, qiangli (D) > > wrote: >> >> Hi All, >> We have uploaded a new draft >> (draft-qiang-tsvwg-udp-options-bounded-latency-00) that explores the >> use of UDP options for bounded latency forwarding. Review and comment >> is highly appreciated. >> Best regards, >> Cristina QIANG >> ============================================== >> A new version of I-D, >> draft-qiang-tsvwg-udp-options-bounded-latency-00.txt >> has been successfully submitted by Li Qiang and posted to the IETF >> repository. >> Name: draft-qiang-tsvwg-udp-options-bounded-latency >> Revision: 00 >> Title: UDP Options for Bounded Latency >> Document date: 2019-03-08 >> Group: Individual Submission >> Pages: 9 >> URL: >> https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-bounded-latency-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounded-latency/ >> Htmlized: >> https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-latency-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-bounded-latency >> Abstract: >> This document explores the use of UDP options for packet forwarding >> with bounded latency. >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available >> attools.ietf.org . >> The IETF Secretariat > From nobody Fri Mar 8 00:51:31 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34881131322 for ; Fri, 8 Mar 2019 00:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ljU6ZA6ZQ0q for ; Fri, 8 Mar 2019 00:51:26 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C52131321 for ; Fri, 8 Mar 2019 00:51:25 -0800 (PST) Received: by bugle.employees.org (Postfix, from userid 1736) id 6F928FECBF24; Fri, 8 Mar 2019 08:51:25 +0000 (UTC) Date: Fri, 8 Mar 2019 08:51:25 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20190308085125.GA26563@bugle.employees.org> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <20190307212311.GA95604@bugle.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 08:51:28 -0000 On Thu, Mar 07, 2019 at 07:47:22PM -0800, Joe Touch wrote: > > The other case is ACS, in which case (currently) there would be no OCS. It would be somewhat wasteful in both space and computation to include both, unless passing such middle boxes is needed. Except (as I recall) isn't the ACS intended to cover the base UDP payload? So they perform different purposes, and this ACS case would only apply when and if the UDP options are being used to carry ACS alone. As soon as some other option is also present together with ACS, the case for OCS being present arises. (One could argue that OCS adds value in the ACS alone case, as it allows the presence & use of the options hence ACS to be validated.) DF From nobody Fri Mar 8 02:44:23 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D3F1277D0 for ; Fri, 8 Mar 2019 02:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJNTTiedvj1y for ; Fri, 8 Mar 2019 02:44:18 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A7E8A126E5C for ; Fri, 8 Mar 2019 02:44:17 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 704A394FB9C0BA2E3B72; Fri, 8 Mar 2019 10:44:15 +0000 (GMT) Received: from DGGEMI424-HUB.china.huawei.com (10.1.199.153) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Mar 2019 10:44:14 +0000 Received: from DGGEMI529-MBS.china.huawei.com ([169.254.5.238]) by DGGEMI424-HUB.china.huawei.com ([10.1.199.153]) with mapi id 14.03.0399.000; Fri, 8 Mar 2019 18:44:07 +0800 From: "qiangli (D)" To: "gorry@erg.abdn.ac.uk" , Joe Touch CC: Toerless Eckert , "tsvwg@ietf.org" Thread-Topic: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) Thread-Index: AdTVTUw267hC5GTQTZyGvOBVjR2e1///oZEAgABM8YD//1lE4A== Date: Fri, 8 Mar 2019 10:44:06 +0000 Message-ID: <06C389826B926F48A557D5DB5A54C4ED45BE97A1@dggemi529-mbs.china.huawei.com> References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> <5C82257F.5030505@erg.abdn.ac.uk> In-Reply-To: <5C82257F.5030505@erg.abdn.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 10:44:21 -0000 SGkgSm9lIGFuZCBHb3JyeSwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBXaWxs IG1ha2UgbW9kaWZpY2F0aW9uIGFjY29yZGluZ2x5IGFuZCB1cGRhdGUgYmVmb3JlIElFVEYgMTA0 IG1lZXRpbmcuIA0KDQo+PigzKSBJcyBMZW5ndGggaW4gZmlndXJlIDUgcmVhbGx5IDEgYnl0ZT8g VGhpcyBpcyB0aGUgdG90YWwgbGVuZ3RoIG9mIHRoZSBvcHRpb24sIGFuZCBJIHNlZSB5b3UgaGF2 ZSBhdCBsZWFzdCBvbmUgYnl0ZSBhZGRpdGlvbmFsLiBJcyB5b3VyIGxlbmd0aCBvZiB0aGUgb3B0 aW9uIHZhcmlhYmxlIG9yIGZpeGVkPw0KDQpZZXMsIDEgYnl0ZSBpcyBlbm91Z2guIFNpbmNlIGVh Y2ggbm9kZSBoYXMgMyBxdWV1ZXMsIG5lZWQgbWluaW1hbCAyIGJpdHMgKDQgZGlmZmVyZW50IHZh bHVlcykgdG8gaW5kaWNhdGUgd2hpY2ggcXVldWUgYSBwYWNrZXQgc2hvdWxkIGVudGVyLg0KDQoN Cj4+ICJPbmUgd2F5IHRvIHJlbGlldmUgaW4tdHJhbnNpdCByZXdyaXRpbmcgaXMgdG8gcHJlLWNv bXB1dGUgdGhlIHNlbmRpbmcNCiAgICBjeWNsZXMgYWxvbmcgdGhlIHdheSwgdGhlbiBjYXJyeSB0 aGVtIHdpdGggbXVsdGlwbGUgU0Mgb3B0aW9ucy4iDQoNClRoZSAyIGJpdHMnIHZhbHVlIHdpbGwg YmUgY2hhbmdlZC9yZXdyaXR0ZW4gaG9wLWJ5LWhvcCwgdGhhdCBpcyB3aGF0IHdlIGNhbGwgIiBp bi10cmFuc2l0IHJld3JpdGluZyAiIC0tLS0gU1dBUCBtZXRob2QNCldlIG1heSB1c2UgU1RBQ0sg bWV0aG9kIHRvIHJlZHVjZSBzdWNoICIgaW4tdHJhbnNpdCByZXdyaXRpbmcgIi4gV2lsbCByZWZp bmUgdGhpcyBwYXJ0IGluIDAxIHZlcnNpb24uIA0KDQo+PiB3aHkgaXQgd291bGRu4oCZdCBiZSBz dWZmaWNpZW50IHRvIGp1c3QgcmVxdWVzdCB0aGUgbmV4dCBvcGVuIHZhbHVlPw0KVGhlIHJlYXNv biB0aGF0IHdoeSB3ZSB3cm90ZSAiMTI3IiBpcyAiMTI3LTI1MyIgaXMgYSByZXNlcnZlZCByZWdp b24gZGVmaW5lZCBpbiBkcmFmdC1pZXRmLXRzdndnLXVkcC1vcHRpb25zLTA2LCB3aWxsIGNoYW5n ZSAiMTI3IiB0byAiVEJEIiBpbiAwMSB2ZXJzaW9uLiBUaGFuayB5b3UgYWdhaW4uDQoNCg0KQmVz dCByZWdhcmRzLA0KDQpDcmlzdGluYSBRSUFORw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBHb3JyeSBGYWlyaHVyc3QgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10g DQpTZW50OiBGcmlkYXksIE1hcmNoIDA4LCAyMDE5IDQ6MTkgUE0NClRvOiBKb2UgVG91Y2ggPHRv dWNoQHN0cmF5YWxwaGEuY29tPg0KQ2M6IHFpYW5nbGkgKEQpIDxxaWFuZ2xpM0BodWF3ZWkuY29t PjsgVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPjsgdHN2d2dAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbdHN2d2ddIEEgTmV3IERyYWZ0IFVwbG9hZGVkIChkcmFmdC1xaWFuZy10c3Z3Zy11 ZHAtb3B0aW9ucy1ib3VuZGVkLWxhdGVuY3ktMDApDQoNCkknbSByZWFsbHkgZW5jb3VyYWdpbmcg eW91IHRvIGRvIGEgcXVpY2sgcmV2aXNpb246IEl0IHdvdWxkIGJlIHJlYWxseSBoZWxwZnVsIGlm IHlvdSBkaWQgdGhlIHVwZGF0ZSBzdWdnZXN0ZWQgYnkgSm9lLCB0byBhbGlnbiBzbyBpdCdzIGNv bmZvcm1hbnQgd2l0aCB0aGUgd2F5IGluIHdoaWNoIHRoZSBhc3NpZ25tZW50cyBhcmUgc3VwcG9z ZWQgdG8gYmUgbWFkZS4NCg0KQSBmZXcgcXVpY2sgb2JzZXJ2YXRpb25zIG9uIHRoZSAtMDAgZHJh ZnQ6DQoNCigxKSBQbGVhc2UgcmVwbGFjZSB0aGUgIktJTkQiIG51bWJlciB3aXRoIHRoZSB0ZXh0 ICJUQkQiLCBhbmQgc2VlIEpvZSdzIGNvbW1lbnQgb24gdGhlIElBTkEgc2VjdGlvbi4NCg0KKDIp IFRoaXMgbWF5IGlzIGEgY2hhbmNlIHRvIGZpeCB0aGlzIHR5cG8gdGhhdCBvY2N1cnMgc2V2ZXJh bCBwbGFjZXM6IA0KL2ZpbGVkL2ZpZWxkLy4NCg0KKDMpIElzIExlbmd0aCBpbiBmaWd1cmUgNSBy ZWFsbHkgMSBieXRlPyBUaGlzIGlzIHRoZSB0b3RhbCBsZW5ndGggb2YgdGhlIG9wdGlvbiwgYW5k IEkgc2VlIHlvdSBoYXZlIGF0IGxlYXN0IG9uZSBieXRlIGFkZGl0aW9uYWwuIElzIHlvdXIgbGVu Z3RoIG9mIHRoZSBvcHRpb24gdmFyaWFibGUgb3IgZml4ZWQ/DQoNCig0KSBJIGRvbid0IHVuZGVy c3RhbmQgdGhpczoNCg0KICAgIk9uZSB3YXkgdG8gcmVsaWV2ZSBpbi10cmFuc2l0IHJld3JpdGlu ZyBpcyB0byBwcmUtY29tcHV0ZSB0aGUgc2VuZGluZw0KICAgIGN5Y2xlcyBhbG9uZyB0aGUgd2F5 LCB0aGVuIGNhcnJ5IHRoZW0gd2l0aCBtdWx0aXBsZSBTQyBvcHRpb25zLiINCg0KSSB3b25kZXI6 IERvIHlvdSBpbWFnaW5lIHRoZSBwYXRoIGFkZHMgb3B0aW9ucyBhcyB0aGUgcGFja2V0IHRyYXZl bHMgdGhyb3VnaCB0aGUgcm91dGVycz8gT3IgaXMgdGhpcyBhIHN1Z2dlc3Rpb24gdGhhdCB0aGUg b3B0aW9uIGZpZWxkIGNhbiBoYXZlIG11bHRpcGxlIHZhbHVlcyBwcmVzZW50IHdpdGhpbiB0aGlz PyAgVGhlc2UgYXJlIHF1aXRlIGRpZmZlcmVudCBwcm9wb3NhbHMsIGFuZCBJIHN1Z2dlc3QgeW91 IHBsYWNlIHRoaXMgdGV4dCBpbiBhIHNlcGFyYXRlIHN1YnNlY3Rpb24/DQoNCkJlc3Qgd2lzaGVz LA0KDQpHb3JyeQ0KDQoNCk9uIDA4LzAzLzIwMTksIDAzOjQzLCBKb2UgVG91Y2ggd3JvdGU6DQo+ IFR3byBwb2ludHMgKHRoZSBmaXJzdCBpcyB1c2VmdWwgZm9yIGV2ZXJ5b25lIGRldmVsb3Bpbmcg dXBjb21pbmcgVURQDQo+IG9wdGlvbnMpOg0KPg0KPiAxLiBwcm9wb3NhbHMgZm9yIG5ldyBVRFAg b3B0aW9ucyBzaG91bGQgaW5kaWNhdGUgYSBLSU5EIHZhbHVlIG9mIOKAnFRCROKAnSANCj4gb25s eTsgdGhleSBzaG91bGQgbm90IOKAmHNxdWF04oCZIG9yIHByZXNlbGVjdCBhIHZhbHVlIHVudGls IGFzc2lnbmVkIGJ5IA0KPiBJQU5BICh3aGVuIHRoZSBVRFAgb3B0aW9ucyBkb2MgaXMgcHVibGlz aGVkKSBvciAtIHVudGlsIHRoZSBVRFAgZG9jIGlzIA0KPiBwdWJsaXNoZWQgLSBhdCBsZWFzdCB0 aGUgZG9jIGlzIGFjY2VwdGVkIGFzIGEgV0cgZG9jLg0KPg0KPiAyLiBhIHJlcXVlc3QgZm9yIHN1 Y2ggYXNzaWdubWVudCBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlIElBTkEgDQo+IGNvbnNpZGVy YXRpb25zIHBvcnRpb24gb2YgdGhhdCBkb2N1bWVudA0KPg0KPiBUaGVzZSBhcmUgY29tbW9uIGNv bnZlbnRpb25zIGZvciBhc3NpZ25lZCBudW1iZXJzIGluIGdlbmVyYWwuDQo+DQo+IEFzIGEgcmVz dWx0LCBJIGVuY291cmFnZSB0aGUgYXV0aG9ycyB0byBxdWlja2x5IGlzc3VlIGFuIHVwZGF0ZSB0 byANCj4gdGhpcyBkb2MgdGhhdCBmb2xsb3dzIHRoZSBhYm92ZSBjb252ZW50aW9uLg0KPg0KPiBB ZGRpdGlvbmFsbHksIGlmIGFjY2VwdGVkLCBjYW4geW91IGV4cGxhaW4gd2h5IGl0IHdvdWxkbuKA mXQgYmUgDQo+IHN1ZmZpY2llbnQgdG8ganVzdCByZXF1ZXN0IHRoZSBuZXh0IG9wZW4gdmFsdWU/ DQo+DQo+IEpvZQ0KPg0KPj4gT24gTWFyIDcsIDIwMTksIGF0IDU6MjIgUE0sIHFpYW5nbGkgKEQp IDxxaWFuZ2xpM0BodWF3ZWkuY29tIA0KPj4gPG1haWx0bzpxaWFuZ2xpM0BodWF3ZWkuY29tPj4g d3JvdGU6DQo+Pg0KPj4gSGkgQWxsLA0KPj4gV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyBkcmFmdA0K Pj4gKGRyYWZ0LXFpYW5nLXRzdndnLXVkcC1vcHRpb25zLWJvdW5kZWQtbGF0ZW5jeS0wMCkgdGhh dCBleHBsb3JlcyB0aGUgDQo+PiB1c2Ugb2YgVURQIG9wdGlvbnMgZm9yIGJvdW5kZWQgbGF0ZW5j eSBmb3J3YXJkaW5nLiBSZXZpZXcgYW5kIGNvbW1lbnQgDQo+PiBpcyBoaWdobHkgYXBwcmVjaWF0 ZWQuDQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBDcmlzdGluYSBRSUFORw0KPj4gPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsDQo+PiBkcmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0aW9ucy1ib3VuZGVkLWxhdGVuY3ktMDAu dHh0DQo+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExpIFFpYW5nIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgDQo+PiByZXBvc2l0b3J5Lg0KPj4gTmFtZTogICAgICAgICAgICAg ICBkcmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0aW9ucy1ib3VuZGVkLWxhdGVuY3kNCj4+IFJldmlz aW9uOiAgMDANCj4+IFRpdGxlOiAgICAgICAgICAgICAgICAgIFVEUCBPcHRpb25zIGZvciBCb3Vu ZGVkIExhdGVuY3kNCj4+IERvY3VtZW50IGRhdGU6ICAgICAgIDIwMTktMDMtMDgNCj4+IEdyb3Vw OiAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4gUGFnZXM6ICAgICAgICAg ICAgICAgOQ0KPj4gVVJMOiANCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0aW9ucy1ibw0KPj4gdW5kZWQtbGF0ZW5jeS0wMC50 eHQNCj4+IFN0YXR1czogDQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1xaWFuZy10c3Z3Zy11ZHAtb3B0aW9ucy1ib3VuZGUNCj4+IGQtbGF0ZW5jeS8NCj4+IEh0bWxp emVkOiANCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xaWFuZy10c3Z3Zy11 ZHAtb3B0aW9ucy1ib3VuZGVkLWxhdA0KPj4gZW5jeS0wMA0KPj4gSHRtbGl6ZWQ6IA0KPj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1xaWFuZy10c3Z3Zy11ZHAt b3B0aW9ucy1iDQo+PiBvdW5kZWQtbGF0ZW5jeQ0KPj4gQWJzdHJhY3Q6DQo+PiAgICBUaGlzIGRv Y3VtZW50IGV4cGxvcmVzIHRoZSB1c2Ugb2YgVURQIG9wdGlvbnMgZm9yIHBhY2tldCBmb3J3YXJk aW5nDQo+PiAgICB3aXRoIGJvdW5kZWQgbGF0ZW5jeS4NCj4+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4gc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIA0K Pj4gYXR0b29scy5pZXRmLm9yZyA8aHR0cDovL3Rvb2xzLmlldGYub3JnLz4uDQo+PiBUaGUgSUVU RiBTZWNyZXRhcmlhdA0KPg0KDQo= From nobody Fri Mar 8 03:30:18 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5501277D8 for ; Fri, 8 Mar 2019 03:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTh0NKylrHAd for ; Fri, 8 Mar 2019 03:30:12 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9229812796C for ; Fri, 8 Mar 2019 03:30:10 -0800 (PST) Received: from [137.50.180.223] (oa-edu-180-223.wireless.abdn.ac.uk [137.50.180.223]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E3D6B1B0012D; Fri, 8 Mar 2019 11:30:04 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (16D57) In-Reply-To: <06C389826B926F48A557D5DB5A54C4ED45BE97A1@dggemi529-mbs.china.huawei.com> Date: Fri, 8 Mar 2019 11:30:04 +0000 Cc: Joe Touch , Toerless Eckert , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6CE801F4-C954-40A1-AD7C-80991796BE18@erg.abdn.ac.uk> References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> <5C82257F.5030505@erg.abdn.ac.uk> <06C389826B926F48A557D5DB5A54C4ED45BE97A1@dggemi529-mbs.china.huawei.com> To: "qiangli (D)" Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 11:30:16 -0000 See below. > On 8 Mar 2019, at 10:44, qiangli (D) wrote: >=20 > Hi Joe and Gorry, >=20 > Thanks a lot for your comments. Will make modification accordingly and upd= ate before IETF 104 meeting.=20 >=20 Great the cutoff is Monday. >>> (3) Is Length in figure 5 really 1 byte? This is the total length of the= option, and I see you have at least one byte additional. Is your length of t= he option variable or fixed? >=20 > Yes, 1 byte is enough. Since each node has 3 queues, need minimal 2 bits (= 4 different values) to indicate which queue a packet should enter. >=20 I see. >>> "One way to relieve in-transit rewriting is to pre-compute the sending > cycles along the way, then carry them with multiple SC options." >=20 > The 2 bits' value will be changed/rewritten hop-by-hop, that is what we ca= ll " in-transit rewriting " ---- SWAP method > We may use STACK method to reduce such " in-transit rewriting ". Will refi= ne this part in 01 version.=20 >=20 Ah I think changing the value isn=E2=80=99t allowed. The option fields are s= et by the sender and immutable - they may be readable in path, but the way t= hey are defined does not make it easy or desirable to change along the path.= >>> why it wouldn=E2=80=99t be sufficient to just request the next open valu= e? > The reason that why we wrote "127" is "127-253" is a reserved region defin= ed in draft-ietf-tsvwg-udp-options-06, will change "127" to "TBD" in 01 vers= ion. OK > Thank you again. >=20 >=20 > Best regards, >=20 > Cristina QIANG >=20 Gorry >=20 > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]=20 > Sent: Friday, March 08, 2019 4:19 PM > To: Joe Touch > Cc: qiangli (D) ; Toerless Eckert ; ts= vwg@ietf.org > Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-b= ounded-latency-00) >=20 > I'm really encouraging you to do a quick revision: It would be really help= ful if you did the update suggested by Joe, to align so it's conformant with= the way in which the assignments are supposed to be made. >=20 > A few quick observations on the -00 draft: >=20 > (1) Please replace the "KIND" number with the text "TBD", and see Joe's co= mment on the IANA section. >=20 > (2) This may is a chance to fix this typo that occurs several places:=20 > /filed/field/. >=20 > (3) Is Length in figure 5 really 1 byte? This is the total length of the o= ption, and I see you have at least one byte additional. Is your length of th= e option variable or fixed? >=20 > (4) I don't understand this: >=20 > "One way to relieve in-transit rewriting is to pre-compute the sending > cycles along the way, then carry them with multiple SC options." >=20 > I wonder: Do you imagine the path adds options as the packet travels throu= gh the routers? Or is this a suggestion that the option field can have multi= ple values present within this? These are quite different proposals, and I s= uggest you place this text in a separate subsection? >=20 > Best wishes, >=20 > Gorry >=20 >=20 >> On 08/03/2019, 03:43, Joe Touch wrote: >> Two points (the first is useful for everyone developing upcoming UDP >> options): >>=20 >> 1. proposals for new UDP options should indicate a KIND value of =E2=80=9C= TBD=E2=80=9D=20 >> only; they should not =E2=80=98squat=E2=80=99 or preselect a value until a= ssigned by=20 >> IANA (when the UDP options doc is published) or - until the UDP doc is=20= >> published - at least the doc is accepted as a WG doc. >>=20 >> 2. a request for such assignment should be included in the IANA=20 >> considerations portion of that document >>=20 >> These are common conventions for assigned numbers in general. >>=20 >> As a result, I encourage the authors to quickly issue an update to=20 >> this doc that follows the above convention. >>=20 >> Additionally, if accepted, can you explain why it wouldn=E2=80=99t be=20 >> sufficient to just request the next open value? >>=20 >> Joe >>=20 >>> On Mar 7, 2019, at 5:22 PM, qiangli (D) >> > wrote: >>>=20 >>> Hi All, >>> We have uploaded a new draft >>> (draft-qiang-tsvwg-udp-options-bounded-latency-00) that explores the=20 >>> use of UDP options for bounded latency forwarding. Review and comment=20= >>> is highly appreciated. >>> Best regards, >>> Cristina QIANG >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> A new version of I-D, >>> draft-qiang-tsvwg-udp-options-bounded-latency-00.txt >>> has been successfully submitted by Li Qiang and posted to the IETF=20 >>> repository. >>> Name: draft-qiang-tsvwg-udp-options-bounded-latency >>> Revision: 00 >>> Title: UDP Options for Bounded Latency >>> Document date: 2019-03-08 >>> Group: Individual Submission >>> Pages: 9 >>> URL:=20 >>> https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-bo >>> unded-latency-00.txt >>> Status:=20 >>> https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounde >>> d-latency/ >>> Htmlized:=20 >>> https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-lat >>> ency-00 >>> Htmlized:=20 >>> https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-b >>> ounded-latency >>> Abstract: >>> This document explores the use of UDP options for packet forwarding >>> with bounded latency. >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available=20 >>> attools.ietf.org . >>> The IETF Secretariat >>=20 >=20 From nobody Fri Mar 8 05:24:55 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690921279A1 for ; Fri, 8 Mar 2019 05:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdYacVzZt_00 for ; Fri, 8 Mar 2019 05:24:53 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA7D127598 for ; Fri, 8 Mar 2019 05:24:52 -0800 (PST) Received: by bugle.employees.org (Postfix, from userid 1736) id AA4EEFECBF5D; Fri, 8 Mar 2019 13:24:51 +0000 (UTC) Date: Fri, 8 Mar 2019 13:24:51 +0000 From: Derek Fawcus To: Derek Fawcus Cc: tsvwg Message-ID: <20190308132451.GA13712@bugle.employees.org> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <20190307212311.GA95604@bugle.employees.org> <20190308085125.GA26563@bugle.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190308085125.GA26563@bugle.employees.org> User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 13:24:54 -0000 On Fri, Mar 08, 2019 at 08:51:25AM +0000, Derek Fawcus wrote: > On Thu, Mar 07, 2019 at 07:47:22PM -0800, Joe Touch wrote: > > > > The other case is ACS, in which case (currently) there would be no OCS. It would be somewhat wasteful in both space and computation to include both, unless passing such middle boxes is needed. [snip] > this ACS case would only apply when and if the UDP options > are being used to carry ACS alone. As soon as some other option > is also present together with ACS, the case for OCS being present arises. Actually, I have to go back to my original position. Sending ACS alone w/o OCS could still suffer from the CCO highlighted deployability issue. Hence the only time options could be safely used w/o OCS would be when the UDP checksum was zero. So I guess we continue this in the deployability sub-thread. DF From nobody Fri Mar 8 05:26:08 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F5F127598 for ; Fri, 8 Mar 2019 05:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWmDmdBXLqyT for ; Fri, 8 Mar 2019 05:26:05 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C64A1279A1 for ; Fri, 8 Mar 2019 05:26:05 -0800 (PST) Received: by bugle.employees.org (Postfix, from userid 1736) id 4E0AEFECBF26; Fri, 8 Mar 2019 13:26:05 +0000 (UTC) Resent-From: Derek Fawcus Resent-Date: Fri, 8 Mar 2019 13:26:05 +0000 Resent-Message-ID: <20190308132605.GB13712@bugle.employees.org> Resent-To: tsvwg@ietf.org Date: Fri, 8 Mar 2019 13:24:51 +0000 From: Derek Fawcus Cc: tsvwg Message-ID: <20190308132451.GA13712@bugle.employees.org> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <20190307212311.GA95604@bugle.employees.org> <20190308085125.GA26563@bugle.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190308085125.GA26563@bugle.employees.org> User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 13:26:06 -0000 On Fri, Mar 08, 2019 at 08:51:25AM +0000, Derek Fawcus wrote: > On Thu, Mar 07, 2019 at 07:47:22PM -0800, Joe Touch wrote: > > > > The other case is ACS, in which case (currently) there would be no OCS. It would be somewhat wasteful in both space and computation to include both, unless passing such middle boxes is needed. [snip] > this ACS case would only apply when and if the UDP options > are being used to carry ACS alone. As soon as some other option > is also present together with ACS, the case for OCS being present arises. Actually, I have to go back to my original position. Sending ACS alone w/o OCS could still suffer from the CCO highlighted deployability issue. Hence the only time options could be safely used w/o OCS would be when the UDP checksum was zero. So I guess we continue this in the deployability sub-thread. DF From nobody Fri Mar 8 08:02:52 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FF1126CFF for ; Fri, 8 Mar 2019 08:02:51 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 nd9vFtIRZVCR for ; Fri, 8 Mar 2019 08:02:48 -0800 (PST) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 7922A120106 for ; Fri, 8 Mar 2019 08:02:48 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id a48so21736765qtb.4 for ; Fri, 08 Mar 2019 08:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tvg78ZulB6KR/9NyC9ChIokVf0L0txseCIv24fvV7co=; b=VmYPQNfFG2PleGOpojPn7cZRl+eS7eSAH4EOiI2oWrkZVWwKqUMz6Bfz7BxwhwjuZj lKS42fKj+5yDZtMeDGxUxqX7VrokMRkaqUxWtS/Ebk25PEFekZ24QuzERKsgDDEGkX17 SkrxHEuBDM5FtINdDLXdLaBEAq3kNX767VFkm8UloxzNsZijadsp+M21lGefj2TeXcsN OdWhiUw60nyzQU/6sUB85cfjmiG9yR26ZramtgFMvk0Lvl8yfvsplEIlLKK+hgJLFFUq PtnKE+NaAqHd6+2+9rDbH4m3x8BvAuo4/rEXVtWrlh2lmS/keEp5MCMSbuLo8a9Nu4kW PekA== 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=Tvg78ZulB6KR/9NyC9ChIokVf0L0txseCIv24fvV7co=; b=j2JO2okXVIx8MusT/shmWQqSYQB0yLx271edkUIWCzveX1M8NzrAfQiNkmJbaYBnjm OTfsQqigpzIzFVT4tN6/gaC36P6uw9jxcAiz7T8lMSG3eKJ2PSNqwg818WFGEhkZ8Tc0 42LAI5Tjprvb1t6qMmrU5U4QlrxJ2DvXQS0/SBt2THeSjGLfnry/LDzlrxDtsTv8vfQv g5zEz4sRH2VaUeS9L0BvIHAHqyEvFUNEllfgzP4qswo2RfCfwO22lWed0Bso2Y8bkX5i T8lXHXzcW5xy+Y2/Ij67h63GXNiILwb4PAwSla6Wcg86kf99UVJcojMT5dDnRovYOUo7 FGfg== X-Gm-Message-State: APjAAAW1yhKg5WZHv59KsiQEd71w66LojzhzoP1TpxE7rLR+3baD5jQi ewCpsRaxoU+i7k++oFNJfIQiEhnRScs6CI3jYJpdMA== X-Google-Smtp-Source: APXvYqw24B/CycZnWEWJ4JtwF7pm6mPqgOG2IJ958DzyhhBfzsibSmGbz/GspwsvuKKv+VDU8PzNSO132EMrdssukLc= X-Received: by 2002:ac8:1695:: with SMTP id r21mr15506701qtj.226.1552060967279; Fri, 08 Mar 2019 08:02:47 -0800 (PST) MIME-Version: 1.0 References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> In-Reply-To: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> From: Tom Herbert Date: Fri, 8 Mar 2019 08:02:36 -0800 Message-ID: To: "qiangli (D)" Cc: tsvwg , Toerless Eckert Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 16:02:51 -0000 On Thu, Mar 7, 2019 at 5:22 PM qiangli (D) wrote: > > Hi All, > > > > We have uploaded a new draft (draft-qiang-tsvwg-udp-options-bounded-latency-00) that explores the use of UDP options for bounded latency forwarding. Review and comment is highly appreciated. > Hi Cristina, One comment. >From the draft: "However in an IP data plane, there is no enough space in the IP common header." This is what extension headers are designed for. The draft is describing what should be a new Hop-by-Hop option. Also, I don't think router vendors are going to be very happy if they have to start parsing packet trailers in the high performance data path. Tom > > > > > Best regards, > > > > Cristina QIANG > > > > > > ============================================== > > A new version of I-D, draft-qiang-tsvwg-udp-options-bounded-latency-00.txt > > has been successfully submitted by Li Qiang and posted to the IETF repository. > > > > Name: draft-qiang-tsvwg-udp-options-bounded-latency > > Revision: 00 > > Title: UDP Options for Bounded Latency > > Document date: 2019-03-08 > > Group: Individual Submission > > Pages: 9 > > URL: https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-bounded-latency-00.txt > > Status: https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounded-latency/ > > Htmlized: https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-latency-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-bounded-latency > > > > > > Abstract: > > This document explores the use of UDP options for packet forwarding > > with bounded latency. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > From nobody Fri Mar 8 08:50:01 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F8E12008F for ; Fri, 8 Mar 2019 08:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 V186j6eLi_EV for ; Fri, 8 Mar 2019 08:49:58 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 2F078124B91 for ; Fri, 8 Mar 2019 08:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=P2Yeql9iSvruVz7sdVYKpa+kUd9alFzjcO5q+5me8Vw=; b=kX+eg9+1I1Z9ISZlOz6VjM+CWy d9Rb4JSGdtzI053MdMr8FY0JttyG2ptgtj5no6zw6TFWXLThXxE7gV29CtRT0uyuQMu8yPcdYL12t tL7CAy6C5dKBK/xYBkvTfsLaOCH51v5GkCXuqi+IDiemaCydVPPwLPRYEsoEwyATAqq/VzTE8datV xiReVs3c3SRM1AzFjDdS5P1oTzYS15hEG82lzk/RxFUqoEFAJGo8jragWBcjoEe3UuVXuF/86jyAo 2X7CCaJlo/C1xGGTThas0aTpcUXD8c2DPhlP8TrEQDxpPaKkZqYUGfKyqwY1MzTw/dhs7W/1tboae AAISVfeg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51452 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h2Igz-001OnF-8d; Fri, 08 Mar 2019 11:49:54 -0500 To: Derek Fawcus , tsvwg References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <20190307212311.GA95604@bugle.employees.org> <20190308085125.GA26563@bugle.employees.org> From: Joe Touch Message-ID: <674697e3-de98-92b5-6fd0-1912fbdcf0a0@strayalpha.com> Date: Fri, 8 Mar 2019 08:49:53 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190308085125.GA26563@bugle.employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 16:49:59 -0000 On 3/8/2019 12:51 AM, Derek Fawcus wrote: > On Thu, Mar 07, 2019 at 07:47:22PM -0800, Joe Touch wrote: >> The other case is ACS, in which case (currently) there would be no OCS. It would be somewhat wasteful in both space and computation to include both, unless passing such middle boxes is needed. > Except (as I recall) isn't the ACS intended to cover the base UDP payload? You're right; in my rush to get the update out, I got spun around on that one... The bigger issue is LITE and FRAG+LITE. Even if OCS is present, it won't help either case get past these bugs. --- That said, I'm going to suggest a more productive track than this rat-hole of gaming a bug. Pure and simple - NAME NAMES. If there is a system that you know of that does this errant thing, tell us the make, model, and firmware/sw version. Let's contact the vendor and get them fixed. That is the only useful way forward - especially because LITE+FRAG is a key expected use case. Joe From nobody Fri Mar 8 09:08:57 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62671313DC for ; Fri, 8 Mar 2019 09:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=strayalpha.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 P4S6m70hZw4v for ; Fri, 8 Mar 2019 09:08:55 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 25A111313D3 for ; Fri, 8 Mar 2019 09:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bb3LkiVQZwfJzLIEWyhFiGMvZtc/TUYyUwlcyq5b/JE=; b=i2TPIhgOiSx6VFh750yEO2S84 qmucmNgugDnjYBg0jh1PSADeFCezhSFXwTWNs0XwNYWaEIiarLORTWjijaj0LXFIjRCcJ0LAkbhEy mTdcIjbPXKsbXI3/mgBLQcjKpPCaTHPpLPqo6UtlBpuU/GRLFXu/Wn06V3I/ZNdJ2Ns/F5nT3eESe 1zC8CEjAAh90SUIC8TCgfAqk2pzsQYtMBfbt+KEP/LodZERzj8niiHX0wqeFGTRUQQ+BKYSLxC4j2 gH4ij6wI6tYUpj7qGYsC11syQbrrBTFjFtp+F05gwZ1XS0VbXwwTZsBRCcT3xy881VXr7B3VDou6c MaXdDCkAQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51601 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h2IzI-001jRy-CA; Fri, 08 Mar 2019 12:08:49 -0500 To: "qiangli (D)" , "gorry@erg.abdn.ac.uk" Cc: Toerless Eckert , "tsvwg@ietf.org" References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> <5C82257F.5030505@erg.abdn.ac.uk> <06C389826B926F48A557D5DB5A54C4ED45BE97A1@dggemi529-mbs.china.huawei.com> From: Joe Touch Message-ID: <7d691ac5-3655-59ac-60cc-221b6a39717e@strayalpha.com> Date: Fri, 8 Mar 2019 09:08:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <06C389826B926F48A557D5DB5A54C4ED45BE97A1@dggemi529-mbs.china.huawei.com> Content-Type: multipart/alternative; boundary="------------437D511ED7F0A542BB07264F" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 17:08:56 -0000 This is a multi-part message in MIME format. --------------437D511ED7F0A542BB07264F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Notes below... On 3/8/2019 2:44 AM, qiangli (D) wrote: >>> "One way to relieve in-transit rewriting is to pre-compute the sending > cycles along the way, then carry them with multiple SC options." > > The 2 bits' value will be changed/rewritten hop-by-hop, that is what we call " in-transit rewriting " ---- SWAP method > We may use STACK method to reduce such " in-transit rewriting ". Will refine this part in 01 version. UDP options MUST NOT change in-transit. (anything that does change in-transit would not be eligible for a UDP option KIND assignment). So it would be useful for this rev to describe ONLY the case where it is immutable. > >>> why it wouldn’t be sufficient to just request the next open value? > The reason that why we wrote "127" is "127-253" is a reserved region defined in draft-ietf-tsvwg-udp-options-06, ... I'll note that "reserved" means you won't get those; they're set aside for base protocol extensions (i.e., updates to the UDP option definition itself, rather than individual options). The values you want to request are from the "unassigned" range. Joe --------------437D511ED7F0A542BB07264F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Notes below...

On 3/8/2019 2:44 AM, qiangli (D) wrote:
"One way to relieve in-transit rewriting is to pre-compute the sending
    cycles along the way, then carry them with multiple SC options."

The 2 bits' value will be changed/rewritten hop-by-hop, that is what we call " in-transit rewriting " ---- SWAP method
We may use STACK method to reduce such " in-transit rewriting ". Will refine this part in 01 version. 

UDP options MUST NOT change in-transit. (anything that does change in-transit would not be eligible for a UDP option KIND assignment).

So it would be useful for this rev to describe ONLY the case where it is immutable.


why it wouldn’t be sufficient to just request the next open value?
The reason that why we wrote "127" is "127-253" is a reserved region defined in draft-ietf-tsvwg-udp-options-06, 

...

I'll note that "reserved" means you won't get those; they're set aside for base protocol extensions (i.e., updates to the UDP option definition itself, rather than individual options).

The values you want to request are from the "unassigned" range.

Joe

--------------437D511ED7F0A542BB07264F-- From nobody Fri Mar 8 20:56:37 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903C5124B0C for ; Fri, 8 Mar 2019 20:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 f9beUtACB407 for ; Fri, 8 Mar 2019 20:56:33 -0800 (PST) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED07012426E for ; Fri, 8 Mar 2019 20:56:31 -0800 (PST) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6ED9812A7FC for ; Fri, 8 Mar 2019 23:56:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=ouosbAVjKx0FltsPoszBCFepiGA=; b=bQi+rz fQw5YOWYqDEW84XdSZpM1MZVW900HZ/yy7vrOkQbUx75woA8u5pmRuNeX52ziqFd g2+ofpq7k3NoV8PBDd5vuzcfvhH7p+tXd248afyXi3OJ5XzQndpSxBcgQ2coPY6u q//KXacjDZy/wqd4Z9W9Y6LtJCJ/6M4+IJ7Sw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=ToylKIHT7WfKbEVYmZBqKFsj1IS9sqRZ X2JebORhVRkBJjtlw4bIN7Bs5ytw7J23r3+GQKIBXwSf8ZI5H2JNJ9PKEeRwM2ZA 99g3ba+jfR3OopIyTYctXVy2/B7smYSmVJ4gQeQHtP53HxAhTDyBqpkwoKvHWeV4 Ag7gNuVuCmU= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 5202912A7FA for ; Fri, 8 Mar 2019 23:56:28 -0500 (EST) Received: from mail-io1-f53.google.com (unknown [209.85.166.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id C6EB512A7F9 for ; Fri, 8 Mar 2019 23:56:27 -0500 (EST) Received: by mail-io1-f53.google.com with SMTP id b6so5043287iog.0 for ; Fri, 08 Mar 2019 20:56:27 -0800 (PST) X-Gm-Message-State: APjAAAUxjGpP1/t/Ntgn84+EJfyuI3YsXuxyxXoM62hYDVcbO/c3nrYz ZfbOle0GQ8+nhkJx71UBRCjYWM1z2cQ0Va9zTDg= X-Google-Smtp-Source: APXvYqxMN85HlVKD/zh6PoCY2REI7KEKNz1hk+UjKJgqgtGT2ETTrCRvhJHjf9TVJCxDFr1iLZiDrWgUEMlIv5uLjsI= X-Received: by 2002:a5d:9052:: with SMTP id v18mr1778479ioq.94.1552107387316; Fri, 08 Mar 2019 20:56:27 -0800 (PST) MIME-Version: 1.0 References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> In-Reply-To: <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> From: "C. M. Heard" Date: Fri, 8 Mar 2019 20:56:22 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: tsvwg , Derek Fawcus Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: B28D60D8-4227-11E9-8829-F733E42159A7-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 04:56:36 -0000 On Thu, 7 Mar 2019 23:41:08 -0800 Joe Touch wrote: > On 3/7/2019 1:23 PM, Derek Fawcus wrote: > > I don't think that is necessary for it to be first, as long as the 16 bits > > of checksum are correctly aligned for how they're swapped, the checksum > > can be at any offset in the payload. > > Yes - this is true. > > We should be able to ignore any of the other constraints and simply > compute OCS over the entire checksum area, so long as the result is > inserted with the same alignment as it is computed. s/checksum area/options area/ in the above paragraph > I.e., if the checksum field is word-aligned to the start of the option > area, then insert the calculated value (regardless of the alignment of > the option area start relative to the native alignment of memory). > Otherwise swap the bytes. Indeed, that is much more elegant than my initial suggestion. The sender has the option to pre-align the checksum to a half-word boundary if it is convenient, but that is not required; it is an implementation choice. > Note, however, there's a problem with LITE: the whole point of LITE is > that it is not checksummed. We can't make OCS cover the LITE area - that > would be the opposite of our goal. And we can't force the LITE area to > be aligned. I agree, and I understand that's why why OCS is (and always has been) defined so that it covers the UDP options (including LITE, if present), but excludes the LITE data. > So AFAICT although OCS will still work, it won't fix the bug - nor will > CCO - for either LITE or LITE+FRAG. Indeed, the updated version of OCS will not fix (or rather bypass) the middlebox checksum computation bug for either LITE or LITE+FRAG. That being said, there is a way around the problem with LITE+FRAG, and that would be to define an updated version of CCO that is the same as the updated version of OCS except that it covers LITE data as well as UDP options. This of course would defeat the purpose of LITE without FRAG, but it would allow LITE+FRAG to traverse the errant middleboxes. I expect that we will disagree on this matter, but I think that designing for deployability is vital in order for UDP options to get traction. This can be tempered by providing a migration path around undesirable workarounds for a better day when a NAME and SHAME campaign has succeeded in squashing errant middlebox behavior. Think of EDNS0 in DNS and the recent DNS flag day. Mike Heard From nobody Fri Mar 8 21:47:49 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D567712796B for ; Fri, 8 Mar 2019 21:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 x_9rC6qUrtJh for ; Fri, 8 Mar 2019 21:47:47 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 8C06E126C15 for ; Fri, 8 Mar 2019 21:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qxiNObhBQMky05ojc3Loiq51SMTypPNd7Rz1E1NocmI=; b=BpLlOLtYfmerB9+QsSrpLM8AG3 +9KjaU1tIY/SPhsHZzqC+QQ+vtG+hfPTu4+EvK6yhwNXvlJ0xgVlx/pml4iNLIuaxoG7uGDl/PbM/ QKK/Oz9QLLynNyRU6ztokvRAPCCMIpjzY/2zqFGXkDQolOF43L51yrlNH4X+R97iaw+WkyeqrAquo zFAUt7DN28XOpbiaCO36rE40Tm7xPyGHp7QHh86GCfX9WCKDOVFKXLxhEOzTUaHM/rULlziGevy/w fem2ZmVmxxvkuaAoy0KJFPBUcor2m69Mv2ncWAyWjOrqMQtac6qxFPjabga2HePG72nBA1TM4ICBf nHDNSAbQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54315 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h2Upg-004BTT-5x; Sat, 09 Mar 2019 00:47:41 -0500 To: "C. M. Heard" Cc: tsvwg , Derek Fawcus References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> From: Joe Touch Message-ID: <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> Date: Fri, 8 Mar 2019 21:47:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 05:47:49 -0000 On 3/8/2019 8:56 PM, C. M. Heard wrote: > That being said, there is a way around the problem with LITE+FRAG, and > that would be to define an updated version of CCO that is the same as > the updated version of OCS except that it covers LITE data as well as > UDP options. This of course would defeat the purpose of LITE without > FRAG, but it would allow LITE+FRAG to traverse the errant middleboxes. So the problem is compounded in the case of LITE+FRAG. One point of the LITE+FRAG solution is NOT checksum the contents of the fragments, but TO checksum the resulting reassembled set - the rationale being the E2E argument, that we should trust only the final step. So not only would you be doing "unnecessary" work for LITE, but for LITE+FRAG you'd be more than doubling the checksum overhead of fragmentation. Again, I would table further discussion on this topic until we have more detail on either the network location of these alleged devices or the names of their manufacturers and details, if known at endpoints. There's simply no point in designing for a transient error. Joe From nobody Fri Mar 8 21:52:34 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C478127971; Fri, 8 Mar 2019 21:52:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <155211074760.10132.16818238668770895482@ietfa.amsl.com> Date: Fri, 08 Mar 2019 21:52:27 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 05:52:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Transport Options for UDP Author : Joe Touch Filename : draft-ietf-tsvwg-udp-options-07.txt Pages : 32 Date : 2019-03-08 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-07 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 8 21:53:43 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED2B128678; Fri, 8 Mar 2019 21:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 49WZt4beBq87; Fri, 8 Mar 2019 21:53:41 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 65478126C15; Fri, 8 Mar 2019 21:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EU7TYQmVURvX7rXNIgGGbVONsrq9C7xdkvPHf/Hgcyk=; b=TEvCjPRhCKlIVaSADjLm7G629I B0AouWydHwcdwiISGKCINxjm8Vs3zmSZeLjyIuk4e/eEJWZE6s3pkSMZNP0kaz/cRlHjBYbi3ZYSK N8KYU9yBiivpZfdj7guOESAC9MXyBEEm4HTHOcShHIHPM4vWthAWot5zB/PlvpopaIeGciufaUm8l AkWbngXfXbe9wLNvf+laGjirawnS15r3nKI0XarqqC0p7gTAQEv96irAyAkBV3OqDE0K1JrkMU8pA xtAZUt71JBs50W0YfAPWou+4k2B80YcninBNWVJYxQTxmZCI9HyCZNKwfDV+Y3NT/UPb9fMdwPP6a o+onqJ7w==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54396 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h2UvS-004FwW-WE; Sat, 09 Mar 2019 00:53:40 -0500 To: tsvwg@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org References: <155211074760.10132.16818238668770895482@ietfa.amsl.com> From: Joe Touch Message-ID: Date: Fri, 8 Mar 2019 21:53:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155211074760.10132.16818238668770895482@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 05:53:43 -0000 This corrects some errors in the processing instructions and rules for new options. Joe On 3/8/2019 9:52 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group WG of the IETF. > > Title : Transport Options for UDP > Author : Joe Touch > Filename : draft-ietf-tsvwg-udp-options-07.txt > Pages : 32 > Date : 2019-03-08 > > Abstract: > Transport protocols are extended through the use of transport header > options. This document experimentally extends UDP by indicating the > location, syntax, and semantics for UDP transport layer options. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-07 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From nobody Sat Mar 9 02:37:10 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286AC129619 for ; Sat, 9 Mar 2019 02:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zU-NJQiGaUL for ; Sat, 9 Mar 2019 02:37:07 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8098D12787E for ; Sat, 9 Mar 2019 02:37:07 -0800 (PST) Received: by bugle.employees.org (Postfix, from userid 1736) id 62AACFECBF64; Sat, 9 Mar 2019 10:37:06 +0000 (UTC) Date: Sat, 9 Mar 2019 10:37:06 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20190309103706.GA15572@bugle.employees.org> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 10:37:09 -0000 On Fri, Mar 08, 2019 at 09:47:40PM -0800, Joe Touch wrote: > > One point of the LITE+FRAG solution is NOT checksum the contents of the > fragments, but TO checksum the resulting reassembled set - the rationale > being the E2E argument, that we should trust only the final step. As I recall the LITE+FRAG use case has no data in the UDP payload (i.e UDP header length is zero)? For this case, there is another way to work around a broken path (be it boxes, NICs, or whatever), that is simply to send with UDP header checksum of zero, and contain any necessary checksums in the UDP slack space. Since the devices on path won't attempt to verify such packets, they should pass unimpeded; and we can then control whatever checksum behaviour is desired for the transported data with the contents of the UDP options. A similar approach can be used whenever UDP len is zero, it obviously can't work when we have UDP data and meaningful data in the slack space. The OCS/CCO case can cover that, except for the LITE (w/o FRAG) case. For the latter I guess we could also use UDP checksum of zero, and have an option to restore a proper checksum for the UDP data at the receiver, however that will still leave legacy receivers experiencing such packets as unchecksumed. Given that we're supposed to veryify such receivers can accept LITE (w/o FRAG) and hold soft state, maybe this is acceptable? i.e. we'de verify LITE comprehension by initially sending it with a CCO like option; once the state is built, we can send LITE (w/o FRAG) using UDP checksum of zero, and the additional option encoding the actual checksum for the UDP data. This additional checksum could simply be the existing defined ACS option. This would seem to avoid doubling of work, and also avoid performing a checksum upon the LITE data portion. DF From nobody Sat Mar 9 02:38:38 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B4A12D4EA for ; Sat, 9 Mar 2019 02:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHOFnrbE2Nh9 for ; Sat, 9 Mar 2019 02:38:35 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9129412870E for ; Sat, 9 Mar 2019 02:38:35 -0800 (PST) Received: by bugle.employees.org (Postfix, from userid 1736) id 99DBCFECBEE8; Sat, 9 Mar 2019 10:38:34 +0000 (UTC) Date: Sat, 9 Mar 2019 10:38:34 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20190309103834.GB15572@bugle.employees.org> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: [tsvwg] UDP Options deployability X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 10:38:37 -0000 On Fri, Mar 08, 2019 at 09:47:40PM -0800, Joe Touch wrote: > > Again, I would table further discussion on this topic until we have more > detail on either the network location of these alleged devices or the > names of their manufacturers and details, if known at endpoints. There's > simply no point in designing for a transient error. I'd have to disagree on that. We know there are issues, we won't find all of them up front, but for those we've already found (even if we can't identify the faulty devices), we should work around them where we can. We have to cope with the world as we find it, not as we'd desire it to be, otherwise the UDP options will simply end up being a non-deployable academic exercise; and I view deployability as trumping a lot of the other considerations. I'd like to be able to use the result, vs the situation we have with UDP-Lite. So I'd say we have to make it work for a sufficiently large portion of use cases that we get a foothold, and that provides the pressure for others to fix their products. That making it work task may well mean choices which seem to be pandering to the broken devices currently deployed, but so be it, otherwise there is a good chance this this effort is simply wasted. DF From nobody Sat Mar 9 03:47:48 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A7F126D00 for ; Sat, 9 Mar 2019 03:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 tOKPYoy2ut-d for ; Sat, 9 Mar 2019 03:47:45 -0800 (PST) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F54124C04 for ; Sat, 9 Mar 2019 03:47:45 -0800 (PST) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B2A4712C8DF for ; Sat, 9 Mar 2019 06:47:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=l6CWkIrMn+XGTTshRXGG1dVUdBE=; b=DgqbOe C8UsFlQDiVyZOyegCZUvfgmpvqiR7C+mFdGo7M3JqFBod/XmxC+lWISxlUz71Eth tF32EDxmWbklSE2fSkr32RtVdWM8dz5+pZI5EEk0QyMS9XrijpgvtURVi7fGG2oa xx0yFoCwsYaqhxA1INAAnv73JDHhxjap8TfX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=s5kgYAffrZ0Pb2HVlvDUFfu+oFnJq3Hx 9lP/DK/pb/oC6cWDR2wtILnAnqhYvHHMK/npghv6U90YXCshjwgl0F/fANsOSzVj kj7SEDubXFEhZH4wXyDV8lzYoNZmwrYaK4SFp2+zaiORkioqnJTl3uzalfVjLRRR G9Oqdw1JREw= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id A94D112C8DD for ; Sat, 9 Mar 2019 06:47:44 -0500 (EST) Received: from mail-it1-f177.google.com (unknown [209.85.166.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 3643112C8D9 for ; Sat, 9 Mar 2019 06:47:44 -0500 (EST) Received: by mail-it1-f177.google.com with SMTP id v2so328017ith.3 for ; Sat, 09 Mar 2019 03:47:44 -0800 (PST) X-Gm-Message-State: APjAAAWicTRHpJ5+/6b7dpHvch/JuQvFqGPUDMj/6XhA+MrSXXqVlaQ8 QcTLxae5goGFLC3W+UKUft09E/LKFIbx7cpnTlw= X-Google-Smtp-Source: APXvYqxe6zj2qij6fcJ4nUcg29xz52nCZbZ/kMlEfSg+g57fOUxbTGdnx4n0BMivGS5K9E1vjrAJCWO8sPqa/ZE8vB8= X-Received: by 2002:a02:c505:: with SMTP id s5mr12264942jam.25.1552132063668; Sat, 09 Mar 2019 03:47:43 -0800 (PST) MIME-Version: 1.0 References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> In-Reply-To: <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> From: "C. M. Heard" Date: Sat, 9 Mar 2019 03:47:39 -0800 X-Gmail-Original-Message-ID: Message-ID: To: tsvwg Cc: Derek Fawcus , Joe Touch Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 26D6D148-4261-11E9-831D-F733E42159A7-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 11:47:47 -0000 On Sat, 9 Mar 2019 10:38:34 +0000, Derek Fawcus wrote: > On Fri, Mar 08, 2019 at 09:47:40PM -0800, Joe Touch wrote: > > Again, I would table further discussion on this topic until we have more > > detail on either the network location of these alleged devices or the > > names of their manufacturers and details, if known at endpoints. There's > > simply no point in designing for a transient error. > > I'd have to disagree on that. > > We know there are issues, we won't find all of them up front, > but for those we've already found (even if we can't identify the > faulty devices), we should work around them where we can. > > We have to cope with the world as we find it, not as we'd desire > it to be, otherwise the UDP options will simply end up being > a non-deployable academic exercise; and I view deployability > as trumping a lot of the other considerations. +1 to all of that, particularly when the workarounds can be made relatively painless. Mike Heard From nobody Sat Mar 9 03:51:31 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19CF1271FF for ; Sat, 9 Mar 2019 03:51:29 -0800 (PST) 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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhn0G6po9txi for ; Sat, 9 Mar 2019 03:51:27 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id B9C41126D00 for ; Sat, 9 Mar 2019 03:51:27 -0800 (PST) Received: from erg.abdn.ac.uk (at-www-1.erg.abdn.ac.uk [IPv6:2001:630:42:150::5]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B679F1B0007C; Sat, 9 Mar 2019 11:51:24 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 09 Mar 2019 11:51:22 +0000 From: Raffaele Zullo To: Joe Touch Cc: tsvwg@ietf.org In-Reply-To: References: <155211074760.10132.16818238668770895482@ietfa.amsl.com> Message-ID: <1e03e780aacb8869c05c5ec7cfa17985@erg.abdn.ac.uk> X-Sender: raffaele@erg.abdn.ac.uk User-Agent: Roundcube Webmail/1.2.3 Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 11:51:30 -0000 On 2019-03-09 05:53, Joe Touch wrote: > This corrects some errors in the processing instructions and rules for > new options. > > Joe Hello Joe, I am sorry but I'd have to disagree with this: The adjustment above helps enable that OCS, together with the other options, result in an overall zero ones-complement sum. This feature is intended to potentially help the UDP options traverse devices that incorrectly attempt to checksum the surplus area (as originally proposed as the Checksum Compensation Option, i.e., CCO [Fa18]). The new OCS is different from CCO and can't help to traverse the devices traversed by CCO. Those devices not only compute UDP checksum over UDP Options area but also use IP Payload length instead of UDP Length in UDP pseudo-header. (In other words to cross those problematic devices the checksum of UDP Options area should not be zero but equal to minus the length of Options) This is why CCO included a pseudo-header (containing UDP Options length) and handled its alignment with the start of UDP Options. Thank you, Raffaele Zullo From nobody Sat Mar 9 05:24:02 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1111127968 for ; Sat, 9 Mar 2019 05:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 xVzkGNFrhCpM for ; Sat, 9 Mar 2019 05:23:58 -0800 (PST) Received: from pb-smtp21.pobox.com (pb-smtp21.pobox.com [173.228.157.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F021276D0 for ; Sat, 9 Mar 2019 05:23:58 -0800 (PST) Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 5C9A840145 for ; Sat, 9 Mar 2019 08:23:57 -0500 (EST) (envelope-from heard@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=H8X Af/w2O2I2PiKO8IKQ/F3j0WQ=; b=MShnMj+eRWPSlFX4uJR8mW69CNvvUrtmKVi /oUwFnJxQUCnpg2ha28BN4+fjW0K44fC2HF4t59Qq/hQTYabf18Nh2iacPGjacU0 Vg9U8fyXbuv9DEbf5KO9MfrZemI66BdzP5Ne/XH+SANsGqx0qCNg3hY2ufXIok8E UhllOPHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= nInFfkEqn0lP8C5bDK/5KMIVosJSn59mN4YYxCAwNiSWcrjCpaoi4ssow21gv6+N 2ehuf2U/47i5B9q/W81Xr75ZnTpew3r4obT6278XJePgu+rSn3zKN8/xXOLyMIjN jEymMzlE93R/pFW8Pa3osUi461zb4J2xxyCVSC3LTlo= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 55A5F40144 for ; Sat, 9 Mar 2019 08:23:57 -0500 (EST) (envelope-from heard@pobox.com) Received: from mail-it1-f174.google.com (unknown [209.85.166.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id E8E8140140 for ; Sat, 9 Mar 2019 08:23:54 -0500 (EST) (envelope-from heard@pobox.com) Received: by mail-it1-f174.google.com with SMTP id l139so529159ita.5 for ; Sat, 09 Mar 2019 05:23:54 -0800 (PST) X-Gm-Message-State: APjAAAXOPsG0LuqM7o3zWsaw7W0nW7Hahz33nTEnmoONMi9kW6rf1Zmg /c03Nf1PJY9DQbgdogN+1dgKksNmGIZ7d1e+f9Q= X-Google-Smtp-Source: APXvYqwyeUWzlsPhsEzBBxgjGonZiKYVuSFh5IwyYda79+4mzvhIhk8d6twUZGRPnBLBi6zQLuBVQApv47yByqzk5WU= X-Received: by 2002:a02:a589:: with SMTP id b9mr13431256jam.40.1552137833682; Sat, 09 Mar 2019 05:23:53 -0800 (PST) MIME-Version: 1.0 From: "C. M. Heard" Date: Sat, 9 Mar 2019 05:23:41 -0800 X-Gmail-Original-Message-ID: Message-ID: To: tsvwg Cc: Joe Touch , Gorry Fairhurst , Tom Jones , Raffaele Zullo Content-Type: multipart/alternative; boundary="000000000000381f020583a940d0" X-Pobox-Relay-ID: 96761C4A-426E-11E9-B991-EE24A11ADF13-06080547!pb-smtp21.pobox.com Archived-At: Subject: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 13:24:01 -0000 --000000000000381f020583a940d0 Content-Type: text/plain; charset="UTF-8" Greetings, In an off-list e-mail, Gorry Fairhust brought to my attention the fact that the errant middleboxes that CCO is designed to work around do not use the correct length value in their (re)computation of the UDP checksum. Quoting from draft-fairhurst-udp-options-cco-00: These middleboxes use the IP Payload Length (obtained as IP Total Length - IP Header Length) to fill UDP pseudo-header Length field and also compute the checksum over the all IP Payload bytes. The genesis of this bug is discussed in the maprg presentation given by the Tom Jones at IETF 103 ( https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00 ). So, besides compensating for the contents of the surplus area, it is also necessary to compensate for the incorrect length value in the UDP pseudo-header. The way that CCO does this is to add a 16-bit pseudo-header of its own that consists of the length of the surplus area. This pseudo-header needs to be aligned with the UDP pseudo-header in order to do its job. Aligning the checksum in the CCO option to a half-word boundary achieves this. These are the points that Rafaele Zullo was trying to make in the message at https://mailarchive.ietf.org/arch/msg/tsvwg/ikg4zLMvejJZERWh4hQTAGUrLGY that escaped both Joe and me. So, it would seem that the OCS text in draft-ietf-tsvwg-udp-options-07 needs some more editing work to take this into account. The objectives can still be achieved with an option that has kind = 2 followed by a 16-bit checksum and no length value, but the calculation has to take into account the fact that the fact that the 16-bit pseudo-header needs to be aligned with the UDP header. Rafaele Zullo's message discusses some of the options. One is to use a NOP to force half-word alignment, but there are other ways to accomplish that objective. Another point is that it is necessary either for the OCS to cover the entire surplus area or else for any padding after the UDP options to be checksum-neutral (e.g., consist of zeroes) in order to properly compensate for the middlebox behavior described above. Besides these matters of substance, there are some editorial matters that need to be attended to. In Section 4 I see: UDP options are defined using a TLV (type, length, and optional value) syntax similar to that of TCP [RFC793]. They are typically a minimum of two bytes in length as shown in Figure 4, excepting only the one byte options "No Operation" (NOP) and "End of Options List" (EOL) described below. If OCS is to have no length field (i.e., have an implicit length of 3), then some text needs to be added to that paragraph. Also, Figure 7 in Section 5.3 needs to be updated to something like this: +--------+--------+--------+ | Kind=2 | Checksum | +--------+--------+--------+ The modifications to OCS requested above would not, AFAICT, cause any significant additional complication. They would also not address the fact that errant middle box traversal for LITE or FRAG+LITE remains unaddressed, but I see those as separate issues. Mike Heard --000000000000381f020583a940d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetin= gs,

In an off-list e-mail, Gorry Fairhust brought to my attention th= e fact that
the errant middleboxes that CCO is designed to work around d= o not use the
correct length value in their (re)computation of the UDP c= hecksum. Quoting
from draft-fairhurst-udp-options-cco-00:

=C2=A0 = =C2=A0These middleboxes use the IP Payload Length (obtained as IP Total
= =C2=A0 =C2=A0Length - IP Header Length) to fill UDP pseudo-header Length fi= eld and
=C2=A0 =C2=A0also compute the checksum over the all IP Payload b= ytes.

The genesis of this bug is discussed in the maprg presentation= given by the
Tom Jones at IETF 103 (https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-= a-tale-of-two-checksums-tom-jones-00).

So, besi= des compensating for the contents of the surplus area, it is
also necessary to compensate for the incorrect length value in the=
UDP pseudo-header. The way that CCO does this is to = add a 16-bit
pseudo-header of its own that consists o= f the length of the surplus
area. This pseudo-header = needs to be aligned with the UDP pseudo-header
in ord= er to do its job. Aligning the checksum in the CCO option to a
half-word boundary achieves this.

These are the points that Rafaele Zullo was trying to mak= e in the message at
t= hat escaped both Joe and me.

So, it would seem that the OCS text i= n draft-ietf-tsvwg-udp-options-07
needs some more editing work to take t= his into account. The objectives
can still be achieved with an option th= at has kind =3D 2 followed by a
16-bit checksum and no length value, but= the calculation has to take
into account the fact that the fact that th= e 16-bit pseudo-header needs
to be aligned with the UDP header. Rafaele = Zullo's message discusses
some of the options. One is to use a NOP t= o force half-word alignment,
but there are other ways to accomplish that= objective.

Another point is that it is necessary either for the OCS= to cover the
entire surplus area or else for any padding after the UDP = options
to be checksum-neutral (e.g., consist of zeroes) in order to pro= perly compensate for the middlebox behavior described above.

Besides= these matters of substance, there are some editorial matters
that need = to be attended to. In Section 4 I see:

=C2=A0 =C2=A0UDP options are = defined using a TLV (type, length, and optional
=C2=A0 =C2=A0value) synt= ax similar to that of TCP [RFC793]. They are typically a
=C2=A0 =C2=A0mi= nimum of two bytes in length as shown in Figure 4, excepting only
=C2=A0= =C2=A0the one byte options "No Operation" (NOP) and "End of= Options List"
=C2=A0 =C2=A0(EOL) described below.

If OCS is= to have no length field (i.e., have an implicit length of 3),
then some= text needs to be added to that paragraph. Also, Figure 7 in
Section 5.3= needs to be updated to something like this:

               =
    +--------+--------+--------+
                   | Kind=3D2 |     Checksum    |
                   +--------+--------+--------+

The modifications to OCS requested above would no= t, AFAICT, cause any
significant additional complication. They wo= uld also not address the
fact that errant middle box traversal fo= r LITE or FRAG+LITE remains
unaddressed, but I see those as separ= ate issues.

Mike Heard
--000000000000381f020583a940d0-- From nobody Sat Mar 9 11:04:39 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4224012426E for ; Sat, 9 Mar 2019 11:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 vody0YEs6OEZ for ; Sat, 9 Mar 2019 11:04:36 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 254F612762F for ; Sat, 9 Mar 2019 11:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sWyo6F8tbVgvuc9sYlYfPEzR3rzsMkueoB1Yft4zFos=; b=JdE3jx831w9LtwrBlHXDFgTcu GhBn1ZgWC1QBYlcYgin1IFXIoM4QLq9mnjnNirKlF1Rg/4BkyISTNnok06Ky9nzJpthSQDeFif6cJ qPQGZz6+7E99rbWIt0Ot01vbOSD4NMWSdrB4p18sM6Yv47xcfpirlxY0/oKRYlXj0jyx0OorhOCYC arTVIz+6HquO6YPUz0ck88Lj0hPlIBdaURltzTcXKMXYkZ1gSPEOvflfay0vrvtDPJLPFlvEHV1DW sSt17nlCRtoPKrq0lvQ7EsLaqUuG5gDBDlMyw35Z6SyuclH9JR1fj0l6JYI1ML63aN/F3UDRd/grv VhxdyFREw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51184 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h2hGr-003Nmk-1K; Sat, 09 Mar 2019 14:04:33 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Sat, 9 Mar 2019 11:04:30 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <71FD67F1-98D1-4327-B45B-98E0DAA69FD0@strayalpha.com> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> To: "C. M. Heard" X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 19:04:38 -0000 OK, but at a MINIMUM we need to deal with these in parallel. We do need to live with the real world, which means FIXING THE POTHOLES, = not just building tanks that don=E2=80=99t care about them=E2=80=A6 Joe > On Mar 9, 2019, at 3:47 AM, C. M. Heard wrote: >=20 > On Sat, 9 Mar 2019 10:38:34 +0000, Derek Fawcus wrote: >> On Fri, Mar 08, 2019 at 09:47:40PM -0800, Joe Touch wrote: >>> Again, I would table further discussion on this topic until we have = more >>> detail on either the network location of these alleged devices or = the >>> names of their manufacturers and details, if known at endpoints. = There's >>> simply no point in designing for a transient error. >>=20 >> I'd have to disagree on that. >>=20 >> We know there are issues, we won't find all of them up front, >> but for those we've already found (even if we can't identify the >> faulty devices), we should work around them where we can. >>=20 >> We have to cope with the world as we find it, not as we'd desire >> it to be, otherwise the UDP options will simply end up being >> a non-deployable academic exercise; and I view deployability >> as trumping a lot of the other considerations. >=20 > +1 to all of that, particularly when the workarounds can be made > relatively painless. >=20 > Mike Heard >=20 From nobody Sat Mar 9 11:29:08 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46313124B91 for ; Sat, 9 Mar 2019 11:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 gTnt-DEMG9bo for ; Sat, 9 Mar 2019 11:29:05 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C4EAE12426E for ; Sat, 9 Mar 2019 11:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vWAvpRyT55AoJuFlLCk9UKCOxvtgtRIWGvvkrWiqs4c=; b=JwjUklM4DfEGw6EsOrG/pXEVU 8SKBJlMdAsQbP1SgX4+uvJCRafAu+6W6AQjzMkIKwXU8WjQEL9dFXXvEqnv0Mid7H9aTCDWR6/0G2 5uMIwgzkKun6teMIrw2sN06nLp7qER0fGC2ZzXQnK2tnlbBgIxMMJGdE8XmLJWFsoQpV/whTyWv1x jhoxIWLMVqshVclqL2BDJPzOOWw6PCAUlhyDsCZLerELG7BCWLubIYBD7LORqFS2SsXc0ZFq/Tzua Tetsv4T5yJYJVP41T18jlYo3EMncHuPi8cPLv1aTi8fEBxZBIxBKRwzNxW/7mMt2KHdFDXwoK98Xk cmmC4yk9w==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51244 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h2heU-003kWP-R4; Sat, 09 Mar 2019 14:29:00 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Sat, 9 Mar 2019 11:28:57 -0800 Cc: tsvwg , Gorry Fairhurst Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "C. M. Heard" X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 19:29:07 -0000 This one=E2=80=99s a bit long - we need to converge quickly if the draft = is going to be updated in time for the cutoff. Please comment asap=E2=80=A6 Joe PS =3D yes, we talk about TLV but need to explain that some options are = exceptions (OCS, NOP, EOL). I also need to update the OCS to be 3 bytes = long (in the table and figure). Those are in addition to the issues = below. ------- Raffaelo and Mike both pointed out: > On Mar 9, 2019, at 5:23 AM, C. M. Heard wrote: > ... > the errant middleboxes that CCO is designed to work around do not use = the > correct length value in their (re)computation of the UDP checksum. ... Well, there are several implications here: 1. we can add in the option length, BUT that also means: (a) we need to declare that the option area consumes the whole = of the surplus area (no chance for other uses) OR (b) that the surplus area is always zero OR=20 (c) that OCS covers even the surplus area (it doesn=E2=80=99t = need to be zero; it does need to be included) we need a choice here. AFAICT, the safest (a) 2. we don=E2=80=99t need OCS alignment; what we do need is to = =E2=80=9Ccoordinate=E2=80=9D the alignment of a 16-bit of the length to = the OCS checksum field i.e.: - calculate the length needed (IPlen - UDP len) - if OCS checksum field is not 16-bit aligned to the start of = the option area, then swap bytes - add the result to the OCS checksum (=E2=80=98pseudo header=E2=80= =99 seems a bit heavy here, but same point) As Derek noted: > As I recall the LITE+FRAG use case has no data in the UDP payload > (i.e UDP header length is zero)? >=20 > For this case, there is another way to work around a broken path (be = it > boxes, NICs, or whatever), that is simply to send with UDP header = checksum > of zero, and contain any necessary checksums in the UDP slack space. 3. we have to deal with LITE/LITE+FRAG=20 we *can* use UDP CS=3D0, but that also may involve overriding = the user=E2=80=99s desires here (i.e., the user API says =E2=80=9Cuse = UDP CS=E2=80=9D and we=E2=80=99re not doing that) which means we have a choice: (d) override so that things work, i.e., force UDP CS=3D0 and = then (d.1) do OCS as a check on our stuff only OR (d.2) disallow the use of OCS (if CS=3D0, what=E2=80=99s = the point?) OR (d.3) use OCS=3D0 (this seems like a waste) OR (e) ignore the user setting of CS, then: (e.1) always do OCS as a check OR (e.2) if UDP CS=3D0, omit OCS (save space), basically = like d.2=20 OR (e.3) if UDP CS=3D0, use OCS=3D0 (basically like e.2 If we do any of the (e) variants, we could either: (f.1) require users to disable UDP CS to use OCS OR (f.2) ignore the user UDP CS setting So which is it? I don=E2=80=99t like assuming user correct configuration (f.1). So to me it=E2=80=99s (f.2) and (d.1).=20 Thoughts? also Derek noted: > The OCS/CCO case can cover that, except for the LITE (w/o FRAG) case. >=20 > For the latter I guess we could also use UDP checksum of zero, and = have > an option to restore a proper checksum for the UDP data at the = receiver, > however that will still leave legacy receivers experiencing such = packets > as unchecksumed. 5. the LITE only case The whole point of LITE is that some of the IP payload isn=E2=80=99t = checksummed.=20 > Given that we're supposed to veryify such receivers can accept > LITE (w/o FRAG) and hold soft state, maybe this is acceptable? We don=E2=80=99t have a requirement that such receivers can accept LITE = before we start using it, so soft state won=E2=80=99t help here. > we can send > LITE (w/o FRAG) using UDP checksum of zero, and the additional > option encoding the actual checksum for the UDP data. >=20 > This additional checksum could simply be the existing defined > ACS option. ACS uses a CRC, not IP checksum. That=E2=80=99s a LOT more work in = software, so this isn=E2=80=99t a viable alternative. IMO, we leave this one alone. The whole point of LITE is to do less work = - if that means the LITE data corrupts the entire packet, then so be it. = Then LITE basically fails. ------ From nobody Sat Mar 9 11:31:49 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4785F124B91 for ; Sat, 9 Mar 2019 11:31:48 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 N3Rz5yH6kbIp for ; Sat, 9 Mar 2019 11:31:46 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 21E2812426E for ; Sat, 9 Mar 2019 11:31:46 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id z13so559745qki.2 for ; Sat, 09 Mar 2019 11:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yqk7D+ZJi9zZYt/wy0F4AUc8xYFmugNjf7XI/5UuV6Y=; b=qjqbRwersezBEiMU7qRz8DzrAdS36I7zkytdz4fyjQkm08qwn41MkkmVX8F/pPiybf XM7s+C5XCcacHG8l3cwbS9gZG+wi0LinvAGlGj0Ifev9CxONjOiYAmIfC4hRVSzVFbX1 l680XuEfmaIQcEvzsaC+u7Ls68vk1W1TCREAp1prfo2Yqow58tQRPMvvKk1INu5jh+Cy WQF2u5xvc8pUIDParzBSulwV0EgXXWO8TZ0N6sr0og9zStFEstIR9vulFx47uBP8Chvh Kc81NFkKRQ7XMlYBrNPNxNQWXXoVLrRRH433Ih/3oC++Xk2TtUcR1X1nlmWNRxFkMeom bjLQ== 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=Yqk7D+ZJi9zZYt/wy0F4AUc8xYFmugNjf7XI/5UuV6Y=; b=tSSwLqsD/VlTtF8a0WZ/4xfVVdfvxDDMogyqrMI8f6SV5uBnRsoPQvteK2szdlDiQ5 Wzq+rfHpL7OUp8lz4hfbt3grkOMjCz/o8VbjXo9cgnu4Ms84ynGVToYNsKb0v+pzucd2 d6EPauMqjLlSzcdSZ+Vz0Md8TwZuUwV3VAJ3VejEuJsE/1X1A4P/k9ijqhNeYPtJ57aS rI9juFAhtMft4lUPKjFLX1dpsLCjuylOUmm5QSz1yi8eZQmMxgq4KyKYk8DW10z0hiCz pgpe0+EH/4+oJam5m8WzaCVA6MlyvBll2wJrquczidUxZeLLcPNjN2idW2P/t3TRfwW5 7f6Q== X-Gm-Message-State: APjAAAXM4XugBIsfDj2cJOK0GVjYt0WAzAKK8tGp1qLvmPvVb56SF6o8 W/PToSDINKqp4TJtkrStJnI7CJV/fVuCkt0Mz8Tskg== X-Google-Smtp-Source: APXvYqxMXtZd/S9Q+ud87WP68K0qBhPfJ7vV/p9CQa8e1PDIYCc17hhSr6CUpukdz4XPPQbHmaZRI9h/QCWBiLyQM4k= X-Received: by 2002:ae9:ef05:: with SMTP id d5mr19105593qkg.323.1552159905018; Sat, 09 Mar 2019 11:31:45 -0800 (PST) MIME-Version: 1.0 References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> <20190309103834.GB15572@bugle.employees.org> In-Reply-To: <20190309103834.GB15572@bugle.employees.org> From: Tom Herbert Date: Sat, 9 Mar 2019 11:31:37 -0800 Message-ID: To: Derek Fawcus Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] UDP Options deployability X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 19:31:48 -0000 On Sat, Mar 9, 2019 at 2:38 AM Derek Fawcus wrote: > > On Fri, Mar 08, 2019 at 09:47:40PM -0800, Joe Touch wrote: > > > > Again, I would table further discussion on this topic until we have more > > detail on either the network location of these alleged devices or the > > names of their manufacturers and details, if known at endpoints. There's > > simply no point in designing for a transient error. > > I'd have to disagree on that. > > We know there are issues, we won't find all of them up front, > but for those we've already found (even if we can't identify the > faulty devices), we should work around them where we can. > > We have to cope with the world as we find it, not as we'd desire > it to be, otherwise the UDP options will simply end up being > a non-deployable academic exercise; and I view deployability > as trumping a lot of the other considerations. > The only way you can know if UDP options are deployable is to actually try to deploy them. This discussion is reminiscent of TFO where every effort was made to define a deployable protocol, but when it started in deployment unforeseen issues appeared where intermediate nodes were dropping SYNs with data. It was quite a bit of work to identify and the root out all the issues. Tom > I'd like to be able to use the result, vs the situation we have > with UDP-Lite. So I'd say we have to make it work for a > sufficiently large portion of use cases that we get a foothold, > and that provides the pressure for others to fix their products. > > That making it work task may well mean choices which seem to > be pandering to the broken devices currently deployed, but > so be it, otherwise there is a good chance this this effort > is simply wasted. > > DF > From nobody Sat Mar 9 11:38:44 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB59130EB4 for ; Sat, 9 Mar 2019 11:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 y6c92uq9dl5H for ; Sat, 9 Mar 2019 11:38:28 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 72F1812865D for ; Sat, 9 Mar 2019 11:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Vgx49FKkJYkEh+GluFIXTmGxCH9yT92G2ebmrBu759Q=; b=FLTVSP43KsyEWg8+CvySujxmW b+j5IHyPexZmQOsGpUMuD4SnLOLwRiLqP+I9W9KLtfMzpoSmnaI8dAY08AfF/Sdm38XxA36g65N/e tXI5QpxkWZoShGSYMmhrn5DehPBOnhQID5crM9p1nk3xW5u5rHJz3ze3ZsVZgThKAdBA69Yxnudjj eWB6Le2DiZ78w0F0VIH957xZuSI4VTojx4XGR0QcSPMOWEAVs6vUUVZBUB55EgMJQrT57XogyBDN3 o/v5d36NHGhCz2nVSdAwZrzwxcfHE2qTp17a5IGgP+SvLIBizV+cg8it3npjPjTxPOsN5aW18e1sO cRgvqvgaQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51394 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h2hnc-003sVm-4g; Sat, 09 Mar 2019 14:38:24 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_D23E68FA-6BCB-4AC7-9D66-D4A9A3F009EF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Sat, 9 Mar 2019 11:38:22 -0800 Cc: Derek Fawcus , tsvwg Message-Id: <79048D05-956E-4D34-9880-3D8275011FDB@strayalpha.com> References: <7D37562E-0375-4EDE-845C-013A4C2E56BC@strayalpha.com> <6F998932-3DB9-48A3-B6FD-24AF9720DD54@strayalpha.com> <5d059a5c-c60e-988c-2b4c-ca8116ddb96f@strayalpha.com> <20190309103834.GB15572@bugle.employees.org> To: Tom Herbert X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] UDP Options deployability X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 19:38:43 -0000 --Apple-Mail=_D23E68FA-6BCB-4AC7-9D66-D4A9A3F009EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 9, 2019, at 11:31 AM, Tom Herbert wrote: >=20 > The only way you can know if UDP options are deployable is to actually > try to deploy them. This discussion is reminiscent of TFO where every > effort was made to define a deployable protocol, but when it started > in deployment unforeseen issues appeared where intermediate nodes were > dropping SYNs with data. It was quite a bit of work to identify and > the root out all the issues. Perhaps, but we had similar issues with multilevel tunnels not working. Instead of trying to design an encapsulation protocol to get around = things, we tracked down the issues and fixed the bugs.=20 Now we have a clean solution that works (just do multiple = encapsulations) rather than a maze of twisty little passages as an = artifact of tolerating errors rather than fixing them. Joe --Apple-Mail=_D23E68FA-6BCB-4AC7-9D66-D4A9A3F009EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Mar 9, 2019, at 11:31 AM, Tom Herbert <tom@herbertland.com>= wrote:

The only way you can know if UDP = options are deployable is to actually
try to deploy them. This discussion is reminiscent of TFO = where every
effort was = made to define a deployable protocol, but when it started
in deployment unforeseen issues = appeared where intermediate nodes were
dropping SYNs with data. It was quite a bit of work to = identify and
the root out = all the issues.

Perhaps, but we had similar issues with multilevel = tunnels not working.

Instead of = trying to design an encapsulation protocol to get around things, we = tracked down the issues and fixed the bugs. 

Now we have a clean solution that works (just do = multiple encapsulations) rather than a maze of twisty little passages as = an artifact of tolerating errors rather than fixing them.

Joe

= --Apple-Mail=_D23E68FA-6BCB-4AC7-9D66-D4A9A3F009EF-- From nobody Sat Mar 9 11:57:06 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D21130E1C for ; Sat, 9 Mar 2019 11:57:05 -0800 (PST) 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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgkp-CpX_vDw for ; Sat, 9 Mar 2019 11:57:03 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id C18B1130DC2 for ; Sat, 9 Mar 2019 11:57:02 -0800 (PST) Received: from erg.abdn.ac.uk (at-www-1.erg.abdn.ac.uk [IPv6:2001:630:42:150::5]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id F2A991B000FD; Sat, 9 Mar 2019 19:56:56 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 09 Mar 2019 19:56:56 +0000 From: Raffaele Zullo To: Joe Touch Cc: "C. M. Heard" , Gorry Fairhurst , tsvwg In-Reply-To: References: Message-ID: X-Sender: raffaele@erg.abdn.ac.uk User-Agent: Roundcube Webmail/1.2.3 Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 19:57:05 -0000 Hi, On 2019-03-09 19:28, Joe Touch wrote: > 5. the LITE only case > > The whole point of LITE is that some of the IP payload isn’t > checksummed. > >> Given that we're supposed to veryify such receivers can accept >> LITE (w/o FRAG) and hold soft state, maybe this is acceptable? > > > We don’t have a requirement that such receivers can accept LITE before > we start using it, so soft state won’t help here. > >> we can send >> LITE (w/o FRAG) using UDP checksum of zero, and the additional >> option encoding the actual checksum for the UDP data. >> >> This additional checksum could simply be the existing defined >> ACS option. > > ACS uses a CRC, not IP checksum. That’s a LOT more work in software, > so this isn’t a viable alternative. > > IMO, we leave this one alone. The whole point of LITE is to do less > work - if that means the LITE data corrupts the entire packet, then so > be it. Then LITE basically fails. > > ------ The case of LITE or more generally when checksum should not cover the full Options area could be partially solved with a CCO of 4 bytes (the original CCO proposal had a variable length for further flexibility). the first 2 bytes contains the checksum of UDP Options you want to cover, the other 2 bytes contains the additional compensation value for the uncovered bytes, for the traversal only. The receiver can still validate the covered Options without the effort of summing the unnecessary Option bytes (e.g. LITE DATA), and without risking to drop a packet for an error on the uncovered bytes. Anyway the sender will still need to sum the uncovered bytes. Thank you, Raffaele Zullo From nobody Sat Mar 9 12:52:32 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DA9127598 for ; Sat, 9 Mar 2019 12:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 lTKhuXsVXVcG for ; Sat, 9 Mar 2019 12:52:28 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 983D812797A for ; Sat, 9 Mar 2019 12:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sofqgP+BM6MF3jRxiEDdkKJrD8wMGQx6k6ruUPDh3O0=; b=qMi5nhufBsFBeJ7MGzJN2x/QN u5U2ELreTLERtZ+94HUBrOIQy8D7Z1tuaXrfnukVl6cLebc9vk9NKFrddtZYJu9nB9opfc11yM1u0 jZZBmWPYi880eIsLs5TFmGkY+/wgIcVr64oNsfKw50Xcz5t4hrL6thwcFCxoMnfRNJ91A6ksBgBHC dGCrjQhoCFNp7Dk1ugS7mD+Kh/J4ZPQQ7xwZ0UN90PYT5plkM0NucJ6iZjFv3Ail45TJPBtjniuYC Gq7qph7Hwaa4DAqy/vVQjeDB48EsGowafqDPmC7oxS/MkVBzMqK4rMTY8Av6GsjFHxfgU6sG+uW1E cImvJpuiw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52083 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h2ixG-000h8G-BT; Sat, 09 Mar 2019 15:52:27 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_65CBBD81-6580-4DBD-B9E6-FADB5596474D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Sat, 9 Mar 2019 12:52:25 -0800 Cc: "C. M. Heard" , Gorry Fairhurst , tsvwg Message-Id: <136FF703-4DFE-4B32-A722-67122F28C894@strayalpha.com> References: To: Raffaele Zullo X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 20:52:31 -0000 --Apple-Mail=_65CBBD81-6580-4DBD-B9E6-FADB5596474D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 9, 2019, at 11:56 AM, Raffaele Zullo = wrote: >=20 > Hi, >=20 > On 2019-03-09 19:28, Joe Touch wrote: >>> ... >> ACS uses a CRC, not IP checksum. That=E2=80=99s a LOT more work in = software, >> so this isn=E2=80=99t a viable alternative. >> IMO, we leave this one alone. The whole point of LITE is to do less >> work - if that means the LITE data corrupts the entire packet, then = so >> be it. Then LITE basically fails. >> ------ >=20 > The case of LITE or more generally when checksum should not cover the = full Options area > could be partially solved with a CCO of 4 bytes > (the original CCO proposal had a variable length for further = flexibility). >=20 > the first 2 bytes contains the checksum of UDP Options you want to = cover, > the other 2 bytes contains the additional compensation value for the = uncovered bytes, for the traversal only. >=20 > The receiver can still validate the covered Options without the effort = of summing the unnecessary Option bytes (e.g. LITE DATA), > and without risking to drop a packet for an error on the uncovered = bytes. >=20 > Anyway the sender will still need to sum the uncovered bytes. Yes, but there are three points to LITE: 1. less work for the transmitter (which your proposal defeats) 2. less work for the receiver (which your proposal maintains) 3. deliver potentially corrupted data (one of the original points of = UDP-lite - it wasn=E2=80=99t just about performance) These errant middle boxes are also thus defeating #3. So, IMO, in the presence of those sorts of things, basically LITE with = our proposal doesn=E2=80=99t do most of what it was intended. Again, for that reason, I=E2=80=99d still prefer leaving it alone. Joe= --Apple-Mail=_65CBBD81-6580-4DBD-B9E6-FADB5596474D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 9, 2019, at 11:56 AM, Raffaele Zullo <raffaele@erg.abdn.ac.uk> wrote:

Hi,

On 2019-03-09 19:28, Joe Touch = wrote:
...
ACS uses = a CRC, not IP checksum. That=E2=80=99s a LOT more work in software,
so this isn=E2=80=99t a viable alternative.
IMO, = we leave this one alone. The whole point of LITE is to do less
work - if that means the LITE data corrupts the entire = packet, then so
be it. Then LITE basically fails.
------

The case of LITE or more generally when checksum should not = cover the full Options area
could be partially solved with a CCO of 4 bytes
(the original CCO proposal had a = variable length for further flexibility).

the first 2 bytes contains the checksum of UDP Options you = want to cover,
the other 2 bytes contains the additional compensation value = for the uncovered bytes, for the traversal only.

The receiver can still validate = the covered Options without the effort of summing the unnecessary Option = bytes (e.g. LITE DATA),
and without risking to drop a packet for an error on the = uncovered bytes.

Anyway the sender will still need to sum the uncovered = bytes.

Yes, but there = are three points to LITE:

1. less = work for the transmitter (which your proposal defeats)
2. less = work for the receiver (which your proposal maintains)
3. = deliver potentially corrupted data (one of the original points of = UDP-lite - it wasn=E2=80=99t just about performance)

These errant middle boxes are also thus defeating = #3.

So, IMO, in the presence of = those sorts of things, basically LITE with our proposal doesn=E2=80=99t = do most of what it was intended.

Again, for that reason, I=E2=80=99d still prefer = leaving it alone.

Joe
= --Apple-Mail=_65CBBD81-6580-4DBD-B9E6-FADB5596474D-- From nobody Sun Mar 10 12:25:56 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EE31200ED for ; Sun, 10 Mar 2019 12:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwHy9ESygrpU for ; Sun, 10 Mar 2019 12:25:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9206A12008F for ; Sun, 10 Mar 2019 12:25:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4BA9AB81D82; Sun, 10 Mar 2019 12:25:49 -0700 (PDT) To: david.black@dell.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, david.black@emc.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@bobbriscoe.net, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190310192549.4BA9AB81D82@rfc-editor.org> Date: Sun, 10 Mar 2019 12:25:49 -0700 (PDT) Archived-At: Subject: [tsvwg] [Editorial Errata Reported] RFC8311 (5649) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 19:25:54 -0000 The following errata report has been submitted for RFC8311, "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5649 -------------------------------------- Type: Editorial Reported by: Bob Briscoe Section: 3. Original Text ------------- see Appendix B.1 of [ECN-L4S]. Corrected Text -------------- see Appendix C.1 of [ECN-L4S]. Notes ----- At the end of Section 8. there is another reference to the same information in the same Appendix: See Appendix C.1 of [ECN-L4S] for discussion of alternatives to the ECN nonce. So we have to change one to be consistent with the other. Let's use C.1, because that is the current number of the appendix in the relevant draft. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8311 (draft-ietf-tsvwg-ecn-experimentation-08) -------------------------------------- Title : Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation Publication Date : January 2018 Author(s) : D. Black Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Sun Mar 10 15:01:05 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01455127598; Sun, 10 Mar 2019 15:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQTwML2TUeuJ; Sun, 10 Mar 2019 15:00:54 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C15124B19; Sun, 10 Mar 2019 15:00:53 -0700 (PDT) Received: from dancer.taht.net (c-73-162-29-198.hsd1.ca.comcast.net [73.162.29.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 4C19A2200A; Sun, 10 Mar 2019 22:00:50 +0000 (UTC) From: Dave Taht To: Cc: , , iesg@ietf.org, roland.bless@kit.edu, tsvwg-chairs@ietf.org, tsvwg@ietf.org References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> Date: Sun, 10 Mar 2019 15:00:47 -0700 In-Reply-To: (Ruediger Geib's message of "Mon, 25 Feb 2019 08:47:45 +0000") Message-ID: <87tvgao0ds.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 22:00:57 -0000 writes: > Deborah, Warren, > > IETF doesn't specify SLAs or related text, I agree. The LE performance > is worse than default forwarding. I'm unhappy if my peer demotes my > traffic to LE and points to an IETF standard allowing this. What > about: > > DISCUSSED CHANGE so far: > Non-LE traffic (e.g., BE traffic) SHOULD NOT be > remarked to LE on a regular basis. > > SOMEWHAT MORE PRECISELY DEFINED OPTION > Non-LE traffic (e.g., BE traffic) MUST NOT be > remarked to LE by default. > > I'd like to avoid LE to result in a "default below default" and prefer > IETF standards not allow fancy interpretations. I would prefer even stronger language than the above in this document. I have noted elsewhere that Comcast, at least, remarks *all* traffic it does not recognize to CS1 - when last I checked. This plays merry hell when diffserv is not washed out when it crosses into the home, and particularly wifi. While I would prefer they not fiddle with the bits at al= l... Precisely defined option: Non-LE traffic MUST NOT be remarked to LE. I might be willing to put in a caveat like: "unless the transit provider has extremely compelling reasons to have identified this traffic to be intended to cause harm, e.g. a DDOS attempt." > > Regards, > > Ruediger > > -----Urspr=C3=BCngliche Nachricht----- > Von: tsvwg Im Auftrag von BRUNGARD, DEBORAH A > Gesendet: Samstag, 23. Februar 2019 17:33 > An: Roland Bless ; Warren Kumari ; The IESG > Cc: tsvwg-chairs@ietf.org; tsvwg@ietf.org > Betreff: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-0= 9: (with DISCUSS and COMMENT) > > Hi Roland, > > On your comment:=20 > "In former times P2P file sharing traffic was throttled by some ISPs > without telling the users. The danger is that the same thing happens > with remarking traffic as LE, so IMHO the user should be informed at > least that traffic is downgraded. Maybe consent is too strong, so I > propose to delete "consent", but stay with "without knowledge of the > user" or I will rephrase it accordingly. However, it's still a SHOULD > NOT only." > > I can not comment on what some ISPs do and what is in their service > contracts. I am fine with this as a "SHOULD NOT". I am not fine with > saying anything about what a service operator needs to do regarding a > service contract. IETF hasn't in the past made these statements (btw - > ITU-T does not touch this either). Hint: I don't think pointing to > this RFC will help you. > > As Brian suggested, just keep the first part of the sentence. > > Thanks! > Deborah > > > -----Original Message----- > From: Roland Bless > Sent: Saturday, February 23, 2019 6:30 AM > To: BRUNGARD, DEBORAH A ; Warren Kumari ; The IESG > Cc: tsvwg-chairs@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-0= 9: (with DISCUSS and COMMENT) > > Hi Deborah, > > On 22.02.19 at 18:14 BRUNGARD, DEBORAH A wrote: >>> The main idea is that applications/users decide what traffic should >>> go to the "background", i.e., which packet are marked as LE >>> (end-to-end argument as hint: the >network lacks usually the >>> application knowledge). >>=20 >> I'll take the opportunity to jump in here=F0=9F=98=8A >>=20 >> This was my comment, I was confused, as there's a couple of places >> in this document which infer much more than previous RFCs on what a >> "user" can do vs. what a network operator can do. In my comment, I >> noted the sentence: > > Sorry, for causing confusion :-) > I was trying to answer the IESG comments one by one and didn't arrive at = yours yet, so I also jump in. > >> "However, non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to=20 >> LE on a regular basis without consent or knowledge of the user." >>=20 >> I scanned other RFCs, I don't see this requirement that an operator need= s to have the consent/knowledge of the user before remarking? Suggest simpl= y dropping the "without consent..." from the sentence. > > Your impression is probably right that this is not really consistent, bec= ause some of the text stems from RFC 3662 and some was added within this I-= D. > At the time of RFC 3662, the view was probably more toward: LE is mainly = a tool for network operators. > Yes, it is, but it's also a different question _who_ is actually deciding= what traffic is classified as LE. In the light of net neutrality debates, = it would be fair if the user classifies its traffic as LE if it is eligible= and I find it reasonable that providers should be transparent: if they use= LE as tool and downgrade users' traffic, they should say so, e.g., inform = the user that they downgrade under certain conditions. > > In former times P2P file sharing traffic was throttled by some ISPs witho= ut telling the users. The danger is that the same thing happens with remark= ing traffic as LE, so IMHO the user should be informed at least that traffi= c is downgraded. Maybe consent is too strong, so I propose to delete "conse= nt", but stay with "without knowledge of the user" or I will rephrase it ac= cordingly. However, it's still a SHOULD NOT only. > >> And the sentence in the abstract "Ideally, applications mark their packe= ts as LE traffic, since they know the urgency of flows." You answered Warre= n "The main idea is that applications/users decide what traffic should go t= o the "background", i.e., which packet are marked as LE (end-to-end argumen= t..". This is very confusing as it contradicts other RFCs where marking/re-= markings are tools for a network operator.=20 > > Besides the net-neutrality argument, the e2e argument is another good rea= son to only let user decide, what should go into this class. The user canno= t harm the network this way, so there is no reason for the Diffserv domain = to distrust this marking coming from the end-system. > For other Diffserv PHBs this IS different, because they are elevated serv= ices (i.e., better than best-effort): a Diffserv domain should either do th= e initial marking or at least apply policing at the ingress boundary nodes = - otherwise QoS guarantees may be at risk; here the markings from end-syste= ms cannot be trusted at least policing is required that may include re-mark= ing. So for the EF PHB for example, admission control and policing are esse= ntial. > >> It directly contradicts RFC8325/section 5.4: >> "An alternative option to mapping is for the administrator to treat the = wireless edge as the edge of the Diffserv domain and explicitly set (or res= et) DSCP markings in the upstream direction according to administrative pol= icy. This option is RECOMMENDED over mapping, as this typically is the mos= t secure solution because the network administrator directly enforces the D= iffserv policy across the IP network (versus an application developer and/o= r the developer of the operating system of the wireless endpoint device, wh= o may be functioning completely independently of the network administrator)= ." > > Yes, that's exactly what I explained in the preceding text above: > normally a Diffserv domain must strictly protect its network at the bound= ary. > >> I recognize this RFC maintains "no harm" saying "There is no incentive f= or DS domains to distrust this initial marking, because letting LE traffic = enter a DS domain causes no harm. Thus, any policing such as limiting the = rate of LE traffic is not necessary at the DS boundary." I'm a bit nervous = on that assumption, I think most operators would agree with Warren's title,= "hysterical raisins"=F0=9F=98=8A Can IETF really maintain (this is PS), "n= o worries"? > > Maybe I don't get the point. Under the assumption that this LE traffic wo= uld have been injected as normal default BE traffic otherwise, I don't see = any negative consequences for the provider. It is a different thing if the = user would refrain from injecting this traffic, because he/she wants to rea= lly only transmit this as background/scavenger traffic. > But compared to the alternative that this traffic would traverse the doma= in as BE traffic otherwise, I would confirm the "no worries" > property. > > Best regards, > Roland > >> -----Original Message----- >> From: iesg On Behalf Of Bless, Roland (TM) >> Sent: Thursday, February 21, 2019 10:04 AM >> To: Warren Kumari ; The IESG >> Cc: David Black ; tsvwg-chairs@ietf.org;=20 >> tsvwg@ietf.org >> Subject: Re: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09:=20 >> (with DISCUSS and COMMENT) >>=20 >> Hi Warren, >>=20 >> Am 20.02.19 um 18:16 schrieb Warren Kumari: >>> --------------------------------------------------------------------- >>> - >>> DISCUSS: >>> --------------------------------------------------------------------- >>> - >>> >>> I believe that this should be trivial DISCUSS to address, but I=20 >>> thought it important enough to warrant it. I'm OK with basically=20 >>> whatever you answer, I just wanted to make sure this had been seen and = considered. >>> >>> "An LE PHB SHOULD NOT be used for a customer=E2=80=99s "normal Internet" >>> traffic nor should packets be "downgraded" to the LE PHB instead of >>> being dropped, particularly when the packets are unauthorized >>> traffic. " >>=20 >> This was actually directly copied from RFC 3662. >>=20 >>> Great, sounds good to me -- but in the USA at least, there is are=20 >>> many cell phone plans which are "unlimited", but after some amount of=20 >>> traffic (e.g 22GB) your connection gets throttled to a lower data=20 >>> rate. Is this traffic still 'a customer's "normal Internet" traffic"? >>> Is it appropriate (whatever that means) to downgrade this traffic to=20 >>> the LE PHB? I understand not wanting to touch this issue with a 10=20 >>> foot pole (and I don't know what the right answer is!), but you *did*=20 >>> open this can of worms by talking about what classification user traffi= c should have. >>> >>> Note: I'm happy to clear my DISCUSS no matter what the answer is, I=20 >>> just want to make sure it has been considered / discussed. >>=20 >> The main idea is that applications/users decide what traffic should >> go to the "background", i.e., which packet are marked as LE >> (end-to-end argument as hint: the network lacks usually the >> application knowledge). >> Operators must have good reasons to deliberately downgrade users' >> normal traffic. In case of throttled traffic, this would still be >> considered as being normal BE traffic. One case for downgrading BE >> traffic could be non-admitted multicast replication traffic as >> described in RFC 3754. >>=20 >>> --------------------------------------------------------------------- >>> - >>> COMMENT: >>> --------------------------------------------------------------------- >>> - >>> >>> Major: >>> "Some network providers keep link utilization below 50% to ensure=20 >>> that all traffic is forwarded without loss after rerouting caused by=20 >>> a link failure (cf.Section 6 of [RFC3439]). LE marked traffic can=20 >>> utilize the normally unused capacity and will be preempted=20 >>> automatically in case of link failure when 100% of the link capacity=20 >>> is required for all other traffic. " Yup - very true. But I think it=20 >>> needs to be mentioned that the provider will need to upgrade their=20 >>> monitoring / management system so that they can see the traffic lass. >>> If they monitoring circuit utilization using e.g interface counters=20 >>> (and not by traffic class), a link may have 1% "real" traffic and 90%=20 >>> LE traffic, and it will look like it it 91% "full". I don't have any=20 >>> suggested text to address this (and this is just a comment, so "well,=20 >>> duh, they should know that anyway!" is a fine >>> answer.) >>=20 >> Thanks for the hint, valid point, but indeed: if they use Diffserv, >> they should also monitor the resource shares for each PHB >> individually. >>=20 >>> Nits: >>> "A main problem is that multicast" -- I'm not sure you can say "A=20 >>> main" - main implies singular.; I'd suggest "The main" or "A major". >>=20 >> Right. >>=20 >>> "However,using the Lower Effort PHB for multicast requires to pay=20 >>> special" -- "requires paying"... >>=20 >> Done. >>=20 >> Regards >> Roland >>=20 From nobody Sun Mar 10 15:11:52 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CAA127598 for ; Sun, 10 Mar 2019 15:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k708wsp5BWx1 for ; Sun, 10 Mar 2019 15:11:49 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10E4124B19 for ; Sun, 10 Mar 2019 15:11:48 -0700 (PDT) Received: from dancer.taht.net (c-73-162-29-198.hsd1.ca.comcast.net [73.162.29.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 12AC72200A for ; Sun, 10 Mar 2019 22:11:44 +0000 (UTC) From: Dave Taht To: tsvwg Date: Sun, 10 Mar 2019 15:11:43 -0700 Message-ID: <87pnqynzvk.fsf@taht.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [tsvwg] New draft uploaded: Some Congestion Experienced (draft-morton-taht-sce-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 22:11:50 -0000 It's unclear to me how to actually get this draft (add a -tsvwg to the name?) in front of this working group from the submittal process itself, but for your enjoyment, and perusal, it's up here, now, as an individual submission. https://datatracker.ietf.org/doc/draft-morton-taht-sce/?include_text=1 Abstract: This memo reclassifies ECT(1) to be an early notification of congestion on ECT(0) marked packets, which can be used by AQM algorithms and transports as an earlier signal of congestion than CE. It is a simple, transparent, and backward compatible upgrade to existing IETF-approved AQMs, RFC3168, and nearly all congestion control algorithms. From nobody Sun Mar 10 18:16:32 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27021286CD for ; Sun, 10 Mar 2019 18:16:19 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP40CvyelR7H for ; Sun, 10 Mar 2019 18:16:17 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0999E129A86 for ; Sun, 10 Mar 2019 18:16:17 -0700 (PDT) Received: from dancer.taht.net (c-73-162-29-198.hsd1.ca.comcast.net [73.162.29.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 2CBFD2200A; Mon, 11 Mar 2019 01:16:12 +0000 (UTC) From: Dave Taht To: tsvwg@ietf.org Cc: "Jonathan Morton" References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> Date: Sun, 10 Mar 2019 18:16:09 -0700 In-Reply-To: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Sun, 10 Mar 2019 18:11:57 -0700") Message-ID: <87h8canrc6.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 01:16:20 -0000 I think this gets the procedure right for submittal here. internet-drafts@ietf.org writes: > A new version of I-D, draft-morton-taht-tsvwg-sce-00.txt > has been successfully submitted by David M. T=C3=A4ht and posted to the > IETF repository. > > Name: draft-morton-taht-tsvwg-sce > Revision: 00 > Title: The Some Congestion Experienced ECN Codepoint > Document date: 2019-03-10 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-morton-taht-ts= vwg-sce-00.txt > Status: https://datatracker.ietf.org/doc/draft-morton-taht-tsvwg-= sce/ > Htmlized: https://tools.ietf.org/html/draft-morton-taht-tsvwg-sce-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-morton-taht-t= svwg-sce > > > Abstract: > This memo reclassifies ECT(1) to be an early notification of > congestion on ECT(0) marked packets, which can be used by AQM > algorithms and transports as an earlier signal of congestion than CE. > It is a simple, transparent, and backward compatible upgrade to > existing IETF-approved AQMs, RFC3168, and nearly all congestion > control algorithms. > >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Sun Mar 10 18:18:18 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9176E129A86 for ; Sun, 10 Mar 2019 18:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6jkVbhAKqOT for ; Sun, 10 Mar 2019 18:18:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6C9B21286CD for ; Sun, 10 Mar 2019 18:18:14 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 88A718FA155428641174; Mon, 11 Mar 2019 01:18:12 +0000 (GMT) Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Mar 2019 01:18:12 +0000 Received: from DGGEMI529-MBS.china.huawei.com ([169.254.5.3]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0399.000; Mon, 11 Mar 2019 09:18:05 +0800 From: "qiangli (D)" To: Tom Herbert CC: tsvwg , Toerless Eckert Thread-Topic: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) Thread-Index: AdTVTUw267hC5GTQTZyGvOBVjR2e1wAN/5oAAIfqJTA= Date: Mon, 11 Mar 2019 01:18:05 +0000 Message-ID: <06C389826B926F48A557D5DB5A54C4ED45BF5F52@dggemi529-mbs.china.huawei.com> References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 01:18:16 -0000 SGkgVG9tLA0KDQpJIGZ1bGx5IGFncmVlIHdpdGggeW91LCBIb3AtYnktaG9wIG9wdGlvbiBpcyBh biBlZmZlY3RpdmUgd2F5IHRvIHdvcmsgaW4gSVB2NiBzY2VuYXJpbywgd2UgYXJlIGFsc28gZ29p bmcgdG8gd29yayBvbiBpdCwgYW5kIFVEUCBvcHRpb24gaXMgYW5vdGhlciB3YXkuIEFzIHZlbmRv ciwgd2UgZG8gY2FyZSBhYm91dCBwcm9jZXNzaW5nIHBlcmZvcm1hbmNlLCBhbmQgd2UgYWxzbyB2 YWx1ZSBVRFAgb3B0aW9uIGFzIGEgcG90ZW50aWFsIHdheSBmb3IgZW5kLXVzZXIgdG8gZXhwcmVz cyB0aGVpciByZXF1aXJlbWVudCBkaXJlY3RseSB0byBuZXR3b3JrLCBzb21lIGV2YWx1YXRpb24g dGVzdCBpcyBuZWVkZWQuDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpDcmlzdGluYSBRSUFORw0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21A aGVyYmVydGxhbmQuY29tXSANClNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAwOSwgMjAxOSAxMjowMyBB TQ0KVG86IHFpYW5nbGkgKEQpIDxxaWFuZ2xpM0BodWF3ZWkuY29tPg0KQ2M6IHRzdndnIDx0c3Z3 Z0BpZXRmLm9yZz47IFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZT4NClN1YmplY3Q6IFJl OiBbdHN2d2ddIEEgTmV3IERyYWZ0IFVwbG9hZGVkIChkcmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0 aW9ucy1ib3VuZGVkLWxhdGVuY3ktMDApDQoNCk9uIFRodSwgTWFyIDcsIDIwMTkgYXQgNToyMiBQ TSBxaWFuZ2xpIChEKSA8cWlhbmdsaTNAaHVhd2VpLmNvbT4gd3JvdGU6DQo+DQo+IEhpIEFsbCwN Cj4NCj4NCj4NCj4gV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyBkcmFmdCAoZHJhZnQtcWlhbmctdHN2 d2ctdWRwLW9wdGlvbnMtYm91bmRlZC1sYXRlbmN5LTAwKSB0aGF0IGV4cGxvcmVzIHRoZSB1c2Ug b2YgVURQIG9wdGlvbnMgZm9yIGJvdW5kZWQgbGF0ZW5jeSBmb3J3YXJkaW5nLiBSZXZpZXcgYW5k IGNvbW1lbnQgaXMgaGlnaGx5IGFwcHJlY2lhdGVkLg0KPg0KSGkgQ3Jpc3RpbmEsDQoNCk9uZSBj b21tZW50Lg0KDQpGcm9tIHRoZSBkcmFmdDogIkhvd2V2ZXIgaW4gYW4gSVAgZGF0YSBwbGFuZSwg dGhlcmUgaXMgbm8gZW5vdWdoIHNwYWNlIGluIHRoZSBJUCBjb21tb24gaGVhZGVyLiINCg0KVGhp cyBpcyB3aGF0IGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBkZXNpZ25lZCBmb3IuIFRoZSBkcmFmdCBp cyBkZXNjcmliaW5nIHdoYXQgc2hvdWxkIGJlIGEgbmV3IEhvcC1ieS1Ib3Agb3B0aW9uLg0KDQpB bHNvLCBJIGRvbid0IHRoaW5rIHJvdXRlciB2ZW5kb3JzIGFyZSBnb2luZyB0byBiZSB2ZXJ5IGhh cHB5IGlmIHRoZXkgaGF2ZSB0byBzdGFydCBwYXJzaW5nIHBhY2tldCB0cmFpbGVycyBpbiB0aGUg aGlnaCBwZXJmb3JtYW5jZSBkYXRhIHBhdGguDQoNClRvbQ0KDQoNCj4NCj4NCj4NCj4NCj4gQmVz dCByZWdhcmRzLA0KPg0KPg0KPg0KPiBDcmlzdGluYSBRSUFORw0KPg0KPg0KPg0KPg0KPg0KPiA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+DQo+IEEgbmV3 IHZlcnNpb24gb2YgSS1ELCANCj4gZHJhZnQtcWlhbmctdHN2d2ctdWRwLW9wdGlvbnMtYm91bmRl ZC1sYXRlbmN5LTAwLnR4dA0KPg0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IExpIFFpYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4NCj4NCj4NCj4g TmFtZTogICAgICAgICAgICAgICBkcmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0aW9ucy1ib3VuZGVk LWxhdGVuY3kNCj4NCj4gUmV2aXNpb246ICAwMA0KPg0KPiBUaXRsZTogICAgICAgICAgICAgICAg ICBVRFAgT3B0aW9ucyBmb3IgQm91bmRlZCBMYXRlbmN5DQo+DQo+IERvY3VtZW50IGRhdGU6ICAg ICAgIDIwMTktMDMtMDgNCj4NCj4gR3JvdXA6ICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQo+DQo+IFBhZ2VzOiAgICAgICAgICAgICAgIDkNCj4NCj4gVVJMOiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1xaWFuZy10c3Z3Zy11 ZHAtb3B0aW9ucy1ib3VuZGVkLWxhdGVuY3ktMDAudHh0DQo+DQo+IFN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0 aW9ucy1ib3VuZGVkLWxhdGVuY3kvDQo+DQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcWlhbmctdHN2d2ctdWRwLW9wdGlvbnMtYm91bmRlZC1sYXRl bmN5LTAwDQo+DQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LXFpYW5nLXRzdndnLXVkcC1vcHRpb25zLWJvdW5kZWQtbGF0ZW5jeQ0K Pg0KPg0KPg0KPg0KPg0KPiBBYnN0cmFjdDoNCj4NCj4gICAgVGhpcyBkb2N1bWVudCBleHBsb3Jl cyB0aGUgdXNlIG9mIFVEUCBvcHRpb25zIGZvciBwYWNrZXQgZm9yd2FyZGluZw0KPg0KPiAgICB3 aXRoIGJvdW5kZWQgbGF0ZW5jeS4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlh dA0KPg0KPg0K From nobody Sun Mar 10 18:46:47 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683C612EB11 for ; Sun, 10 Mar 2019 18:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF5HlyHEAhH0 for ; Sun, 10 Mar 2019 18:46:42 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1ED7F130E2B for ; Sun, 10 Mar 2019 18:46:42 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0DF8C87A765BF4BFEDAA; Mon, 11 Mar 2019 01:46:40 +0000 (GMT) Received: from DGGEMI421-HUB.china.huawei.com (10.1.199.150) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Mar 2019 01:46:39 +0000 Received: from DGGEMI529-MBS.china.huawei.com ([169.254.5.3]) by dggemi421-hub.china.huawei.com ([10.1.199.150]) with mapi id 14.03.0415.000; Mon, 11 Mar 2019 09:46:33 +0800 From: "qiangli (D)" To: "Gorry (erg)" CC: Joe Touch , Toerless Eckert , "tsvwg@ietf.org" Thread-Topic: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) Thread-Index: AdTVTUw267hC5GTQTZyGvOBVjR2e1///oZEAgABM8YD//1lE4IAA3BEA//trxoA= Date: Mon, 11 Mar 2019 01:46:33 +0000 Message-ID: <06C389826B926F48A557D5DB5A54C4ED45BF7F7D@dggemi529-mbs.china.huawei.com> References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> <5C82257F.5030505@erg.abdn.ac.uk> <06C389826B926F48A557D5DB5A54C4ED45BE97A1@dggemi529-mbs.china.huawei.com> <6CE801F4-C954-40A1-AD7C-80991796BE18@erg.abdn.ac.uk> In-Reply-To: <6CE801F4-C954-40A1-AD7C-80991796BE18@erg.abdn.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 01:46:46 -0000 SGkgR29ycnksDQoNCj4+IEFoIEkgdGhpbmsgY2hhbmdpbmcgdGhlIHZhbHVlIGlzbuKAmXQgYWxs b3dlZC4gVGhlIG9wdGlvbiBmaWVsZHMgYXJlIHNldCBieSB0aGUgc2VuZGVyIGFuZCBpbW11dGFi bGUgLSB0aGV5IG1heSBiZSByZWFkYWJsZSBpbiBwYXRoLCBidXQgdGhlIHdheSB0aGV5IGFyZSBk ZWZpbmVkIGRvZXMgbm90IG1ha2UgaXQgZWFzeSBvciBkZXNpcmFibGUgdG8gY2hhbmdlIGFsb25n IHRoZSBwYXRoLg0KDQpXZSBoYXZlIHRoZSBzYW1lIGNvbmNlcm4gb24gIkluLXRyYW5zaXQgcmV3 cml0aW5nIiwgdGhhdCdzIHdoeSB3ZSBzcGVjaWZpY2FsbHkgd3JvdGUgdGhlIGZvbGxvd2luZyB0 ZXh0IGluIG91ciBkb2N1bWVudDoNCiJJZiB0aGVyZSBpcyBvbmx5IG9uZSBTQyBvcHRpb24gY2Fy cmllZCBpbiBhIHBhY2tldCwgdGhlIEN5Y2xlX0lkZW50aWZpZXIgZmllbGQgbWF5IG5lZWQgdG8g YmUgcmV3cml0dGVuIGJlZm9yZSByZS1zZW5kaW5nIG91dC4gT25lIHdheSB0byByZWxpZXZlIGlu LXRyYW5zaXQgcmV3cml0aW5nIGlzIHRvIHByZS1jb21wdXRlIHRoZSBzZW5kaW5nIGN5Y2xlcyBh bG9uZyB0aGUgd2F5LCB0aGVuIGNhcnJ5IHRoZW0gd2l0aCBtdWx0aXBsZSBTQyBvcHRpb25zLiIN Cg0KQW5kIEkgd2FzIHdvbmRlcmluZyBpZiB0aGUgcHJvcG9zZWQgc29sdXRpb24gInByZS1jb21w dXRlIHRoZSBzZW5kaW5nIGN5Y2xlcyBhbG9uZyB0aGUgd2F5LCB0aGVuIGNhcnJ5IHRoZW0gd2l0 aCBtdWx0aXBsZSBTQyBvcHRpb25zLiIgaXMgYWNjZXB0YWJsZS4gVGhhbmtzIQ0KDQoNCkJlc3Qg cmVnYXJkcywNCg0KQ3Jpc3RpbmEgUUlBTkcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogR29ycnkgKGVyZykgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10gDQpTZW50 OiBGcmlkYXksIE1hcmNoIDA4LCAyMDE5IDc6MzAgUE0NClRvOiBxaWFuZ2xpIChEKSA8cWlhbmds aTNAaHVhd2VpLmNvbT4NCkNjOiBKb2UgVG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29tPjsgVG9l cmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPjsgdHN2d2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbdHN2d2ddIEEgTmV3IERyYWZ0IFVwbG9hZGVkIChkcmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0 aW9ucy1ib3VuZGVkLWxhdGVuY3ktMDApDQoNClNlZSBiZWxvdy4NCg0KPiBPbiA4IE1hciAyMDE5 LCBhdCAxMDo0NCwgcWlhbmdsaSAoRCkgPHFpYW5nbGkzQGh1YXdlaS5jb20+IHdyb3RlOg0KPiAN Cj4gSGkgSm9lIGFuZCBHb3JyeSwNCj4gDQo+IFRoYW5rcyBhIGxvdCBmb3IgeW91ciBjb21tZW50 cy4gV2lsbCBtYWtlIG1vZGlmaWNhdGlvbiBhY2NvcmRpbmdseSBhbmQgdXBkYXRlIGJlZm9yZSBJ RVRGIDEwNCBtZWV0aW5nLiANCj4gDQpHcmVhdCB0aGUgY3V0b2ZmIGlzIE1vbmRheS4NCg0KPj4+ ICgzKSBJcyBMZW5ndGggaW4gZmlndXJlIDUgcmVhbGx5IDEgYnl0ZT8gVGhpcyBpcyB0aGUgdG90 YWwgbGVuZ3RoIG9mIHRoZSBvcHRpb24sIGFuZCBJIHNlZSB5b3UgaGF2ZSBhdCBsZWFzdCBvbmUg Ynl0ZSBhZGRpdGlvbmFsLiBJcyB5b3VyIGxlbmd0aCBvZiB0aGUgb3B0aW9uIHZhcmlhYmxlIG9y IGZpeGVkPw0KPiANCj4gWWVzLCAxIGJ5dGUgaXMgZW5vdWdoLiBTaW5jZSBlYWNoIG5vZGUgaGFz IDMgcXVldWVzLCBuZWVkIG1pbmltYWwgMiBiaXRzICg0IGRpZmZlcmVudCB2YWx1ZXMpIHRvIGlu ZGljYXRlIHdoaWNoIHF1ZXVlIGEgcGFja2V0IHNob3VsZCBlbnRlci4NCj4gDQpJIHNlZS4NCg0K Pj4+ICJPbmUgd2F5IHRvIHJlbGlldmUgaW4tdHJhbnNpdCByZXdyaXRpbmcgaXMgdG8gcHJlLWNv bXB1dGUgdGhlIA0KPj4+IHNlbmRpbmcNCj4gICAgY3ljbGVzIGFsb25nIHRoZSB3YXksIHRoZW4g Y2FycnkgdGhlbSB3aXRoIG11bHRpcGxlIFNDIG9wdGlvbnMuIg0KPiANCj4gVGhlIDIgYml0cycg dmFsdWUgd2lsbCBiZSBjaGFuZ2VkL3Jld3JpdHRlbiBob3AtYnktaG9wLCB0aGF0IGlzIHdoYXQg DQo+IHdlIGNhbGwgIiBpbi10cmFuc2l0IHJld3JpdGluZyAiIC0tLS0gU1dBUCBtZXRob2QgV2Ug bWF5IHVzZSBTVEFDSyBtZXRob2QgdG8gcmVkdWNlIHN1Y2ggIiBpbi10cmFuc2l0IHJld3JpdGlu ZyAiLiBXaWxsIHJlZmluZSB0aGlzIHBhcnQgaW4gMDEgdmVyc2lvbi4NCj4gDQpBaCBJIHRoaW5r IGNoYW5naW5nIHRoZSB2YWx1ZSBpc27igJl0IGFsbG93ZWQuIFRoZSBvcHRpb24gZmllbGRzIGFy ZSBzZXQgYnkgdGhlIHNlbmRlciBhbmQgaW1tdXRhYmxlIC0gdGhleSBtYXkgYmUgcmVhZGFibGUg aW4gcGF0aCwgYnV0IHRoZSB3YXkgdGhleSBhcmUgZGVmaW5lZCBkb2VzIG5vdCBtYWtlIGl0IGVh c3kgb3IgZGVzaXJhYmxlIHRvIGNoYW5nZSBhbG9uZyB0aGUgcGF0aC4NCg0KPj4+IHdoeSBpdCB3 b3VsZG7igJl0IGJlIHN1ZmZpY2llbnQgdG8ganVzdCByZXF1ZXN0IHRoZSBuZXh0IG9wZW4gdmFs dWU/DQo+IFRoZSByZWFzb24gdGhhdCB3aHkgd2Ugd3JvdGUgIjEyNyIgaXMgIjEyNy0yNTMiIGlz IGEgcmVzZXJ2ZWQgcmVnaW9uIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9u cy0wNiwgd2lsbCBjaGFuZ2UgIjEyNyIgdG8gIlRCRCIgaW4gMDEgdmVyc2lvbi4NCk9LDQoNCj4g VGhhbmsgeW91IGFnYWluLg0KPiANCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gDQo+IENyaXN0aW5h IFFJQU5HDQo+IA0KR29ycnkNCg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogR29ycnkgRmFpcmh1cnN0IFttYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWtdDQo+IFNl bnQ6IEZyaWRheSwgTWFyY2ggMDgsIDIwMTkgNDoxOSBQTQ0KPiBUbzogSm9lIFRvdWNoIDx0b3Vj aEBzdHJheWFscGhhLmNvbT4NCj4gQ2M6IHFpYW5nbGkgKEQpIDxxaWFuZ2xpM0BodWF3ZWkuY29t PjsgVG9lcmxlc3MgRWNrZXJ0IA0KPiA8dHRlQGNzLmZhdS5kZT47IHRzdndnQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbdHN2d2ddIEEgTmV3IERyYWZ0IFVwbG9hZGVkIA0KPiAoZHJhZnQtcWlh bmctdHN2d2ctdWRwLW9wdGlvbnMtYm91bmRlZC1sYXRlbmN5LTAwKQ0KPiANCj4gSSdtIHJlYWxs eSBlbmNvdXJhZ2luZyB5b3UgdG8gZG8gYSBxdWljayByZXZpc2lvbjogSXQgd291bGQgYmUgcmVh bGx5IGhlbHBmdWwgaWYgeW91IGRpZCB0aGUgdXBkYXRlIHN1Z2dlc3RlZCBieSBKb2UsIHRvIGFs aWduIHNvIGl0J3MgY29uZm9ybWFudCB3aXRoIHRoZSB3YXkgaW4gd2hpY2ggdGhlIGFzc2lnbm1l bnRzIGFyZSBzdXBwb3NlZCB0byBiZSBtYWRlLg0KPiANCj4gQSBmZXcgcXVpY2sgb2JzZXJ2YXRp b25zIG9uIHRoZSAtMDAgZHJhZnQ6DQo+IA0KPiAoMSkgUGxlYXNlIHJlcGxhY2UgdGhlICJLSU5E IiBudW1iZXIgd2l0aCB0aGUgdGV4dCAiVEJEIiwgYW5kIHNlZSBKb2UncyBjb21tZW50IG9uIHRo ZSBJQU5BIHNlY3Rpb24uDQo+IA0KPiAoMikgVGhpcyBtYXkgaXMgYSBjaGFuY2UgdG8gZml4IHRo aXMgdHlwbyB0aGF0IG9jY3VycyBzZXZlcmFsIHBsYWNlczogDQo+IC9maWxlZC9maWVsZC8uDQo+ IA0KPiAoMykgSXMgTGVuZ3RoIGluIGZpZ3VyZSA1IHJlYWxseSAxIGJ5dGU/IFRoaXMgaXMgdGhl IHRvdGFsIGxlbmd0aCBvZiB0aGUgb3B0aW9uLCBhbmQgSSBzZWUgeW91IGhhdmUgYXQgbGVhc3Qg b25lIGJ5dGUgYWRkaXRpb25hbC4gSXMgeW91ciBsZW5ndGggb2YgdGhlIG9wdGlvbiB2YXJpYWJs ZSBvciBmaXhlZD8NCj4gDQo+ICg0KSBJIGRvbid0IHVuZGVyc3RhbmQgdGhpczoNCj4gDQo+ICAg Ik9uZSB3YXkgdG8gcmVsaWV2ZSBpbi10cmFuc2l0IHJld3JpdGluZyBpcyB0byBwcmUtY29tcHV0 ZSB0aGUgc2VuZGluZw0KPiAgICBjeWNsZXMgYWxvbmcgdGhlIHdheSwgdGhlbiBjYXJyeSB0aGVt IHdpdGggbXVsdGlwbGUgU0Mgb3B0aW9ucy4iDQo+IA0KPiBJIHdvbmRlcjogRG8geW91IGltYWdp bmUgdGhlIHBhdGggYWRkcyBvcHRpb25zIGFzIHRoZSBwYWNrZXQgdHJhdmVscyB0aHJvdWdoIHRo ZSByb3V0ZXJzPyBPciBpcyB0aGlzIGEgc3VnZ2VzdGlvbiB0aGF0IHRoZSBvcHRpb24gZmllbGQg Y2FuIGhhdmUgbXVsdGlwbGUgdmFsdWVzIHByZXNlbnQgd2l0aGluIHRoaXM/ICBUaGVzZSBhcmUg cXVpdGUgZGlmZmVyZW50IHByb3Bvc2FscywgYW5kIEkgc3VnZ2VzdCB5b3UgcGxhY2UgdGhpcyB0 ZXh0IGluIGEgc2VwYXJhdGUgc3Vic2VjdGlvbj8NCj4gDQo+IEJlc3Qgd2lzaGVzLA0KPiANCj4g R29ycnkNCj4gDQo+IA0KPj4gT24gMDgvMDMvMjAxOSwgMDM6NDMsIEpvZSBUb3VjaCB3cm90ZToN Cj4+IFR3byBwb2ludHMgKHRoZSBmaXJzdCBpcyB1c2VmdWwgZm9yIGV2ZXJ5b25lIGRldmVsb3Bp bmcgdXBjb21pbmcgVURQDQo+PiBvcHRpb25zKToNCj4+IA0KPj4gMS4gcHJvcG9zYWxzIGZvciBu ZXcgVURQIG9wdGlvbnMgc2hvdWxkIGluZGljYXRlIGEgS0lORCB2YWx1ZSBvZiDigJxUQkTigJ0g DQo+PiBvbmx5OyB0aGV5IHNob3VsZCBub3Qg4oCYc3F1YXTigJkgb3IgcHJlc2VsZWN0IGEgdmFs dWUgdW50aWwgYXNzaWduZWQgYnkgDQo+PiBJQU5BICh3aGVuIHRoZSBVRFAgb3B0aW9ucyBkb2Mg aXMgcHVibGlzaGVkKSBvciAtIHVudGlsIHRoZSBVRFAgZG9jIA0KPj4gaXMgcHVibGlzaGVkIC0g YXQgbGVhc3QgdGhlIGRvYyBpcyBhY2NlcHRlZCBhcyBhIFdHIGRvYy4NCj4+IA0KPj4gMi4gYSBy ZXF1ZXN0IGZvciBzdWNoIGFzc2lnbm1lbnQgc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBJQU5B IA0KPj4gY29uc2lkZXJhdGlvbnMgcG9ydGlvbiBvZiB0aGF0IGRvY3VtZW50DQo+PiANCj4+IFRo ZXNlIGFyZSBjb21tb24gY29udmVudGlvbnMgZm9yIGFzc2lnbmVkIG51bWJlcnMgaW4gZ2VuZXJh bC4NCj4+IA0KPj4gQXMgYSByZXN1bHQsIEkgZW5jb3VyYWdlIHRoZSBhdXRob3JzIHRvIHF1aWNr bHkgaXNzdWUgYW4gdXBkYXRlIHRvIA0KPj4gdGhpcyBkb2MgdGhhdCBmb2xsb3dzIHRoZSBhYm92 ZSBjb252ZW50aW9uLg0KPj4gDQo+PiBBZGRpdGlvbmFsbHksIGlmIGFjY2VwdGVkLCBjYW4geW91 IGV4cGxhaW4gd2h5IGl0IHdvdWxkbuKAmXQgYmUgDQo+PiBzdWZmaWNpZW50IHRvIGp1c3QgcmVx dWVzdCB0aGUgbmV4dCBvcGVuIHZhbHVlPw0KPj4gDQo+PiBKb2UNCj4+IA0KPj4+IE9uIE1hciA3 LCAyMDE5LCBhdCA1OjIyIFBNLCBxaWFuZ2xpIChEKSA8cWlhbmdsaTNAaHVhd2VpLmNvbSANCj4+ PiA8bWFpbHRvOnFpYW5nbGkzQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+PiANCj4+PiBIaSBBbGws DQo+Pj4gV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyBkcmFmdA0KPj4+IChkcmFmdC1xaWFuZy10c3Z3 Zy11ZHAtb3B0aW9ucy1ib3VuZGVkLWxhdGVuY3ktMDApIHRoYXQgZXhwbG9yZXMgdGhlIA0KPj4+ IHVzZSBvZiBVRFAgb3B0aW9ucyBmb3IgYm91bmRlZCBsYXRlbmN5IGZvcndhcmRpbmcuIFJldmll dyBhbmQgDQo+Pj4gY29tbWVudCBpcyBoaWdobHkgYXBwcmVjaWF0ZWQuDQo+Pj4gQmVzdCByZWdh cmRzLA0KPj4+IENyaXN0aW5hIFFJQU5HDQo+Pj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KPj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELA0KPj4+IGRyYWZ0 LXFpYW5nLXRzdndnLXVkcC1vcHRpb25zLWJvdW5kZWQtbGF0ZW5jeS0wMC50eHQNCj4+PiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExpIFFpYW5nIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgDQo+Pj4gcmVwb3NpdG9yeS4NCj4+PiBOYW1lOiAgICAgICAgICAgICAgIGRyYWZ0LXFp YW5nLXRzdndnLXVkcC1vcHRpb25zLWJvdW5kZWQtbGF0ZW5jeQ0KPj4+IFJldmlzaW9uOiAgMDAN Cj4+PiBUaXRsZTogICAgICAgICAgICAgICAgICBVRFAgT3B0aW9ucyBmb3IgQm91bmRlZCBMYXRl bmN5DQo+Pj4gRG9jdW1lbnQgZGF0ZTogICAgICAgMjAxOS0wMy0wOA0KPj4+IEdyb3VwOiAgICAg ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4+IFBhZ2VzOiAgICAgICAgICAgICAg IDkNCj4+PiBVUkw6IA0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0aW9ucy1iDQo+Pj4gbw0KPj4+IHVuZGVkLWxhdGVuY3kt MDAudHh0DQo+Pj4gU3RhdHVzOiANCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0aW9ucy1ib3VuZA0KPj4+IGUNCj4+PiBkLWxhdGVu Y3kvDQo+Pj4gSHRtbGl6ZWQ6IA0KPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1xaWFuZy10c3Z3Zy11ZHAtb3B0aW9ucy1ib3VuZGVkLWxhDQo+Pj4gdA0KPj4+IGVuY3ktMDAN Cj4+PiBIdG1saXplZDogDQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1xaWFuZy10c3Z3Zy11ZHAtb3B0aW9ucy0NCj4+PiBiDQo+Pj4gb3VuZGVkLWxhdGVu Y3kNCj4+PiBBYnN0cmFjdDoNCj4+PiAgIFRoaXMgZG9jdW1lbnQgZXhwbG9yZXMgdGhlIHVzZSBv ZiBVRFAgb3B0aW9ucyBmb3IgcGFja2V0IGZvcndhcmRpbmcNCj4+PiAgIHdpdGggYm91bmRlZCBs YXRlbmN5Lg0KPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSANCj4+PiBhdHRvb2xzLmlldGYub3JnIDxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCj4+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4gDQo+ IA0KDQo= From nobody Sun Mar 10 18:54:09 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E126130DE3 for ; Sun, 10 Mar 2019 18:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn3Co_-PfuGU for ; Sun, 10 Mar 2019 18:54:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C6CD8130E00 for ; Sun, 10 Mar 2019 18:54:03 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DAFFE32A24566C25C027; Mon, 11 Mar 2019 01:54:01 +0000 (GMT) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Mar 2019 01:54:01 +0000 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 11 Mar 2019 01:54:01 +0000 Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Mon, 11 Mar 2019 01:54:00 +0000 Received: from DGGEMI529-MBS.china.huawei.com ([169.254.5.3]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0399.000; Mon, 11 Mar 2019 09:53:57 +0800 From: "qiangli (D)" To: Joe Touch , "gorry@erg.abdn.ac.uk" CC: Toerless Eckert , "tsvwg@ietf.org" Thread-Topic: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) Thread-Index: AdTVTUw267hC5GTQTZyGvOBVjR2e1///oZEAgABM8YD//1lE4IABOreA//vD5HA= Date: Mon, 11 Mar 2019 01:53:57 +0000 Message-ID: <06C389826B926F48A557D5DB5A54C4ED45BF7F98@dggemi529-mbs.china.huawei.com> References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> <5C82257F.5030505@erg.abdn.ac.uk> <06C389826B926F48A557D5DB5A54C4ED45BE97A1@dggemi529-mbs.china.huawei.com> <7d691ac5-3655-59ac-60cc-221b6a39717e@strayalpha.com> In-Reply-To: <7d691ac5-3655-59ac-60cc-221b6a39717e@strayalpha.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_06C389826B926F48A557D5DB5A54C4ED45BF7F98dggemi529mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 01:54:08 -0000 --_000_06C389826B926F48A557D5DB5A54C4ED45BF7F98dggemi529mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEpvZSwgIG1heSBJIHVuZGVyc3RhbmQgeW91ciBjb21tZW50cyBhcyB5b3VyIHN1cHBv cnQgZm9yIHRoaXMgYXBwcm9hY2ggLS0tIOKAnHByZS1jb21wdXRlIHRoZSBzZW5kaW5nIGN5Y2xl cyBhbG9uZyB0aGUgd2F5LCB0aGVuIGNhcnJ5IHRoZW0gd2l0aCBtdWx0aXBsZSBTQyBvcHRpb25z LiIgPyAgSWYgdGhhdCBzbywgSeKAmW0gZ2xhZCB0byBtYWtlIG1vZGlmaWNhdGlvbiBhY2NvcmRp bmdseS4NCg0KDQo+PiBUaGUgdmFsdWVzIHlvdSB3YW50IHRvIHJlcXVlc3QgYXJlIGZyb20gdGhl ICJ1bmFzc2lnbmVkIiByYW5nZS4NCkkgc2VlLiBUaGFuayB5b3UhDQoNCg0KDQpCZXN0IHJlZ2Fy ZHMsDQoNCkNyaXN0aW5hIFFJQU5HDQoNCkZyb206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQHN0 cmF5YWxwaGEuY29tXQ0KU2VudDogU2F0dXJkYXksIE1hcmNoIDA5LCAyMDE5IDE6MDkgQU0NClRv OiBxaWFuZ2xpIChEKSA8cWlhbmdsaTNAaHVhd2VpLmNvbT47IGdvcnJ5QGVyZy5hYmRuLmFjLnVr DQpDYzogVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPjsgdHN2d2dAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbdHN2d2ddIEEgTmV3IERyYWZ0IFVwbG9hZGVkIChkcmFmdC1xaWFuZy10c3Z3 Zy11ZHAtb3B0aW9ucy1ib3VuZGVkLWxhdGVuY3ktMDApDQoNCg0KTm90ZXMgYmVsb3cuLi4NCk9u IDMvOC8yMDE5IDI6NDQgQU0sIHFpYW5nbGkgKEQpIHdyb3RlOg0KDQoiT25lIHdheSB0byByZWxp ZXZlIGluLXRyYW5zaXQgcmV3cml0aW5nIGlzIHRvIHByZS1jb21wdXRlIHRoZSBzZW5kaW5nDQoN CiAgICBjeWNsZXMgYWxvbmcgdGhlIHdheSwgdGhlbiBjYXJyeSB0aGVtIHdpdGggbXVsdGlwbGUg U0Mgb3B0aW9ucy4iDQoNCg0KDQpUaGUgMiBiaXRzJyB2YWx1ZSB3aWxsIGJlIGNoYW5nZWQvcmV3 cml0dGVuIGhvcC1ieS1ob3AsIHRoYXQgaXMgd2hhdCB3ZSBjYWxsICIgaW4tdHJhbnNpdCByZXdy aXRpbmcgIiAtLS0tIFNXQVAgbWV0aG9kDQoNCldlIG1heSB1c2UgU1RBQ0sgbWV0aG9kIHRvIHJl ZHVjZSBzdWNoICIgaW4tdHJhbnNpdCByZXdyaXRpbmcgIi4gV2lsbCByZWZpbmUgdGhpcyBwYXJ0 IGluIDAxIHZlcnNpb24uDQoNClVEUCBvcHRpb25zIE1VU1QgTk9UIGNoYW5nZSBpbi10cmFuc2l0 LiAoYW55dGhpbmcgdGhhdCBkb2VzIGNoYW5nZSBpbi10cmFuc2l0IHdvdWxkIG5vdCBiZSBlbGln aWJsZSBmb3IgYSBVRFAgb3B0aW9uIEtJTkQgYXNzaWdubWVudCkuDQoNClNvIGl0IHdvdWxkIGJl IHVzZWZ1bCBmb3IgdGhpcyByZXYgdG8gZGVzY3JpYmUgT05MWSB0aGUgY2FzZSB3aGVyZSBpdCBp cyBpbW11dGFibGUuDQoNCg0KDQp3aHkgaXQgd291bGRu4oCZdCBiZSBzdWZmaWNpZW50IHRvIGp1 c3QgcmVxdWVzdCB0aGUgbmV4dCBvcGVuIHZhbHVlPw0KDQpUaGUgcmVhc29uIHRoYXQgd2h5IHdl IHdyb3RlICIxMjciIGlzICIxMjctMjUzIiBpcyBhIHJlc2VydmVkIHJlZ2lvbiBkZWZpbmVkIGlu IGRyYWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMtMDYsDQoNCi4uLg0KDQpJJ2xsIG5vdGUgdGhh dCAicmVzZXJ2ZWQiIG1lYW5zIHlvdSB3b24ndCBnZXQgdGhvc2U7IHRoZXkncmUgc2V0IGFzaWRl IGZvciBiYXNlIHByb3RvY29sIGV4dGVuc2lvbnMgKGkuZS4sIHVwZGF0ZXMgdG8gdGhlIFVEUCBv cHRpb24gZGVmaW5pdGlvbiBpdHNlbGYsIHJhdGhlciB0aGFuIGluZGl2aWR1YWwgb3B0aW9ucyku DQoNClRoZSB2YWx1ZXMgeW91IHdhbnQgdG8gcmVxdWVzdCBhcmUgZnJvbSB0aGUgInVuYXNzaWdu ZWQiIHJhbmdlLg0KDQpKb2UNCg== --_000_06C389826B926F48A557D5DB5A54C4ED45BF7F98dggemi529mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovk vZM7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovk vZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBKb2UsICZuYnNwO21heSBJ IHVuZGVyc3RhbmQgeW91ciBjb21tZW50cyBhcyB5b3VyIHN1cHBvcnQgZm9yIHRoaXMgYXBwcm9h Y2ggLS0tIOKAnHByZS1jb21wdXRlIHRoZSBzZW5kaW5nIGN5Y2xlcyBhbG9uZyB0aGUgd2F5LCB0 aGVuIGNhcnJ5IHRoZW0NCiB3aXRoIG11bHRpcGxlIFNDIG9wdGlvbnMuJnF1b3Q7ID8gJm5ic3A7 SWYgdGhhdCBzbywgSeKAmW0gZ2xhZCB0byBtYWtlIG1vZGlmaWNhdGlvbiBhY2NvcmRpbmdseS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZn dDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHZhbHVlcyB5b3Ugd2FudCB0byByZXF1 ZXN0IGFyZSBmcm9tIHRoZSAmcXVvdDt1bmFzc2lnbmVkJnF1b3Q7IHJhbmdlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBzZWUuIFRoYW5rIHlvdSE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlm eTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNyaXN0aW5hIFFJQU5H PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBzdHJheWFscGhhLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWFyY2ggMDksIDIwMTkgMTowOSBBTTxicj4NCjxiPlRv OjwvYj4gcWlhbmdsaSAoRCkgJmx0O3FpYW5nbGkzQGh1YXdlaS5jb20mZ3Q7OyBnb3JyeUBlcmcu YWJkbi5hYy51azxicj4NCjxiPkNjOjwvYj4gVG9lcmxlc3MgRWNrZXJ0ICZsdDt0dGVAY3MuZmF1 LmRlJmd0OzsgdHN2d2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10g QSBOZXcgRHJhZnQgVXBsb2FkZWQgKGRyYWZ0LXFpYW5nLXRzdndnLXVkcC1vcHRpb25zLWJvdW5k ZWQtbGF0ZW5jeS0wMCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3RlcyBiZWxvdy4uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+T24gMy84LzIwMTkgMjo0NCBBTSwgcWlhbmdsaSAoRCkgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtPbmUg d2F5IHRvIHJlbGlldmUgaW4tdHJhbnNpdCByZXdyaXRpbmcgaXMgdG8gcHJlLWNvbXB1dGUgdGhl IHNlbmRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBjeWNsZXMg YWxvbmcgdGhlIHdheSwgdGhlbiBjYXJyeSB0aGVtIHdpdGggbXVsdGlwbGUgU0Mgb3B0aW9ucy4m cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhl IDIgYml0cycgdmFsdWUgd2lsbCBiZSBjaGFuZ2VkL3Jld3JpdHRlbiBob3AtYnktaG9wLCB0aGF0 IGlzIHdoYXQgd2UgY2FsbCAmcXVvdDsgaW4tdHJhbnNpdCByZXdyaXRpbmcgJnF1b3Q7IC0tLS0g U1dBUCBtZXRob2Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPldlIG1heSB1c2UgU1RBQ0sgbWV0aG9kIHRvIHJlZHVjZSBzdWNoICZxdW90OyBpbi10cmFu c2l0IHJld3JpdGluZyAmcXVvdDsuIFdpbGwgcmVmaW5lIHRoaXMgcGFydCBpbiAwMSB2ZXJzaW9u LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIj5VRFAgb3B0aW9ucyBNVVNUIE5PVCBjaGFuZ2UgaW4tdHJhbnNpdC4gKGFueXRoaW5n IHRoYXQgZG9lcyBjaGFuZ2UgaW4tdHJhbnNpdCB3b3VsZCBub3QgYmUgZWxpZ2libGUgZm9yIGEg VURQIG9wdGlvbiBLSU5EIGFzc2lnbm1lbnQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLVVTIj5TbyBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIHRoaXMgcmV2IHRvIGRl c2NyaWJlIE9OTFkgdGhlIGNhc2Ugd2hlcmUgaXQgaXMgaW1tdXRhYmxlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij53aHkgaXQgd291bGRuPC9zcGFuPuKAmTxzcGFuIGxhbmc9IkVOLVVTIj50IGJlIHN1ZmZpY2ll bnQgdG8ganVzdCByZXF1ZXN0IHRoZSBuZXh0IG9wZW4gdmFsdWU/PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGUgcmVhc29uIHRoYXQgd2h5IHdlIHdyb3RlICZxdW90OzEyNyZxdW90OyBpcyAmcXVv dDsxMjctMjUzJnF1b3Q7IGlzIGEgcmVzZXJ2ZWQgcmVnaW9uIGRlZmluZWQgaW4gZHJhZnQtaWV0 Zi10c3Z3Zy11ZHAtb3B0aW9ucy0wNiwgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiPkknbGwgbm90ZSB0aGF0ICZxdW90O3Jlc2VydmVkJnF1b3Q7 IG1lYW5zIHlvdSB3b24ndCBnZXQgdGhvc2U7IHRoZXkncmUgc2V0IGFzaWRlIGZvciBiYXNlIHBy b3RvY29sIGV4dGVuc2lvbnMgKGkuZS4sIHVwZGF0ZXMgdG8gdGhlIFVEUCBvcHRpb24gZGVmaW5p dGlvbiBpdHNlbGYsIHJhdGhlciB0aGFuIGluZGl2aWR1YWwgb3B0aW9ucykuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSB2YWx1ZXMgeW91IHdhbnQgdG8g cmVxdWVzdCBhcmUgZnJvbSB0aGUgJnF1b3Q7dW5hc3NpZ25lZCZxdW90OyByYW5nZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Sm9lPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_06C389826B926F48A557D5DB5A54C4ED45BF7F98dggemi529mbschi_-- From nobody Sun Mar 10 20:28:29 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10D6130E83 for ; Sun, 10 Mar 2019 20:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 1KnMjIomSyi0 for ; Sun, 10 Mar 2019 20:28:27 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 E6A44130DCB for ; Sun, 10 Mar 2019 20:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=G67N+8GNysCM1Id6OQyoeQY7SN7lznHK0PsnZraTzAU=; b=BK8yl517vk3UUAq116x8+XLnOq z0qf65waurlEJhq+Wys3Zq4/5wyRan67sQ6d3Z7RcTrGofZgy16fmy5UghGh7C6v8yn/VY9H8N17e g1gVcsW6hWPKbJLNm/DAD6vOWzS26ckNhXjpxqVwnmhxBfbZGjC0RO9TkgXeCjhkQk2d/I0HOEMEj m9Fdet5urwZWLhyMcoLdrH0afRcbhIgVA5LxAWojziVb9vPQtBD2GkjoYwSET3xSdpHFt6ogZWehQ SCpO1yzePrMJrNPRLn4omioXJWOQJVsv1oc8vAvzzIiXERk+snRJWwswPB7OYq9raTXDez1/btjho 6LMnQYeA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62981 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h3Bbs-0027SC-Oc; Sun, 10 Mar 2019 23:28:17 -0400 To: "qiangli (D)" , Tom Herbert Cc: Toerless Eckert , tsvwg References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> <06C389826B926F48A557D5DB5A54C4ED45BF5F52@dggemi529-mbs.china.huawei.com> From: Joe Touch Message-ID: Date: Sun, 10 Mar 2019 20:28:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <06C389826B926F48A557D5DB5A54C4ED45BF5F52@dggemi529-mbs.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 03:28:28 -0000 On 3/10/2019 6:18 PM, qiangli (D) wrote: > we also value UDP option as a potential way for end-user to express their requirement directly to network, This seems misguided to me. Transport headers and options are intended for endpoints; if you need to express information to the network, it should be in the network headers. Joe From nobody Sun Mar 10 20:30:08 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30505130E6B for ; Sun, 10 Mar 2019 20:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 0hl86D9UiU1W for ; Sun, 10 Mar 2019 20:30:05 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 50351130DCB for ; Sun, 10 Mar 2019 20:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Czw/Ljccuw6cfRrEP6F+TpshblQ9hvl0x9hleoA60W4=; b=yJtqDa6qBO/KDrOrnxWLE9OTf cUpu3zyAxnLxd6n0WT9umurVIP2ZayfcoxP7q7LDwUREsNlKimXC4rCHpm60eRTmHNVkb+euYyZNV bioGrG0dvVJMQx/TMDClSP/BO/MywPSKbOYDSUqHXZIOTYJglLYlAmDXi7KWryxX3q9SyIo3bInEv p2iIv4LwiARaDxdXLMc+BbY4EoF3YAkWhcBabJiE1GNesavFBD4xkE5UILLMgQQwlhjc/HL4ZyH4c BpAWEKQ1AeIqWgtIEdq+TTe33xULmcUvIdX8nm9pK4pwZ4Zb4+S9F+8EKj9pjDvu+it41U9mjRrYY xfqGpgYAw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62989 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h3Bdb-0028rZ-6X; Sun, 10 Mar 2019 23:30:03 -0400 To: "qiangli (D)" , "gorry@erg.abdn.ac.uk" Cc: Toerless Eckert , "tsvwg@ietf.org" References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> <5C82257F.5030505@erg.abdn.ac.uk> <06C389826B926F48A557D5DB5A54C4ED45BE97A1@dggemi529-mbs.china.huawei.com> <7d691ac5-3655-59ac-60cc-221b6a39717e@strayalpha.com> <06C389826B926F48A557D5DB5A54C4ED45BF7F98@dggemi529-mbs.china.huawei.com> From: Joe Touch Message-ID: <49a7ea78-eb88-2a18-1c1f-eb866bec3c90@strayalpha.com> Date: Sun, 10 Mar 2019 20:30:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <06C389826B926F48A557D5DB5A54C4ED45BF7F98@dggemi529-mbs.china.huawei.com> Content-Type: multipart/alternative; boundary="------------96107A35F0732AD055ABAAC3" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 03:30:06 -0000 This is a multi-part message in MIME format. --------------96107A35F0732AD055ABAAC3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 3/10/2019 6:53 PM, qiangli (D) wrote: >  may I understand your comments as your support for this approach --- > “pre-compute the sending cycles along the way, then carry them with > multiple SC options." ?  I don't quite understand what you're trying to accomplish. As per my other note, I don't think transport headers should be used as a way to communicate with network devices EXCEPT at the endpoints. So even if the values in the options do not change (is that your intent above?), I still would not suggest this as a useful UDP option. Joe --------------96107A35F0732AD055ABAAC3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 3/10/2019 6:53 PM, qiangli (D) wrote:
 may I understand your comments as your support for this approach --- “pre-compute the sending cycles along the way, then carry them with multiple SC options." ? 

I don't quite understand what you're trying to accomplish.

As per my other note, I don't think transport headers should be used as a way to communicate with network devices EXCEPT at the endpoints.

So even if the values in the options do not change (is that your intent above?), I still would not suggest this as a useful UDP option.

Joe

--------------96107A35F0732AD055ABAAC3-- From nobody Mon Mar 11 02:24:33 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B66F13111D; Mon, 11 Mar 2019 02:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, L_8BIT_MISMATCH=0.01, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV0vvaFjbEgW; Mon, 11 Mar 2019 02:24:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2A313104D; Mon, 11 Mar 2019 02:24:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 540E0B8223C; Mon, 11 Mar 2019 02:24:10 -0700 (PDT) To: ietf@bobbriscoe.net, david.black@dell.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@kuehlewind.net, iesg@ietf.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190311092410.540E0B8223C@rfc-editor.org> Date: Mon, 11 Mar 2019 02:24:10 -0700 (PDT) Archived-At: Subject: [tsvwg] [Errata Verified] RFC8311 (5649) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 09:24:26 -0000 The following errata report has been verified for RFC8311, "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5649 -------------------------------------- Status: Verified Type: Editorial Reported by: Bob Briscoe Date Reported: 2019-03-10 Verified by: Mirja Kühlewind (IESG) Section: 3. Original Text ------------- see Appendix B.1 of [ECN-L4S]. Corrected Text -------------- see Appendix C.1 of [ECN-L4S]. Notes ----- At the end of Section 8. there is another reference to the same information in the same Appendix: See Appendix C.1 of [ECN-L4S] for discussion of alternatives to the ECN nonce. So we have to change one to be consistent with the other. Let's use C.1, because that is the current number of the appendix in the relevant draft. -------------------------------------- RFC8311 (draft-ietf-tsvwg-ecn-experimentation-08) -------------------------------------- Title : Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation Publication Date : January 2018 Author(s) : D. Black Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Mar 11 02:24:46 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EB41310F4 for ; Mon, 11 Mar 2019 02:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=dell.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 gNH_BMboZUzQ for ; Mon, 11 Mar 2019 02:24:33 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 5B85B131155 for ; Mon, 11 Mar 2019 02:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1552296273; x=1583832273; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L/UYN1MAtX+t0fzO2hr65EDFzZ7AlwVmOtAf78gBPr4=; b=he4DNj2CCQvyR8S9tUPN1z3BrGLsnpcj2POn/zsAJzsVhfbYxlVFZBDN ozz/2cX+S/NQQOpLyrPW/ZashCjAq4SWor6dNqbpEveUI+isp+BZ9q2vA pTcEsne6Uh8jI/N7ckHc+FzfWbq/fdn6wULPylrYJaZHRRXJO0Vn9R/aT 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ENAAADKIZchieV50NkDg0BAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVIFAQEBCwGBPIEqEYEDJwqDf4h5jFyJMY51FIFnCwEBIwuEPgI?= =?us-ascii?q?XhCMiNQgNAQEDAQEHAQMCAQECEAEBARMLCCkjDII6IhxNawEBAQEBASMCDWM?= =?us-ascii?q?BAQEEEhERKxoMBAIBCBEEAQEDAgYgAgICHxEVCAgCBAENBQgagwABgV0DFQE?= =?us-ascii?q?OomY9Am+BAYkHAQEBb4Evh3kNgh+BCyQBiyyBWD6BEUaCTIFBgRaBdwESASG?= =?us-ascii?q?DCDGCJgOKGiaCCoYJkRszAwQCAo9Mg1eBeYVmi1uKeIcWizECBAIEBQIVgUg?= =?us-ascii?q?BNWdxcC+DDQmCG4hohQQ7QTGNfoEfgR8BAQ?= X-IPAS-Result: =?us-ascii?q?A2ENAAADKIZchieV50NkDg0BAQEBAwEBAQcDAQEBgVIFA?= =?us-ascii?q?QEBCwGBPIEqEYEDJwqDf4h5jFyJMY51FIFnCwEBIwuEPgIXhCMiNQgNAQEDA?= =?us-ascii?q?QEHAQMCAQECEAEBARMLCCkjDII6IhxNawEBAQEBASMCDWMBAQEEEhERKxoMB?= =?us-ascii?q?AIBCBEEAQEDAgYgAgICHxEVCAgCBAENBQgagwABgV0DFQEOomY9Am+BAYkHA?= =?us-ascii?q?QEBb4Evh3kNgh+BCyQBiyyBWD6BEUaCTIFBgRaBdwESASGDCDGCJgOKGiaCC?= =?us-ascii?q?oYJkRszAwQCAo9Mg1eBeYVmi1uKeIcWizECBAIEBQIVgUgBNWdxcC+DDQmCG?= =?us-ascii?q?4hohQQ7QTGNfoEfgR8BAQ?= Received: from mx0a-00154901.pphosted.com ([67.231.149.39]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 11 Mar 2019 04:24:31 -0500 Received: from pps.filterd (m0142699.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2B9NOKS060886 for ; Mon, 11 Mar 2019 05:24:30 -0400 Received: from esa3.dell-outbound2.iphmx.com (esa3.dell-outbound2.iphmx.com [68.232.154.63]) by mx0a-00154901.pphosted.com with ESMTP id 2r5mg7g519-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 11 Mar 2019 05:24:30 -0400 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA256; 11 Mar 2019 15:24:21 +0600 Received: from maildlpprd03.lss.emc.com ([10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x2B9OJnM013114 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Mar 2019 05:24:24 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x2B9OJnM013114 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 11 Mar 2019 05:23:47 -0400 Received: from MXHUB303.corp.emc.com ([10.146.3.29]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x2B9Nvuw010235 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 11 Mar 2019 05:23:57 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0415.000; Mon, 11 Mar 2019 05:23:56 -0400 To: "spencerdawkins.ietf@gmail.com" , "ietf@kuehlewind.net" , "gorry@erg.abdn.ac.uk" , "wes@mti-systems.com" CC: "ietf@bobbriscoe.net" , "tsvwg@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC8311 (5649) Thread-Index: AQHU13cXU+l81gQ41E2rbZkdqWe3eaYGKQFg Date: Mon, 11 Mar 2019 09:23:55 +0000 Message-ID: References: <20190310192549.4BA9AB81D82@rfc-editor.org> In-Reply-To: <20190310192549.4BA9AB81D82@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.79.20.255] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=610 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110071 Archived-At: Subject: Re: [tsvwg] [Editorial Errata Reported] RFC8311 (5649) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 09:24:45 -0000 Qm9iIGNvbnRhY3RlZCBtZSBkaXJlY3RseSBhYm91dCB0aGlzIGVycmF0YSAtIGZyb20gd2hhdCBJ IGNhbiBzZWUsIHRoZSBCLjEgcmVmZXJlbmNlIHNob3VsZCd2ZSBiZWVuIHRvIEMuMSBpbiB0aGUg Zmlyc3QgcGxhY2UsIHNvIHRoaXMgZXJyYXRhIHNob3VsZCBiZSBhcHByb3ZlZCwgDQoNClRoYW5r cywgLS1EYXZpZCAoUkZDIDgzMTEgYXV0aG9yKQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3Jn Pg0KPiBTZW50OiBTdW5kYXksIE1hcmNoIDEwLCAyMDE5IDM6MjYgUE0NCj4gVG86IEJsYWNrLCBE YXZpZDsgc3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb207IGlldGZAa3VlaGxld2luZC5uZXQ7 IEJsYWNrLA0KPiBEYXZpZDsgZ29ycnlAZXJnLmFiZG4uYWMudWs7IHdlc0BtdGktc3lzdGVtcy5j b20NCj4gQ2M6IGlldGZAYm9iYnJpc2NvZS5uZXQ7IHRzdndnQGlldGYub3JnOyByZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnDQo+IFN1YmplY3Q6IFtFZGl0b3JpYWwgRXJyYXRhIFJlcG9ydGVkXSBS RkM4MzExICg1NjQ5KQ0KPiANCj4gDQo+IFtFWFRFUk5BTCBFTUFJTF0NCj4gDQo+IFRoZSBmb2xs b3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzgzMTEsDQo+ICJS ZWxheGluZyBSZXN0cmljdGlvbnMgb24gRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24g KEVDTikNCj4gRXhwZXJpbWVudGF0aW9uIi4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0 Og0KPiBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ1NjQ5DQo+IA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUeXBlOiBFZGl0b3JpYWwNCj4g UmVwb3J0ZWQgYnk6IEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2UubmV0Pg0KPiANCj4gU2Vj dGlvbjogMy4NCj4gDQo+IE9yaWdpbmFsIFRleHQNCj4gLS0tLS0tLS0tLS0tLQ0KPiBzZWUgQXBw ZW5kaXggQi4xIG9mIFtFQ04tTDRTXS4NCj4gDQo+IENvcnJlY3RlZCBUZXh0DQo+IC0tLS0tLS0t LS0tLS0tDQo+IHNlZSBBcHBlbmRpeCBDLjEgb2YgW0VDTi1MNFNdLg0KPiANCj4gTm90ZXMNCj4g LS0tLS0NCj4gQXQgdGhlIGVuZCBvZiBTZWN0aW9uIDguIHRoZXJlIGlzIGFub3RoZXIgcmVmZXJl bmNlIHRvIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluDQo+IHRoZSBzYW1lIEFwcGVuZGl4Og0KPiAN Cj4gICAgU2VlIEFwcGVuZGl4IEMuMSBvZiBbRUNOLUw0U10gZm9yIGRpc2N1c3Npb24gb2YgYWx0 ZXJuYXRpdmVzIHRvIHRoZQ0KPiAgICBFQ04gbm9uY2UuDQo+IA0KPiBTbyB3ZSBoYXZlIHRvIGNo YW5nZSBvbmUgdG8gYmUgY29uc2lzdGVudCB3aXRoIHRoZSBvdGhlci4gTGV0J3MgdXNlIEMuMSwN Cj4gYmVjYXVzZSB0aGF0IGlzIHRoZSBjdXJyZW50IG51bWJlciBvZiB0aGUgYXBwZW5kaXggaW4g dGhlIHJlbGV2YW50IGRyYWZ0Lg0KPiANCj4gSW5zdHJ1Y3Rpb25zOg0KPiAtLS0tLS0tLS0tLS0t DQo+IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElmIG5l Y2Vzc2FyeSwgcGxlYXNlDQo+IHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQg c2hvdWxkIGJlIHZlcmlmaWVkIG9yDQo+IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVh Y2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eQ0KPiBjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3Rh dHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCj4gDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFJGQzgzMTEgKGRyYWZ0LWlldGYtdHN2d2ct ZWNuLWV4cGVyaW1lbnRhdGlvbi0wOCkNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gVGl0bGUgICAgICAgICAgICAgICA6IFJlbGF4aW5nIFJlc3RyaWN0aW9ucyBv biBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKQ0KPiBFeHBlcmltZW50YXRp b24NCj4gUHVibGljYXRpb24gRGF0ZSAgICA6IEphbnVhcnkgMjAxOA0KPiBBdXRob3IocykgICAg ICAgICAgIDogRC4gQmxhY2sNCj4gQ2F0ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNUQU5E QVJEDQo+IFNvdXJjZSAgICAgICAgICAgICAgOiBUcmFuc3BvcnQgQXJlYSBXb3JraW5nIEdyb3Vw DQo+IEFyZWEgICAgICAgICAgICAgICAgOiBUcmFuc3BvcnQNCj4gU3RyZWFtICAgICAgICAgICAg ICA6IElFVEYNCj4gVmVyaWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCg== From nobody Mon Mar 11 02:39:47 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2194D12E036 for ; Mon, 11 Mar 2019 02:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSAnnm4R5NKK for ; Mon, 11 Mar 2019 02:39:44 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 EAF96127968 for ; Mon, 11 Mar 2019 02:39:43 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3HPJ-0007lj-QX; Mon, 11 Mar 2019 10:39:41 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1h3HPJ-0003ZP-3j; Mon, 11 Mar 2019 10:39:41 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: <87h8canrc6.fsf@taht.net> Date: Mon, 11 Mar 2019 10:39:40 +0100 Cc: tsvwg@ietf.org, Jonathan Morton Content-Transfer-Encoding: quoted-printable Message-Id: <3CA247DE-4CA2-46CB-8367-E96889D808A8@ifi.uio.no> References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> To: Dave Taht X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 34D793B1C49EAB5F7782F1D4D1E7C4659CE48914 Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 09:39:46 -0000 Hi, Regarding this paragraph: *** The underlying cause is the very sharp "multiplicative decrease" reaction required of transport protocols to congestion signalling (whether that be packet loss or CE marks), which tends to leave the congestion window significantly smaller than the ideal BDP when triggered at only slightly above the ideal value. The availability of this sharp response is required to assure network stability (AIMD principle), but there is presently no standardised and backwards- compatible means of providing a less drastic signal. *** FWIW, TCP Alternative Backoff with ECN (ABE), RFC 8511, tries to address = exactly that problem without requiring an extra code point. The underlying logic is: when ECN is signalled, chances are that there's = an AQM algorithm in place, and the queue is probably short - hence the = very sharp response is probably not appropriate. Cheers, Michael > On 11 Mar 2019, at 02:16, Dave Taht wrote: >=20 >=20 > I think this gets the procedure right for submittal here. >=20 > internet-drafts@ietf.org writes: >=20 >> A new version of I-D, draft-morton-taht-tsvwg-sce-00.txt >> has been successfully submitted by David M. T=C3=A4ht and posted to = the >> IETF repository. >>=20 >> Name: draft-morton-taht-tsvwg-sce >> Revision: 00 >> Title: The Some Congestion Experienced ECN Codepoint >> Document date: 2019-03-10 >> Group: Individual Submission >> Pages: 7 >> URL: = https://www.ietf.org/internet-drafts/draft-morton-taht-tsvwg-sce-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-morton-taht-tsvwg-sce/ >> Htmlized: = https://tools.ietf.org/html/draft-morton-taht-tsvwg-sce-00 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-morton-taht-tsvwg-sce >>=20 >>=20 >> Abstract: >> This memo reclassifies ECT(1) to be an early notification of >> congestion on ECT(0) marked packets, which can be used by AQM >> algorithms and transports as an earlier signal of congestion than = CE. >> It is a simple, transparent, and backward compatible upgrade to >> existing IETF-approved AQMs, RFC3168, and nearly all congestion >> control algorithms. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >=20 From nobody Mon Mar 11 02:43:44 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE03127968; Mon, 11 Mar 2019 02:43:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <155229741545.16956.12342830618638891939@ietfa.amsl.com> Date: Mon, 11 Mar 2019 02:43:35 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 09:43:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet Authors : Godred Fairhurst Colin Perkins Filename : draft-ietf-tsvwg-transport-encrypt-05.txt Pages : 43 Date : 2019-03-11 Abstract: This document describes implications of applying end-to-end encryption at the transport layer. It identifies in-network uses of transport layer header information. It then reviews the implications of developing end-to-end transport protocols that use authentication to protect the integrity of transport information or encryption to provide confidentiality of the transport protocol header and expected implications of transport protocol design and network operation. Since transport measurement and analysis of the impact of network characteristics have been important to the design of current transport protocols, it also considers the impact on transport and application evolution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 03:01:30 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539B6130DE6 for ; Mon, 11 Mar 2019 03:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXbp4LByofwB for ; Mon, 11 Mar 2019 03:01:26 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B62D1277E7 for ; Mon, 11 Mar 2019 03:01:26 -0700 (PDT) Received: from Gs-MacBook-Pro.local (unknown [86.111.164.170]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B7AA31B0023D for ; Mon, 11 Mar 2019 10:01:23 +0000 (GMT) Message-ID: <5C8631F3.3080302@erg.abdn.ac.uk> Date: Mon, 11 Mar 2019 10:01:23 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org References: <155229741545.16956.12342830618638891939@ietfa.amsl.com> In-Reply-To: <155229741545.16956.12342830618638891939@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 10:01:29 -0000 Hi TSVWG, We made a quick update to fix typos and one edit that was pending. The new revision is below. We don't know of further pending issues. Gorry On 11/03/2019, 09:43, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group WG of the IETF. > > Title : The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet > Authors : Godred Fairhurst > Colin Perkins > Filename : draft-ietf-tsvwg-transport-encrypt-05.txt > Pages : 43 > Date : 2019-03-11 > > Abstract: > This document describes implications of applying end-to-end > encryption at the transport layer. It identifies in-network uses of > transport layer header information. It then reviews the implications > of developing end-to-end transport protocols that use authentication > to protect the integrity of transport information or encryption to > provide confidentiality of the transport protocol header and expected > implications of transport protocol design and network operation. > Since transport measurement and analysis of the impact of network > characteristics have been important to the design of current > transport protocols, it also considers the impact on transport and > application evolution. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-05 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 05:39:18 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5119113107E; Mon, 11 Mar 2019 05:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx1k2iWTDEel; Mon, 11 Mar 2019 05:39:04 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (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 8EE90131055; Mon, 11 Mar 2019 05:39:04 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 141.3.10.8 id 1h3KCm-00044L-7G; Mon, 11 Mar 2019 13:38:56 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id ECF91420430; Mon, 11 Mar 2019 13:38:55 +0100 (CET) To: Alissa Cooper , The IESG Cc: David Black , tsvwg-chairs@ietf.org, tsvwg@ietf.org References: <155070472609.31486.14832014530010443987.idtracker@ietfa.amsl.com> From: "Bless, Roland (TM)" Openpgp: preference=signencrypt Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= xsFNBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABzShSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+wsGABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEzsFNBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABwsFlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Mon, 11 Mar 2019 13:38:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155070472609.31486.14832014530010443987.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1552307936.312865008 Archived-At: Subject: Re: [tsvwg] Alissa Cooper's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 12:39:16 -0000 Hi Alissa, Am 21.02.19 um 00:18 schrieb Alissa Cooper: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > = Section 3 = > > "An LE PHB SHOULD NOT be used for a customer's "normal Internet" > traffic nor should packets be "downgraded" to the LE PHB instead of > being dropped, particularly when the packets are unauthorized > traffic." > > I would recommend against mixing normative and non-normative keywords for a > sequence of behaviors listed in the same sentence. I can't determine why one of > these is normative and the other not. Right, that was overlooked and is fixed as also suggested by Mirja in the next revision. > "There is no intrinsic reason to limit the applicability of the LE PHB > to any particular application or type of traffic." > > I get the idea of not wanting to imply any kind of limitation, but wouldn't use > cases of applying this to real-time traffic be pretty rare? That seems like a > caveat worth explaining. Right. I added a sentence. > = Section 15 = > > RFC 8174 should be a normative reference. Corrected. Thanks, Roland From nobody Mon Mar 11 06:24:34 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DF61277D8; Mon, 11 Mar 2019 06:24:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <155231067350.23172.12127461551160739529@ietfa.amsl.com> Date: Mon, 11 Mar 2019 06:24:33 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-le-phb-10.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 13:24:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : A Lower Effort Per-Hop Behavior (LE PHB) for Differentiated Services Author : Roland Bless Filename : draft-ietf-tsvwg-le-phb-10.txt Pages : 21 Date : 2019-03-11 Abstract: This document specifies properties and characteristics of a Lower Effort (LE) per-hop behavior (PHB). The primary objective of this LE PHB is to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, best-effort traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard DSCP value for the LE PHB. This specification obsoletes RFC 3662 and updates the DSCP recommended in RFC 4594 and RFC 8325 to use the DSCP assigned in this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-10 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-le-phb-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-le-phb-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 06:34:57 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE359129AA0; Mon, 11 Mar 2019 06:34:47 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huCf8C8ExcBY; Mon, 11 Mar 2019 06:34:46 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (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 C3CAA1277D8; Mon, 11 Mar 2019 06:34:45 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 141.3.10.8 id 1h3L4k-0002HJ-Q1; Mon, 11 Mar 2019 14:34:42 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id A3A16420430; Mon, 11 Mar 2019 14:34:42 +0100 (CET) To: Spencer Dawkins at IETF References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> Cc: "tsvwg@ietf.org" , "iesg@ietf.org" , "tsvwg-chairs@ietf.org" From: "Bless, Roland (TM)" Openpgp: preference=signencrypt Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= xsFNBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABzShSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+wsGABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEzsFNBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABwsFlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Mon, 11 Mar 2019 14:34:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1552311282.895018562 Archived-At: Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 13:34:48 -0000 Hi Spencer, Am 28.02.19 um 19:30 schrieb Spencer Dawkins at IETF: > Roland, could you submit an updated version of this draft, so I can > approve it before Wednesday of IETF 104? :-)  Somewhat later than planned, but draft v10 has just been posted. It should cover all IESG comments (unless I overlooked something). Name: draft-ietf-tsvwg-le-phb Revision: 10 Title: A Lower Effort Per-Hop Behavior (LE PHB) for Differentiated Services Document date: 2019-03-11 Group: tsvwg Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-le-phb-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ Htmlized: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-10 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-le-phb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-le-phb-10 Regards Roland From nobody Mon Mar 11 09:26:34 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B40131113 for ; Mon, 11 Mar 2019 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 tqQhhwW5KCTe for ; Mon, 11 Mar 2019 09:26:23 -0700 (PDT) Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92900127963 for ; Mon, 11 Mar 2019 09:26:22 -0700 (PDT) Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 701085EBD1 for ; Mon, 11 Mar 2019 12:26:20 -0400 (EDT) (envelope-from heard@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=bwjCOsIdxV1a0dFckuuKE1U0Bog=; b=hHwwB3 hd9WMkOv0/1HcWVWvqHWIsiM2u2upqVoWgUcDHVyoNe3pDAPTsKlzrxE9t1jK7Ei 0WNDv7faWG6ABZ29tKUguEMByG6iVQ9kX62jxOljDTHSk1Ip5bQp2d4RDK2oqnKT lt0krpVD+TMQR+oOGPZ+njEcXEFMPptlT+fm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=gaL26FmaBWzm2VGMxYZXpEbnZyHKndHp SFbgAvw7KlCcC/e+OBNxGxsD8wYDty4oXt7yXEcQR3Yvmd/OMzkMaYGJEXKebjOG Do71JI55MbP7stAgBWxnG+dJ4U0fpuKZct7cv6103FSys/36sIpS/tgHSA3mPfbS 1lCtmEjAKHA= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 6869C5EBD0 for ; Mon, 11 Mar 2019 12:26:20 -0400 (EDT) (envelope-from heard@pobox.com) Received: from mail-it1-f178.google.com (unknown [209.85.166.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 08F275EBCF for ; Mon, 11 Mar 2019 12:26:18 -0400 (EDT) (envelope-from heard@pobox.com) Received: by mail-it1-f178.google.com with SMTP id w18so8235031itj.4 for ; Mon, 11 Mar 2019 09:26:18 -0700 (PDT) X-Gm-Message-State: APjAAAXV4bArFbNeK4cAjkgsgmPO3in7+z0uIhdxzaslLuYgXZ9EwUXI df6m8UU+VHAmihwDYhabqo/WwuRs24eLQ94A09o= X-Google-Smtp-Source: APXvYqzVaoNT2FO2Uv6rgy7CafSdEa9U+0nV048Z/UAMaoUblwPsIACyqWGeOgmPCq2oIGQ0tPUqwcoeK3hIeTedR+k= X-Received: by 2002:a24:5647:: with SMTP id o68mr317544itb.151.1552321576728; Mon, 11 Mar 2019 09:26:16 -0700 (PDT) MIME-Version: 1.0 References: <136FF703-4DFE-4B32-A722-67122F28C894@strayalpha.com> In-Reply-To: <136FF703-4DFE-4B32-A722-67122F28C894@strayalpha.com> From: "C. M. Heard" Date: Mon, 11 Mar 2019 09:26:04 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch , tsvwg Cc: Raffaele Zullo , Gorry Fairhurst , Tom Jones Content-Type: multipart/alternative; boundary="0000000000002883570583d40829" X-Pobox-Relay-ID: 65DFA8F0-441A-11E9-8AFC-D01F9763A999-06080547!pb-smtp20.pobox.com Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:26:33 -0000 --0000000000002883570583d40829 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 9 Mar 2019 11:28:57 -0800 Joe Touch wrote: > > This one=E2=80=99s a bit long - we need to converge quickly if the draft = is going > to be updated in time for the cutoff. > > Please comment asap=E2=80=A6 > > Joe > > PS =3D yes, we talk about TLV but need to explain that some options are > exceptions (OCS, NOP, EOL). I also need to update the OCS to be 3 bytes > long (in the table and figure). Those are in addition to the issues below= . > > ------- > > Raffaelo and Mike both pointed out: > > > On Mar 9, 2019, at 5:23 AM, C. M. Heard wrote: > > ... > > the errant middleboxes that CCO is designed to work around do not use the > > correct length value in their (re)computation of the UDP checksum. ... > > Well, there are several implications here: > > 1. we can add in the option length, BUT that also means: > (a) we need to declare that the option area consumes the whole of > the surplus area (no chance for other uses) > OR > (b) that the surplus area is always zero > OR > (c) that OCS covers even the surplus area (it doesn=E2=80=99t nee= d to be > zero; it does need to be included) > > we need a choice here. AFAICT, the safest (a) I agree with that. > 2. we don=E2=80=99t need OCS alignment; what we do need is to =E2=80=9Cco= ordinate=E2=80=9D the alignment of a 16-bit of the length to the OCS checksum field > i.e.: > - calculate the length needed (IPlen - UDP len) > - if OCS checksum field is not 16-bit aligned to the start of the > option area, then swap bytes > - add the result to the OCS checksum (=E2=80=98pseudo header=E2= =80=99 seems a bit > heavy here, but same point) I believe that is correct. Padding could still be convenient, though, and I see no reason to disallow it (the current draft does permit padding for alignment). > As Derek noted: > > As I recall the LITE+FRAG use case has no data in the UDP payload > > (i.e UDP header length is zero)? > > > > For this case, there is another way to work around a broken path (be it > > boxes, NICs, or whatever), that is simply to send with UDP header checksum > > of zero, and contain any necessary checksums in the UDP slack space. > > > 3. we have to deal with LITE/LITE+FRAG > we *can* use UDP CS=3D0, but that also may involve overriding the > user=E2=80=99s desires here (i.e., the user API says =E2=80=9Cuse= UDP CS=E2=80=9D and we=E2=80=99re > not doing that) which means we have a choice: > (d) override so that things work, i.e., force UDP CS=3D0 and then > (d.1) do OCS as a check on our stuff only > OR > (d.2) disallow the use of OCS (if CS=3D0, what=E2=80=99s = the point?) > OR > (d.3) use OCS=3D0 (this seems like a waste) > OR > (e) ignore the user setting of CS, then: > (e.1) always do OCS as a check > OR > (e.2) if UDP CS=3D0, omit OCS (save space), basically lik= e d.2 > OR > (e.3) if UDP CS=3D0, use OCS=3D0 (basically like e.2 > > If we do any of the (e) variants, we could either: > (f.1) require users to disable UDP CS to use OCS > OR > (f.2) ignore the user UDP CS setting > > So which is it? > > I don=E2=80=99t like assuming user correct configuration (f.1). > > So to me it=E2=80=99s (f.2) and (d.1). > > Thoughts? I'm skeptical about this proposal, because it requires making a for how OCS is calculated for the specific case of LITE+FRAG, and there are all manner of corner cases that will make that difficult to draft. In addition, the UDP header itself would not be covered by a checksum, irrespective of the user UDP CS setting. I'd like to float a different idea, namely, putting the UDP user data inside the FRAG option itself. Terminal and non-terminal FRAG options would need to be distinguished in some manner other than the Length field; one way is to allocate different Kind code points, as shown below. +--------+--------+--------+--------+ | Kind=3DX |Len=3D8+k | Frag. Offset | +--------+--------+--------+--------+ | Identification | +--------+--------+--------+--------+ ... ... | User Data | ... ... +--------+--------+--------+--------+ UDP non-terminal FRAG option format +--------+--------+--------+--------+ | Kind=3DY |Len=3D10+k| Frag. Offset | +--------+--------+--------+--------+ | Identification | +--------+--------+--------+--------+ ... ... | User Data | ... ... +--------+--------+--------+--------+ | Checksum | +--------+--------+ UDP terminal FRAG option format The following requirements would apply: >> A host that wishes to signal that it is able to accept and process the FRAG option MAY do so by transmitting an unfragmented datagram with an empty terminal FRAG option with Offset zero and length 12. >> Non-empty FRAG options MUST NOT be present in packets with ordinary UDP user data. Any such options MUST be silently dropped. >> UDP options other than OCS and padding MUST NOT accompany the FRAG option in non-terminal fragments. Any such options MUST be silently dropped. All other options that apply to a reassembled packet must accompany the FRAG header in the terminal fragment. My thinking is that if user UDP CS setting specifies that the UDP checksum should be zero, then OCS would not accompany the FRAG option. Otherwise it would, irrespective of the user OCS setting. It is true there is the potential for excess work when the user UDP CS setting is non-zero, because there are checksums that cover both the individual fragments and the reassembled UDP datagram. However, most of that work can be avoided by a well-designed implementation that caches partial checksums during the reassembly process and sums those to calculate the overall checksum. Alternatively, one could omit the overall checksum in terminal FRAG options. Since there is a looming submission deadline, it may be better to develop this proposal further on the mailing list before putting it into a draft. > also Derek noted: > > > The OCS/CCO case can cover that, except for the LITE (w/o FRAG) case. > > > > For the latter I guess we could also use UDP checksum of zero, and have > > an option to restore a proper checksum for the UDP data at the receiver= , > > however that will still leave legacy receivers experiencing such packet= s > > as unchecksumed. > > > 5. the LITE only case ... > > IMO, we leave this one alone. [... T]here are three points to LITE: > > 1. less work for the transmitter (which your proposal defeats) > 2. less work for the receiver (which your proposal maintains) > 3. deliver potentially corrupted data (one of the original points of > UDP-lite - it wasn=E2=80=99t just about performance) > > These errant middle boxes are also thus defeating #3. > > So, IMO, in the presence of those sorts of things, basically LITE with ou= r > proposal doesn=E2=80=99t do most of what it was intended. I agree with this. My take is that if LITE is to remain in the spec, then i= t should not be covered by OCS. The workaround would defeat its purpose. Mike Heard --0000000000002883570583d40829 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 9 Mar 2019 11:2= 8:57 -0800 Joe Touch wrote:
>
> This one=E2=80=99= s a bit long - we need to converge quickly if the draft is going
= > to be updated in time for the cutoff.
>
> Pl= ease comment asap=E2=80=A6
>
> Joe
>=
> PS =3D =C2=A0yes, we talk about TLV but need to explain tha= t some options are
> exceptions (OCS, NOP, EOL). I also need t= o update the OCS to be 3 bytes
> long (in the table and figure= ). Those are in addition to the issues below.
>
>= -------
>
> Raffaelo and Mike both pointed out:<= /div>
>
> > On Mar 9, 2019, at 5:23 AM, C. M. Heard = <heard@pobox.com> wrote:
=
> > ...
> > the errant middleboxes that CCO is d= esigned to work around do not use the
> > correct length va= lue in their (re)computation of the UDP checksum. ...
>
<= div>> Well, there are several implications here:
>
> 1. we can add in the option length, BUT that also means:
&= gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 (a) we need to declare that the option area= consumes the whole of
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the surpl= us area (no chance for other uses)
> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 OR
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (b) that the surplus area= is always zero
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 OR
>= ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 (c) that OCS covers even the surplus area (it= doesn=E2=80=99t need to be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 zero= ; it does need to be included)
>
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 we need a choice here. AFAICT, the safest (a)

<= /div>
I agree with that.

> 2. we don=E2=80=99t need OCS alignment; what we do need is = to =E2=80=9Ccoordinate=E2=80=9D the
=C2=A0alignment of= a 16-bit of the length to the OCS checksum field
> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 i.e.:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 - calcul= ate the length needed (IPlen - UDP len)
> =C2=A0 =C2=A0 =C2=A0= =C2=A0 - if OCS checksum field is not 16-bit aligned to the start of the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 option area, then swap byt= es
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 - add the result to the OCS c= hecksum (=E2=80=98pseudo header=E2=80=99 seems a bit
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 heavy here, but same point)

I believe that is correct. Padding co= uld still be convenient, though,
and I see no rea= son to disallow it (the current draft does permit
padding for ali= gnment).

> As Derek noted:
>= > As I recall the LITE+FRAG use case has no data in the UDP payload
> > (i.e UDP header length is zero)?
> >
=
> > For this case, there is another way to work around a broken = path (be it
> > boxes, NICs, or whatever), that is simply t= o send with UDP header checksum
> > of zero, and contain an= y necessary checksums in the UDP slack space.
>
>=
> 3. we have to deal with LITE/LITE+FRAG
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 we *can* use UDP CS=3D0, but that also may involve= overriding the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 user=E2=80=99s d= esires here (i.e., the user API says =E2=80=9Cuse UDP CS=E2=80=9D and we=E2= =80=99re
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 not doing that) which m= eans we have a choice:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (d) overr= ide so that things work, i.e., force UDP CS=3D0 and then
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (d.1) do OCS as a chec= k on our stuff only
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 OR
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (d.2) disallow the use of OCS (if CS=3D0, what=E2=80=99s = the point?)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 OR
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (d.3) use OCS=3D0 (this seems like a waste)
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 OR
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (e) igno= re the user setting of CS, then:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.1) always do OCS as a check
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OR
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.2) if UDP CS=3D0= , omit OCS (save space), basically like d.2
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OR
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.3) if UDP CS=3D0, use OCS=3D0 = (basically like e.2
>
> If we do any of the (e) v= ariants, we could either:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (f.1) = require users to disable UDP CS to use OCS
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 OR
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (f.2) ignore the u= ser UDP CS setting
>
> So which is it?
= >
> I don=E2=80=99t like assuming user correct configuratio= n (f.1).
>
> So to me it=E2=80=99s (f.2) and (d.1= ).
>
> Thoughts?

I'm skeptical about this proposal, because it = requires making a for
how OCS is calculated for t= he specific case of LITE+FRAG, and there
are all manner of corner= cases that will make that difficult to draft.
In addition, the U= DP header itself would not be covered by a checksum,
irresp= ective of the user UDP CS setting.

I'd li= ke to float a different idea, namely, putting the UDP user data
i= nside the FRAG option itself. Terminal and non-terminal FRAG options
<= div>would need to be distinguished in some manner other than the Length
field; one way is to allocate different Kind code points, as shown b= elow.

                   +--------+--------+--------+--------+
                   | Kind=3DX |Len=3D8+k |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   ...           =
                    ...
                   |             User Data             |
                   ...=
                               ...
                   +--------+--------+--------+--------+

UDP non-terminal FRAG option = format


                   +--------+--------+--------+--------=
+
                   | Kind=3DY |Len=3D10+k|  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   ...                               ...
                   |             User Data             |
                   ...=
                               ...
                   +--------+--------+--------+--------+
| Checksum | +--------+--------+ UDP terminal FRAG option format

The following requirements would apply:

   >> A host that wishes to signal that it i=
s able to accept and process
   the FRAG option MAY do so by transmitting an unfragmented datagram
   with an empty terminal FRAG option with Offset zero and length 12.
=

>>= ; Non-empty FRAG options MUST NOT be present in packets with ordinary UDP user data. Any such options MUST be silently dropped.

>> UDP options other than OCS and padding MUST NOT = accompany the FRAG option in non-terminal fragments. Any such options MUST be silently dropped. All other options that apply to a reassembled packet must accompany the FRAG header in the terminal fragment.

My th= inking is that if user UDP CS setting specifies that the UDP
checksum should be zero, then OCS would not accompany the FRAG
=
option. Otherwise it would, irrespective of the user OCS setting.

It is true there is the potential for excess work when= the user UDP
CS setting is non-zero, because there are checksums= that cover both
the individual fragments and the reassembled UDP= datagram. However,
most of that work can be avoided by a well-de= signed implementation
that caches partial checksums during the re= assembly process and
sums those to calculate the overall checksum= . Alternatively, one
could omit the overall checksum in terminal = FRAG options.

Since there is a looming submission = deadline, it may be better to
develop this proposal further on th= e mailing list before putting it
into a draft.

> also Derek noted:
>
> > The OCS/CCO case can cover that, except fo= r the LITE (w/o FRAG) case.
> >
> > For the= latter I guess we could also use UDP checksum of zero, and have
= > > an option to restore a proper checksum for the UDP data at the re= ceiver,
> > however that will still leave legacy receivers = experiencing such packets
> > as unchecksumed.
&g= t;
>
> 5. the LITE only case
...
<= div>>
> IMO, we leave this one alone. [... T]here are three= points to LITE:
>
> 1. less work for the transmi= tter (which your proposal defeats)
> 2. less work for the rece= iver (which your proposal maintains)
> 3. deliver potentially = corrupted data (one of the original points of
> UDP-lite - it = wasn=E2=80=99t just about performance)
>
> These = errant middle boxes are also thus defeating #3.
>
&g= t; So, IMO, in the presence of those sorts of things, basically LITE with o= ur
> proposal doesn=E2=80=99t do most of what it was intended.=

I agree with this. My take is that if LITE is to = remain in the spec, then it
should not be covered by OCS. The wor= karound would defeat its purpose.

Mike Heard
=
--0000000000002883570583d40829-- From nobody Mon Mar 11 09:29:13 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A239127962 for ; Mon, 11 Mar 2019 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=bobbriscoe.net 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 v5BM5AYm7skF for ; Mon, 11 Mar 2019 09:29:10 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977A112008A for ; Mon, 11 Mar 2019 09:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ysm9R5ZwAzpA5uFmJjCOkDPu5UrccEWjfx9xa2Mng84=; b=a81XUrs4LL/eWLBN3GxFR7Lsi lsxAj+FGTIelgc236lGJmaGMmJ6P3Y2XBCY5q0ipCbpvgTCwJND5QfAhLrkracnChqdR/dlUlvsTg obBoJrXg+kD4Cq9qaMVkVjIzHZm3FyhISlWAD7EMpcSrr5Bmj99/N4aOX2yK8S04tSAXL3SeYFT2d /bF/dbj8hXTu0FMeaP6c7eRmzOFaLN6gg9X6I4GTot6gDeCdiz7x5GrMS67dwILoS8NdIKEmML64L phzuaE6Vp/Bl7GYwbQEAtV0a5jYPaxuJe6exYsTD3Z/2iWlkfQrbfiN7vuqJYDuprICtihm79ALb6 x2gm4o9ew==; Received: from [31.185.135.153] (port=50070 helo=[192.168.0.9]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h3NnX-0001fo-2s; Mon, 11 Mar 2019 16:29:07 +0000 To: Dave Taht , tsvwg@ietf.org Cc: Jonathan Morton References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> From: Bob Briscoe Message-ID: <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> Date: Mon, 11 Mar 2019 16:29:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <87h8canrc6.fsf@taht.net> Content-Type: multipart/alternative; boundary="------------F674BC627153BF7C6C11CFF2" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:29:13 -0000 This is a multi-part message in MIME format. --------------F674BC627153BF7C6C11CFF2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dave, I'm pasting my comments on this from the bufferbloat list here. I guess discussion on assignment of an IETF codepoint ought to continue here. ======================================================================================= L4S is far from dead. It's merely been working differently from how you're used to. Those working on an L4S AQM (at least those in the cable industry) had to have a private WG for the last ~18 months, but now we're allowed to publish and talk openly again. Similarly, there's work under the covers on an L4S AQM in switch hardware. And I see external signs of work under covers on DSL access equipment (covers that I am not under any longer). Nonetheless, I think you will see updated Linux code for an L4S DualQ Coupled AQM built against the mainline tree appear on netdev list today. ==In summary== The problem that the SCE draft identifies with TCP's sharp multiplicative decrease is also the primary problem that L4S identified. Like L4S, SCE requires changes to network, sender and receiver (see comment later about the rcv-window approach hinted at in the SCE draft). But SCE is just starting on its journey. Having to change end systems and network together is really tough and takes many years. It seems you're trying to do the same thing as L4S, but by slightly different means. Before splitting the people involved in this into two factions, can you say what you didn't like about the L4S approach in the first place? We've been very careful to specify L4S broadly enough so that it can encompass many different approaches within it. The only thing stated against L4S I can find is that it's taking a long time. Starting an identically difficult approach now is going to restart the clock, and take a lot lot longer. ==2 output values vs. 2 input values.== We considered schemes where the AQM can use a second marking as a lower strength /output/ (like VCP, my own QV and now SCE). But we worked out that there were a wider range of advantages and much more significant performance improvements from the sender using a second marking to distinguish how it will behave (i.e. a second /input/ to the classifier in front of the AQM). Don't get me wrong. It's useful that you guys are putting the work in on SCE. Then everyone can compare the two approaches (again), as a check on whether that decision was correct. That's important, cos ECT(1) is the last useful codepoint in the IP header. See: "Notification of Less Severe Congestion than CE" at https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#appendix-C.2 where we've written: Before assigning ECT(1) as an identifer for L4S, we must carefully consider whether it might be better to hold ECT(1) in reserve for future standardisation of rapid flow acceleration, which is an important and enduring problem [RFC6077 ]. ==FQ-only vs. FQ or DualQ== One of the problems with the 2 outputs approach (SCE etc.) is that it is only possible with per-flow queuing. I doubt you'll get the last useful codepoint in the IP header for just that. It's sort-of obvious that, if you try to implement SCE in a FIFO, you can only have one queue length for all the flows. Then legacy TCP flows that don't understand SCE would push the queue deeper to the CE threshold, ruining it for the flows that support SCE. We worked out that the 2 inputs approach (L4S) is more generic - ie. it can be used with FQ or DualQ (multiple or just 2 queues). For instance, you can modify fq_CoDel for senders that uses ECT(1) to indicate that they support a small multiplicative decrease (L4S senders). You only need the following: Include the last bit of the ECN field with the flow ID when you do the classification for sfq. Then in the queues with ECN==X1, you instantiate a shallow threshold ECN AQM. This could be CoDel with a shallow 'target', but you also want it to respond immediately (zero 'interval'), so even a simple step at about 1ms will work, but a random RED-like ramp on the /instantaneous/ queue is much better. ==Re-purposing the Receive Window?=== Receiver congestion control using the receive window may seem like a useful stop-gap, but it runs counter to how nearly all today's transport protocols are intended to work (except, I know of a LEDBAT-like example from Microsoft Research). So you will have your work cut out proving that it is stable and that the two ends don't fight, etc. if you think L4S is taking years, you will find that takes longer. There is current research on this that I can point you to, if you want. That's why we chose an approach that had a pre-existing widely deployed existence proof (DCTCP) to start from. IETF groups like rmcat explicitly decided early on to require the approach where the receiver is a dumb reflector, then new sender congestion control algorithms can be deployed unilaterally. The argument was that the feedback function can be thought of as a sub-layer below the congestion control function. The ongoing addition of accurate ECN feedback to TCP and to QUIC also take the dumb reflector approach. And RTCP already does it that way. ==ECN feedback problems=== Over the last decades, we've made sure that the ECN feedback schemes for TCP, QUIC, RTP (but not SCTP yet) can all feed back ECT(1) as well as CE, in case a scheme like SCE came along. However, the solution in the TCP case [draft-ietf-tcpm-accurate-ecn] is still problematic for SCE if you're impatient. The base scheme overloads 3 bits in the TCP header, which it uses to feed back CE only. To feed back ECT(1) we had to add a TCP option. That's not going to get through middleboxes for many years. The TCP option is also optional to implement. Two of the main TCP developers are currently saying they will probably not implement it, at least not initially. ==Tunnels and lower layers== Over the years I've maintained a fairly lonely activity to make sure that the ECN propagation behaviour of tunnels and layer 2 protocols will treat ECT(1) as either a stronger output signal (as in SCE) or as an alternative input signal to an AQM (as in L4S). Theoretically, this allows either the SCE or the L4S approach. HOWEVER, you would probably not be surprised at how many people read the spec [RFC6040], and say "Ah, no router alters ECT(0) to ECT(1) today, so I'm not going to implement that unnecessary extra line of code in my tunnel decap." ==Wider benefit: Relaxing link ordering== By overloading the ECT(1) marking to mean "the sender uses time for loss detection" a link can relax the reordering requirement on ECT(1) packets today. You can do that with L4S, cos the sender is selecting the marking. You can't do that when the AQM is selecting the marking (as with SCE). If transport protocols detect loss in time units without tying it to any marking (as in RACK on its own), a link cannot use this to relax the ordering requirement until it is sure that all the legacy non-RACK transports have decayed out of the network. That would be measured in decades. HTH Bob On 11/03/2019 01:16, Dave Taht wrote: > I think this gets the procedure right for submittal here. > > internet-drafts@ietf.org writes: > >> A new version of I-D, draft-morton-taht-tsvwg-sce-00.txt >> has been successfully submitted by David M. Täht and posted to the >> IETF repository. >> >> Name: draft-morton-taht-tsvwg-sce >> Revision: 00 >> Title: The Some Congestion Experienced ECN Codepoint >> Document date: 2019-03-10 >> Group: Individual Submission >> Pages: 7 >> URL: https://www.ietf.org/internet-drafts/draft-morton-taht-tsvwg-sce-00.txt >> Status: https://datatracker.ietf.org/doc/draft-morton-taht-tsvwg-sce/ >> Htmlized: https://tools.ietf.org/html/draft-morton-taht-tsvwg-sce-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-morton-taht-tsvwg-sce >> >> >> Abstract: >> This memo reclassifies ECT(1) to be an early notification of >> congestion on ECT(0) marked packets, which can be used by AQM >> algorithms and transports as an earlier signal of congestion than CE. >> It is a simple, transparent, and backward compatible upgrade to >> existing IETF-approved AQMs, RFC3168, and nearly all congestion >> control algorithms. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------F674BC627153BF7C6C11CFF2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dave,

I'm pasting my comments on this from the bufferbloat list here. I guess discussion on assignment of an IETF codepoint ought to continue here.
=======================================================================================

L4S is far from dead. It's merely been working differently from how you're used to. Those working on an L4S AQM (at least those in the cable industry) had to have a private WG for the last ~18 months, but now we're allowed to publish and talk openly again. Similarly, there's work under the covers on an L4S AQM in switch hardware. And I see external signs of work under covers on DSL access equipment (covers that I am not under any longer).

Nonetheless, I think you will see updated Linux code for an L4S DualQ Coupled AQM built against the mainline tree appear on netdev list today.

==In summary==

The problem that the SCE draft identifies with TCP's sharp multiplicative decrease is also the primary problem that L4S identified.

Like L4S, SCE requires changes to network, sender and receiver (see comment later about the rcv-window approach hinted at in the SCE draft). But SCE is just starting on its journey. Having to change end systems and network together is really tough and takes many years.

It seems you're trying to do the same thing as L4S, but by slightly different means. Before splitting the people involved in this into two factions, can you say what you didn't like about the L4S approach in the first place? We've been very careful to specify L4S broadly enough so that it can encompass many different approaches within it.

The only thing stated against L4S I can find is that it's taking a long time. Starting an identically difficult approach now is going to restart the clock, and take a lot lot longer.

==2 output values vs. 2 input values.==

We considered schemes where the AQM can use a second marking as a lower strength /output/ (like VCP, my own QV and now SCE). But we worked out that there were a wider range of advantages and much more significant performance improvements from the sender using a second marking to distinguish how it will behave (i.e. a second /input/ to the classifier in front of the AQM).

Don't get me wrong. It's useful that you guys are putting the work in on SCE. Then everyone can compare the two approaches (again), as a check on whether that decision was correct. That's important, cos ECT(1) is the last useful codepoint in the IP header. See: "Notification of Less Severe Congestion than CE" at https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#appendix-C.2 where we've written:
   Before assigning ECT(1) as an identifer for L4S, we must carefully
   consider whether it might be better to hold ECT(1) in reserve for
   future standardisation of rapid flow acceleration, which is an
   important and enduring problem [RFC6077].

==FQ-only vs. FQ or DualQ==

One of the problems with the 2 outputs approach (SCE etc.) is that it is only possible with per-flow queuing. I doubt you'll get the last useful codepoint in the IP header for just that. It's sort-of obvious that, if you try to implement SCE in a FIFO, you can only have one queue length for all the flows. Then legacy TCP flows that don't understand SCE would push the queue deeper to the CE threshold, ruining it for the flows that support SCE.

We worked out that the 2 inputs approach (L4S) is more generic - ie. it can be used with FQ or DualQ (multiple or just 2 queues).

For instance, you can modify fq_CoDel for senders that uses ECT(1) to indicate that they support a small multiplicative decrease (L4S senders). You only need the following: Include the last bit of the ECN field with the flow ID when you do the classification for sfq. Then in the queues with ECN==X1, you instantiate a shallow threshold ECN AQM. This could be CoDel with a shallow 'target', but you also want it to respond immediately (zero 'interval'), so even a simple step at about 1ms will work, but a random RED-like ramp on the /instantaneous/ queue is much better.

==Re-purposing the Receive Window?===

Receiver congestion control using the receive window may seem like a useful stop-gap, but it runs counter to how nearly all today's transport protocols are intended to work (except, I know of a LEDBAT-like example from Microsoft Research). So you will have your work cut out proving that it is stable and that the two ends don't fight, etc. if you think L4S is taking years, you will find that takes longer. There is current research on this that I can point you to, if you want.

That's why we chose an approach that had a pre-existing widely deployed existence proof (DCTCP) to start from.

IETF groups like rmcat explicitly decided early on to require the approach where the receiver is a dumb reflector, then new sender congestion control algorithms can be deployed unilaterally. The argument was that the feedback function can be thought of as a sub-layer below the congestion control function. The ongoing addition of accurate ECN feedback to TCP and to QUIC also take the dumb reflector approach. And RTCP already does it that way.

==ECN feedback problems===

Over the last decades, we've made sure that the ECN feedback schemes for TCP, QUIC, RTP (but not SCTP yet) can all feed back ECT(1) as well as CE, in case a scheme like SCE came along.

However, the solution in the TCP case [draft-ietf-tcpm-accurate-ecn] is still problematic for SCE if you're impatient. The base scheme overloads 3 bits in the TCP header, which it uses to feed back CE only. To feed back ECT(1) we had to add a TCP option. That's not going to get through middleboxes for many years. The TCP option is also optional to implement. Two of the main TCP developers are currently saying they will probably not implement it, at least not initially.

==Tunnels and lower layers==

Over the years I've maintained a fairly lonely activity to make sure that the ECN propagation behaviour of tunnels and layer 2 protocols will treat ECT(1) as either a stronger output signal (as in SCE) or as an alternative input signal to an AQM (as in L4S). Theoretically, this allows either the SCE or the L4S approach.

HOWEVER, you would probably not be surprised at how many people read the spec [RFC6040], and say "Ah, no router alters ECT(0) to ECT(1) today, so I'm not going to implement that unnecessary extra line of code in my tunnel decap."

==Wider benefit: Relaxing link ordering==

By overloading the ECT(1) marking to mean "the sender uses time for loss detection" a link can relax the reordering requirement on ECT(1) packets today. You can do that with L4S, cos the sender is selecting the marking. You can't do that when the AQM is selecting the marking (as with SCE).

If transport protocols detect loss in time units without tying it to any marking (as in RACK on its own), a link cannot use this to relax the ordering requirement until it is sure that all the legacy non-RACK transports have decayed out of the network. That would be measured in decades.

HTH



Bob



On 11/03/2019 01:16, Dave Taht wrote:
I think this gets the procedure right for submittal here.

internet-drafts@ietf.org writes:

A new version of I-D, draft-morton-taht-tsvwg-sce-00.txt
has been successfully submitted by David M. Täht and posted to the
IETF repository.

Name:		draft-morton-taht-tsvwg-sce
Revision:	00
Title:		The Some Congestion Experienced ECN Codepoint
Document date:	2019-03-10
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-morton-taht-tsvwg-sce-00.txt
Status:         https://datatracker.ietf.org/doc/draft-morton-taht-tsvwg-sce/
Htmlized:       https://tools.ietf.org/html/draft-morton-taht-tsvwg-sce-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-morton-taht-tsvwg-sce


Abstract:
   This memo reclassifies ECT(1) to be an early notification of
   congestion on ECT(0) marked packets, which can be used by AQM
   algorithms and transports as an earlier signal of congestion than CE.
   It is a simple, transparent, and backward compatible upgrade to
   existing IETF-approved AQMs, RFC3168, and nearly all congestion
   control algorithms.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------F674BC627153BF7C6C11CFF2-- From nobody Mon Mar 11 10:16:01 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50DA127962 for ; Mon, 11 Mar 2019 10:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=cablelabs.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 7qHhBTHFpOeF for ; Mon, 11 Mar 2019 10:15:58 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750128.outbound.protection.outlook.com [40.107.75.128]) (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 70882131142 for ; Mon, 11 Mar 2019 10:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=naRB1f4Vy30eNJLUEeDErqiMTV6zt3geYXykRcqsGP4=; b=B4Agx/6clSvg/Ih3ufljINlCj5CWL3B459ka1XEimmINKS+lHhrsSyeEpUe4xeamDY9FaWdgQCRw0Fot7r4K8+Hl1vRpelklY0lLRyt7fp7/dMy4c0ISe5kNKro+xDENQpCXGpiONYvehRDdXcBwXkmY5I3b4i4p7oYMAh/XEQ0= Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4096.namprd06.prod.outlook.com (52.132.124.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Mon, 11 Mar 2019 17:15:54 +0000 Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b%4]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 17:15:54 +0000 From: Greg White To: Bob Briscoe , Dave Taht , "tsvwg@ietf.org" CC: Jonathan Morton Thread-Topic: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt Thread-Index: AQHU16gidytVluJIdkSixRL8FOY/naYGn8cA//+ofYA= Date: Mon, 11 Mar 2019 17:15:54 +0000 Message-ID: <63DC5E45-449A-4008-9041-95A3C7216FF4@cablelabs.com> References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> In-Reply-To: <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com; x-originating-ip: [2620:0:2b10:23:10e1:3bcc:abbe:9072] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e235803f-b444-4653-cd51-08d6a645383b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR06MB4096; x-ms-traffictypediagnostic: SN6PR06MB4096: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: 1; SN6PR06MB4096; 20:+HV8J1aaAa8JE0HIPnJIiW6dUtMedQoZj64fmTgGYYhUskfJGQ96619Zg423NBUSV/RsuDMWacwbt5GN+IPgQhSr5uz5JC9xdskLL4LPnltTOH+GEWl0u81p+EsLIzoBMejc+k0ExSh+QjvRCnDDvtqJnrd7QHvOc9GSSwTC9BM= x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39850400004)(396003)(366004)(376002)(189003)(199004)(6246003)(790700001)(6116002)(2420400007)(15650500001)(97736004)(33656002)(8936002)(8676002)(81156014)(10710500007)(81166006)(4326008)(102836004)(6506007)(58126008)(110136005)(76176011)(5660300002)(99286004)(53546011)(2906002)(106356001)(2501003)(316002)(68736007)(82746002)(36756003)(86362001)(446003)(14454004)(11346002)(46003)(476003)(486006)(966005)(105586002)(14444005)(2616005)(186003)(606006)(25786009)(478600001)(7110500001)(53936002)(7736002)(54896002)(83716004)(6512007)(256004)(71200400001)(71190400001)(6486002)(6436002)(6306002)(236005)(229853002)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4096; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 550VY5bNeX9OohavvQB+6OtHfpfeGKJftn1lo8ohI+Ju5CMhLkqBQKES1JJWo6G8rxPGpRCuPLtutix12wXYMsbheLfvFK1IsW5utSB/7bfUDdoGxTBGPrZEvzde9VhlB6Fuw7f4CSKzPyD4+busOLhH4M8AtGpSIYEaYpm5vI7nUsXc+hNenOGOoIx8q3wRefPXAlSzra1CO2LiL29ZpV1K7mz7h+A77PZw46eKXqR5RLFjY5Bg7M9X+RwFjgNm8R7h1C4TWyBc0k9wcM5va/Ef1pwebZK75QN/xuHOMaj9viHxsTPiN4NWfkTcTZvSGJhXkbAhO4PqPLPBQR9SbsTPp0aE5becbC6evZ/5Yt7WIbeuvAqeNrSync8Vo7csgdmWFUS69ybGA/YGkNolr4lMkTXntxLwZCDdDBTJPqE= Content-Type: multipart/alternative; boundary="_000_63DC5E45449A4008904195A3C7216FF4cablelabscom_" MIME-Version: 1.0 X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: e235803f-b444-4653-cd51-08d6a645383b X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 17:15:54.4150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4096 Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:16:01 -0000 --_000_63DC5E45449A4008904195A3C7216FF4cablelabscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gdGhlIGl0ZW0gYmVsb3csIEkgYW0gaW50ZW5kaW5nIHRvIGZpbmlzaCB1cCBhbmQgc3VibWl0 IGEgVFNWV0cgaW5mb3JtYXRpb25hbCBkcmFmdCB0b2RheSB0aGF0IGRlc2NyaWJlcyB0aGUgKG5l dykgbWFuZGF0b3J5IHN1cHBvcnQgZm9yIEw0UyBBUU0gYW5kIGR1YWwtcXVldWUgcmVxdWlyZW1l bnQgaW4gRE9DU0lTIDMuMSAoQ00gJiBDTVRTKSBlcXVpcG1lbnQuICBUaGUgZHJhZnQgd2lsbCBl c3NlbnRpYWxseSBiZSBhIHJlZm9ybWF0IG9mIHRoaXMgZG9jdW1lbnQ6DQpodHRwczovL2NhYmxl bGEuYnMvbG93LWxhdGVuY3ktZG9jc2lzLXRlY2hub2xvZ3ktb3ZlcnZpZXctZmVicnVhcnktMjAx OQ0KDQpUaGVzZSByZXF1aXJlbWVudHMgd2VyZSBhZGRlZCBpbiBEZWNlbWJlciwgYW5kIHdpbGwg cm9sbCBvdXQgYXMgZmlybXdhcmUgdXBkYXRlcyB0byBleGlzdGluZyBET0NTSVMgMy4xIGVxdWlw bWVudCAobmVhcmx5IDEwMCUgb2YgQ01UU3MsIGFuZCBhIGdyb3dpbmcgZnJhY3Rpb24gb2YgQ01z KSBvdmVyIHRpbWUuDQoNCi1HcmVnDQoNCkZyb206IHRzdndnIDx0c3Z3Zy1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgQm9iIEJyaXNjb2UgPGlldGZAYm9iYnJpc2NvZS5uZXQ+DQpEYXRl OiBNb25kYXksIE1hcmNoIDExLCAyMDE5IGF0IDEwOjI5IEFNDQpUbzogRGF2ZSBUYWh0IDxkYXZl QHRhaHQubmV0PiwgInRzdndnQGlldGYub3JnIiA8dHN2d2dAaWV0Zi5vcmc+DQpDYzogSm9uYXRo YW4gTW9ydG9uIDxjaHJvbWF0aXg5OUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1vcnRvbi10YWh0LXRzdndnLXNjZS0w MC50eHQNCg0KTDRTIGlzIGZhciBmcm9tIGRlYWQuIEl0J3MgbWVyZWx5IGJlZW4gd29ya2luZyBk aWZmZXJlbnRseSBmcm9tIGhvdyB5b3UncmUgdXNlZCB0by4gVGhvc2Ugd29ya2luZyBvbiBhbiBM NFMgQVFNIChhdCBsZWFzdCB0aG9zZSBpbiB0aGUgY2FibGUgaW5kdXN0cnkpIGhhZCB0byBoYXZl IGEgcHJpdmF0ZSBXRyBmb3IgdGhlIGxhc3QgfjE4IG1vbnRocywgYnV0IG5vdyB3ZSdyZSBhbGxv d2VkIHRvIHB1Ymxpc2ggYW5kIHRhbGsgb3Blbmx5IGFnYWluLg0K --_000_63DC5E45449A4008904195A3C7216FF4cablelabscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29u dmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gdGhlIGl0ZW0gYmVsb3csIEkgYW0gaW50ZW5kaW5nIHRvIGZpbmlzaCB1cCBhbmQg c3VibWl0IGEgVFNWV0cgaW5mb3JtYXRpb25hbCBkcmFmdCB0b2RheSB0aGF0IGRlc2NyaWJlcyB0 aGUgKG5ldykgbWFuZGF0b3J5IHN1cHBvcnQgZm9yIEw0UyBBUU0gYW5kIGR1YWwtcXVldWUgcmVx dWlyZW1lbnQgaW4gRE9DU0lTIDMuMSAoQ00gJmFtcDsgQ01UUykgZXF1aXBtZW50LiAmbmJzcDtU aGUgZHJhZnQgd2lsbCBlc3NlbnRpYWxseQ0KIGJlIGEgcmVmb3JtYXQgb2YgdGhpcyBkb2N1bWVu dDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v Y2FibGVsYS5icy9sb3ctbGF0ZW5jeS1kb2NzaXMtdGVjaG5vbG9neS1vdmVydmlldy1mZWJydWFy eS0yMDE5Ij5odHRwczovL2NhYmxlbGEuYnMvbG93LWxhdGVuY3ktZG9jc2lzLXRlY2hub2xvZ3kt b3ZlcnZpZXctZmVicnVhcnktMjAxOTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2Ug cmVxdWlyZW1lbnRzIHdlcmUgYWRkZWQgaW4gRGVjZW1iZXIsIGFuZCB3aWxsIHJvbGwgb3V0IGFz IGZpcm13YXJlIHVwZGF0ZXMgdG8gZXhpc3RpbmcgRE9DU0lTIDMuMSBlcXVpcG1lbnQgKG5lYXJs eSAxMDAlIG9mIENNVFNzLCBhbmQgYSBncm93aW5nIGZyYWN0aW9uIG9mIENNcykgb3ZlciB0aW1l LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tR3JlZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj50c3Z3ZyAmbHQ7dHN2 d2ctYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEJvYiBCcmlzY29lICZsdDtpZXRm QGJvYmJyaXNjb2UubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE1hcmNoIDExLCAy MDE5IGF0IDEwOjI5IEFNPGJyPg0KPGI+VG86IDwvYj5EYXZlIFRhaHQgJmx0O2RhdmVAdGFodC5u ZXQmZ3Q7LCAmcXVvdDt0c3Z3Z0BpZXRmLm9yZyZxdW90OyAmbHQ7dHN2d2dAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj5Kb25hdGhhbiBNb3J0b24gJmx0O2Nocm9tYXRpeDk5QGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFt0c3Z3Z10gTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1tb3J0b24tdGFodC10c3Z3Zy1zY2UtMDAudHh0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtj b2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5MNFMgaXMgZmFyIGZyb20gZGVhZC4gSXQncyBt ZXJlbHkgYmVlbiB3b3JraW5nIGRpZmZlcmVudGx5IGZyb20gaG93IHlvdSdyZSB1c2VkIHRvLiBU aG9zZSB3b3JraW5nIG9uIGFuIEw0UyBBUU0gKGF0DQogbGVhc3QgdGhvc2UgaW4gdGhlIGNhYmxl IGluZHVzdHJ5KSBoYWQgdG8gaGF2ZSBhIHByaXZhdGUgV0cgZm9yIHRoZSBsYXN0IH4xOCBtb250 aHMsIGJ1dCBub3cgd2UncmUgYWxsb3dlZCB0byBwdWJsaXNoIGFuZCB0YWxrIG9wZW5seSBhZ2Fp bi48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_63DC5E45449A4008904195A3C7216FF4cablelabscom_-- From nobody Mon Mar 11 12:27:16 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1D11310EE for ; Mon, 11 Mar 2019 12:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbDPfaCZdL0Z for ; Mon, 11 Mar 2019 12:27:12 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id C10A91310AB for ; Mon, 11 Mar 2019 12:27:12 -0700 (PDT) Received: from erg.abdn.ac.uk (at-www-1.erg.abdn.ac.uk [IPv6:2001:630:42:150::5]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 28CDA1B001CB; Mon, 11 Mar 2019 19:27:08 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 11 Mar 2019 19:27:08 +0000 From: Raffaele Zullo To: "C. M. Heard" Cc: Joe Touch , tsvwg In-Reply-To: References: <136FF703-4DFE-4B32-A722-67122F28C894@strayalpha.com> Message-ID: <32fee79db0d64dd078e3025a8a5c89ff@erg.abdn.ac.uk> X-Sender: raffaele@erg.abdn.ac.uk User-Agent: Roundcube Webmail/1.2.3 Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 19:27:14 -0000 Hello, On 2019-03-11 16:26, C. M. Heard wrote: > On Sat, 9 Mar 2019 11:28:57 -0800 Joe Touch wrote: >> Well, there are several implications here: >> >> 1. we can add in the option length, BUT that also means: >> (a) we need to declare that the option area consumes the > whole of >> the surplus area (no chance for other uses) >> OR >> (b) that the surplus area is always zero >> OR >> (c) that OCS covers even the surplus area (it doesn’t need > to be >> zero; it does need to be included) >> >> we need a choice here. AFAICT, the safest (a) > > I agree with that. I would add that a Zero padding after UDP Options area is not neutral to the (full IP payload) checksum because it still increases the IP Total Length (it changes the "pseudo-header"). >> 2. we don’t need OCS alignment; what we do need is to > “coordinate” the > > alignment of a 16-bit of the length to the OCS checksum field >> i.e.: >> - calculate the length needed (IPlen - UDP len) >> - if OCS checksum field is not 16-bit aligned to the start > of the >> option area, then swap bytes >> - add the result to the OCS checksum (‘pseudo header’ > seems a bit >> heavy here, but same point) > > I believe that is correct. Padding could still be convenient, though, > > and I see no reason to disallow it (the current draft does permit > padding for alignment). > Would it be possible to leave this as a choice? CCO draft, despite on sender's side required alignemnt, on receiver's side only required that the complement of the sum of Options and pseudoheader was zero, in order to accept also a working CCO computed without alignment. Thank you, Raffaele Zullo From nobody Mon Mar 11 12:31:58 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE1B1310D7 for ; Mon, 11 Mar 2019 12:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZNN564eLU_HN for ; Mon, 11 Mar 2019 12:31:54 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 98D27130F81 for ; Mon, 11 Mar 2019 12:31:54 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id l139so516034ita.5 for ; Mon, 11 Mar 2019 12:31:54 -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:content-transfer-encoding; bh=7A87lf+sYYDJCA5O6GMH5A8ZL0N214DGYry3aS91KpQ=; b=NCn+z7kn0LePpYQqjaNNKguGEa0fHlcLY5XP1JlTysw4VSdFt+Fr07gGrCjbGVwyik 2Xt2/YOnf15T4ibFCm1fm4tQVv+/8MQfXOMXMSXVoYNxKGceX4h9LE3qrVeK3cDNSNN+ bamLMPNhNHejBPAMomvMo+0EEFNDuAFGXQFbmGXvMrkIFUPWvl7/kNugIQGWGzYe7yFq Cxp815Y78Zc489zsUxRbMP7sio3EW4oGgZ350YHlWn+cP7S/XlbiMPkVvjm+rCzAMI/R PHxLI6+e2C/lZknio7a5VMkhknvO0bBGW9Yby/YgemVKOzo6wiviEACmWj/Bq66vbXzq FEfw== 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:content-transfer-encoding; bh=7A87lf+sYYDJCA5O6GMH5A8ZL0N214DGYry3aS91KpQ=; b=qu8zP4yDL9Xgu0y1vnvwbYSrOmF/ZKi/NEDtazHTvcVqOAgCstZb/XcPYDcG+EZrsu pJluQ3WZEtR7QIAXK6R6EybLW0/CgVFP3wy2PZom3DuEcuyMcH2AQw5WgdchGzG51z5Q paEzvEj1kiUUuoKfsXR+qbFoJMZDTrqhAuYLk0pl8sCyVbJa6NNtFiw7LRmcoK3RT9h0 YK6NFwpuOnXcs+dixhgKkM8XM8WYypxu9wjhtXUAUlPYc6QKebIoBb+/6VzjCTVUBf8W HlgdteH+ZCpkPV7KqoLB+wPPOrGE4Zf4f8h31OHkF82JuKQIXZwWYr86rcG69/AJDL8g F1OQ== X-Gm-Message-State: APjAAAVj+nwhE9+YLlPhAW+1FRkHPX7f07P9cHPWn2l6YrYrJzhQLUQI cMVawjfgivI6tvkw+zzFGoUzbeHVwZIEqFIfxcA= X-Google-Smtp-Source: APXvYqxzrcGFuhhTHBMuVxWGwXHn3bJXPUZefeAdPY4IoZWcdWDcSc3g197szHWSm3NrRi2ixl4j/VLGq4p1v4KHazk= X-Received: by 2002:a24:2546:: with SMTP id g67mr245735itg.18.1552332713968; Mon, 11 Mar 2019 12:31:53 -0700 (PDT) MIME-Version: 1.0 References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> In-Reply-To: <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> From: Loganaden Velvindron Date: Mon, 11 Mar 2019 23:31:42 +0400 Message-ID: To: Bob Briscoe Cc: Dave Taht , tsvwg@ietf.org, Jonathan Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 19:31:57 -0000 On Mon, Mar 11, 2019 at 8:29 PM Bob Briscoe wrote: > > Dave, > > I'm pasting my comments on this from the bufferbloat list here. I guess d= iscussion on assignment of an IETF codepoint ought to continue here. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > L4S is far from dead. It's merely been working differently from how you'r= e used to. Those working on an L4S AQM (at least those in the cable industr= y) had to have a private WG for the last ~18 months, but now we're allowed = to publish and talk openly again. Similarly, there's work under the covers = on an L4S AQM in switch hardware. And I see external signs of work under co= vers on DSL access equipment (covers that I am not under any longer). > > Nonetheless, I think you will see updated Linux code for an L4S DualQ Cou= pled AQM built against the mainline tree appear on netdev list today. > > =3D=3DIn summary=3D=3D > > The problem that the SCE draft identifies with TCP's sharp multiplicative= decrease is also the primary problem that L4S identified. > Hence why I think it's important to do research on both and see how they fare when used by early adopters on routers at home :-) From nobody Mon Mar 11 12:56:25 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF70E130F5C for ; Mon, 11 Mar 2019 12:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 U9GzBaBYldQR for ; Mon, 11 Mar 2019 12:56:22 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 0F501130EBE for ; Mon, 11 Mar 2019 12:56:21 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id x20so6309qto.1 for ; Mon, 11 Mar 2019 12:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=DmUHV/37/kgLFlPvxk3O1k6nduFoZZ3peFC3SeN4VX0=; b=Molwm3iVQYQR+KH5xbPWGbdMamqjyd/T0qHC7TxxCfKUT0uO5kF/cO6oHbgn28gtS9 YlDAy7dKTLx6Q/AL0NGlqiVgE8ODmtEe55GbLCunfgboC1O3N1KEOFEULVwkJktWp+CW 6NDcxiRCC6RAQO6Y2Lg1SDaFTtfaXUWr5icTCfQeM+tNlDIsIawhiMnDydiNbXs33hM4 W5wInuXXC5+/TKWTpKLlH/T/k+rn1cUjUBRPkKnhf0G+XyQJKRVGGsb1tf+9zTNHucuP +CVttsHigUaxa+tyZEkXeuWTTpqCdHtozZAuAP6l8vm7xf3d2BsOV9MVMwSKXxcnpphK FIsg== 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=DmUHV/37/kgLFlPvxk3O1k6nduFoZZ3peFC3SeN4VX0=; b=V4hhy53oIvKkhAmSDYIJBX3M8RDLiJdRbpNo8sUQfFBVnKl1YNbSvLTg6WNjAhUU/E 0KJQRfgs5gv+vVED/p9QPb0vMrIV4KXBUthIJKx9Vz+prf+T2g1nCh8JKdjnkKEWgAEQ vaKdZlA9PU6LPMF9d1iGI1b8bt6aro0Yq5DiLy7jMnXobfz/0MhY0iS1t/RRBf7i2Hy2 DrLYKFaMSba/QzCy0xBhpzVhCFTZmrNYlyRhEmZztVnzzVBVO9njG88Np7CRNbncQcXo wq6Q0O9qt30yvHFMX54oirJquByf7UtQbU5PH40+t1Gzv+ij6Lr0+8ANLqnBMn2YBhV2 kuoA== X-Gm-Message-State: APjAAAW+B9ML8UiDowlEKed48kLJ6fT0dB5mlskpoakBZmiBPA1D3JO5 2RXQ6nv13VbfZt5G2dyE1Uc75ZliZXQSpY1EuHzB/aVWz6g= X-Google-Smtp-Source: APXvYqyOycua419vjvzRXEn9y+97OrHXSzcPVxtRv3sbcEow3+Tw2m7xgoS3RyG72SstSB6OT0J0fZGZxKqwLyR06Go= X-Received: by 2002:ac8:22d6:: with SMTP id g22mr25900905qta.97.1552334180537; Mon, 11 Mar 2019 12:56:20 -0700 (PDT) MIME-Version: 1.0 From: Tom Herbert Date: Mon, 11 Mar 2019 12:56:09 -0700 Message-ID: To: tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 19:56:24 -0000 >From the draft: "Legacy receivers interpret these as zero-length payload packets (i.e., UDP Length field is 8, the length of just the UDP header), which would not affect the receiver unless the presence of the packet itself were a signal." This is an improvement over previous drafts in that the problem is at least acknowledged, but it provides no guidance on resolving the issue. The protocol as described may break legacy applications. It seems like there should be a lot more words around this. If the problem can't be eliminated in the protocol, then at least it should be mentioned in usage guidelines. >From the draft: "The primary purpose of OCS is to detect non-standard (i.e., non-option) uses of the options area". Given that the checksum is optional, I don't see how this works to detect non-standard use of the checksum area. For instance, if some random garbage bytes are in the option area then the only way the non-standard use is detected is if by chance the type for OCS happens to appear in the data and is parsed as being an OCS option. Of course that's exceedingly unlikely to happen, so garbage data is likely to be proessed as options. As I mentioned previously, UDP options space should start with a fixed size header that includes a two byte checksum. This will eliminate any ambiguity and solves other problems (like the corrupted OCS type field problem), Tom From nobody Mon Mar 11 13:18:02 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10588126CAD for ; Mon, 11 Mar 2019 13:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=bobbriscoe.net 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 7mt5uBRa8SaL for ; Mon, 11 Mar 2019 13:17:58 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC0B1200D8 for ; Mon, 11 Mar 2019 13:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=L7RJv85b9U9wFGHMpo4zEpJxdL6RyYmUpCNcZOL2irM=; b=ynXSNDarTsHmV1ZwvDx+fB+1gx K2AKdP0Uz2p3Gm0644Xpy2JmhYsY4barf/HSHI9C+SdA/zmnmlrSd11eau02IlvCQgH2YJY5oV4Xi IW9dTsphvYdSYVQiSgbURdDnSUaPb1us8Q5/lqyJNIDtUTTAWyti3Cfd+Y5FLpQZ6nWag6LU/+u4G OxNIc08I1Ht5C87tLBmC9jBagej9WoQPzgBbIE2aE+aybqWW8uaV8NL6Ih779UHzKCEYe1mxkV6zE Yqhn6evMrWZcn0ZXPJopj4FBeYmETuGbb13dNIUAtZMZAWhziZLIKdeGrX/0zyqDOcaSRLzisM+BJ /MzuheSg==; Received: from [31.185.135.153] (port=51946 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h3RMy-00043o-4Y; Mon, 11 Mar 2019 20:17:56 +0000 To: Dave Taht Cc: David Pullen , tsvwg@ietf.org References: <87muouco0q.fsf@taht.net> From: Bob Briscoe Message-ID: Date: Mon, 11 Mar 2019 20:17:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <87muouco0q.fsf@taht.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] Technical review 5 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 20:18:01 -0000 Dave, While looking for your name, I found your posting from Xmas Day, that I never replied to - sorry. The main thing I think you've missed is that the WRR scheduler between the two queues doesn't actually do anything in all normal circumstances. The DualQ actually even works with a strict priority scheduler because of this. The scheduling is done by the senders, just as if the 2 queues were a single FIFO. That's not obvious so let me explain... When there's traffic in the Classic queue, the ECN marking in the L4S queue coupled over from the Classic AQM, causes the L4S sender to leave enough space between it's packets for the classic queue. When Koen first suggested this, I didn't think it would work, but it works amazingly accurately. The only reason for using WRR instead of strict priority is to give the Classic queue a chance, in case of an unresponsive sender in the L queue. It's good to keep the weight high (we recommend 15/16) so L4S packets get served quickly. Not using strict priority also ensures that an initial DNS or SYN packet in the Classic queue is released quickly if there's a continuous flow going in the L4S queue. In the Linux implementation, we also provide a scheduler called time-shifted FIFO, but we recommend WRR (particularly in the DOCSIS case, cos TS-FIFO needs packet time-stamping, which existing cable modem hardware doesn't support). TS-FIFO just takes the packet that arrived first, but for one queue it first subtracts from the arrival time by a pre-configured amount (e.g. 30ms) to prioritize it. Bob On 25/12/2018 02:56, Dave Taht wrote: > Bob Briscoe writes: > >> David, >> >> OK, you're right that we don't do a good job of justifying this, other >> than hinting that WRR is already well-known. >> >> I've recorded much more of the thinking behind this choice. I've also >> explained why the choice of WRR scheduler weight is not important, as >> follows (additions in green): >> >> o A well-understood weighted scheduler such as weighted round robin >> (WRR) is recommended. The scheduler weight for Classic should be >> low, e.g. 1/16. Note that the coupled congestion signal typically >> make L4S sources leave roughly equal per-flow capacity available >> for classic flows. So, if the weight is small, its exact value is >> unimportant because it does not normally determine capacity >> shares. The weight is only important to prevent unresponsive L4S >> traffic starving classic traffic. > I note that the "fq" portion of fq_codel (RFC8290) has better min/max properties > than straight drr, as does qfq. > > I am saddened that there is seemingly no fq or aqm component intended for > "classic" flows in this design, as if it didn't need it. > > The first deployment of fq_codel (free.fr's) had the following weighted > queue structure: > > drr 1 priority fq_codel (diffserv markings) > drr 2 best effort fq_codel > drr 3 background fq_codel > > and nearly the entire qos related deployment of this has essentially the > same structure, including sch_cake. > > In deprioritizing "classic" to 1/16 the total possible flow volume, any > form of weighted fair queuing can be used, but I still don't know why > you wish to punish classic flows so much by eliding aqm and fq on those. > > > >> o Alternatively, a time-shifted FIFO (TS-FIFO) could be used. It >> works by selecting the head packet that has waited the longest, >> biased against the Classic traffic by a time-shift of tshift. To >> implement time-shifted FIFO, the "if (scheduler() == lq )" test in >> line 3 of the dequeue code would simply be replaced by "if ( >> lq.time() + tshift >= cq.time() )". For the public Internet a >> good value for tshift is 50ms. For private networks with smaller >> diameter, about 4*target would be reasonable. TS-FIFO is a very >> simple scheduler, but complexity might need to be added to address >> some deficiencies (which is why it is not recommended over WRR): >> >> * TS-FIFO does not fully isolate latency in the L4S queue from >> uncontrolled bursts in the Classic queue; >> >> * TS-FIFO is only appropriate if time-stamping of packets is >> feasible; >> >> * Even if time-stamping is supported, the sojourn time of the >> head packet is always stale. For instance, if a burst arrives >> at an empty queue, the sojourn time will only measure the delay >> of the burst once the burst is over, even though the queue knew >> about it from the start. At the cost of more operations and >> more storage, a 'scaled sojourn time' metric of queue delay can >> be used, which is the sojourn time of a packet scaled by the >> ratio of the queue sizes when the packet departed and arrived. >> >> Bob >> >> On 18/12/2018 19:53, David Pullen wrote: >> >> Hi Bob, >> >> >> At the end of Appendix A, WRR is recommended over time-shifted >> FIFO, but no real justification is given. Why is WRR recommended? >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> - Dave >> >> >> David Pullen Distinguished Engineer | Wired Networking, Cable >> Modems Broadcom office: 678.475.3143 | mobile: 678.477.4108 | fax: >> 770.232.0211 4385 River Green Parkway | Duluth, GA 30096 >> david.pullen@broadcom.com | broadcom.com -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Mar 11 13:28:28 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6F2127961 for ; Mon, 11 Mar 2019 13:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.299 X-Spam-Level: ** X-Spam-Status: No, score=2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 wRdCwiOYDV2s for ; Mon, 11 Mar 2019 13:28:26 -0700 (PDT) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4559112787F for ; Mon, 11 Mar 2019 13:28:26 -0700 (PDT) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 2F2901344A5 for ; Mon, 11 Mar 2019 16:28:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=QxByFDmerD+n tGxFyZ4eUM8RmsU=; b=o9hRGalsd3O4enrq8qXWqsc8uZjk0MklDMO2C3Eqdplh /kqHwOviUwxDfwe3WbcIg3xivtpDiKYZvtCKYKBSPBJzoVCS1pnvfzx4vYcKpRLP ciHgZFAG/EAP7LV/gJAliGuF2Z59eLe3PFZqdMdNlfiq5pLEfVoN+aFT3xodmcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=CzMbL/ EINafkTU2+VPGKZKAgPMYoJZ75kWUl3gPnNCH1PFs3IpBZectRGg20LSPstkypMN Ewmj6CpoVBRgHlXvpYtLUqYVRHLt/l3iTxhwTDJwsMbNxcyOFuyWssuCSX1Gu57Y iEdZS2Zxgr/GX3tejPBz/u6636AokAYKFE1QU= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 2742C1344A4 for ; Mon, 11 Mar 2019 16:28:25 -0400 (EDT) Received: from mail-it1-f169.google.com (unknown [209.85.166.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 9AAF11344A1 for ; Mon, 11 Mar 2019 16:28:24 -0400 (EDT) Received: by mail-it1-f169.google.com with SMTP id k193so817348ita.3 for ; Mon, 11 Mar 2019 13:28:24 -0700 (PDT) X-Gm-Message-State: APjAAAXnOOtimb5NNnJlz6/W/GD9O2KDjw2hcCrky+rZsf3U3KYjRUgj PwyIgKB69KcaPfAdJHlqRVqsqp61/l/PsZ+pxz8= X-Google-Smtp-Source: APXvYqx55cCw/o+enwXZ985tGpLJboAihjYlwWiX+iiMJ72M8p9SCfhvgvFpI6BpzSGHuBDweI6KuEO2RXDwQBZMLeA= X-Received: by 2002:a24:101:: with SMTP id 1mr53338itk.138.1552336104054; Mon, 11 Mar 2019 13:28:24 -0700 (PDT) MIME-Version: 1.0 References: <136FF703-4DFE-4B32-A722-67122F28C894@strayalpha.com> <32fee79db0d64dd078e3025a8a5c89ff@erg.abdn.ac.uk> In-Reply-To: <32fee79db0d64dd078e3025a8a5c89ff@erg.abdn.ac.uk> From: "C. M. Heard" Date: Mon, 11 Mar 2019 13:28:12 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Raffaele Zullo Cc: Joe Touch , tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 3867E794-443C-11E9-8CC0-DF19F34BB12D-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 20:28:27 -0000 On Mon, 11 Mar 2019 19:27:08 +0000 PM Raffaele Zullo wrote: > On 2019-03-11 16:26, C. M. Heard wrote: > > On Sat, 9 Mar 2019 11:28:57 -0800 Joe Touch wrote: > >> Well, there are several implications here: > >> > >> 1. we can add in the option length, BUT that also means: > >> (a) we need to declare that the option area consumes the > > whole of > >> the surplus area (no chance for other uses) > >> OR > >> (b) that the surplus area is always zero > >> OR > >> (c) that OCS covers even the surplus area (it doesn=E2=80=99t = need > > to be > >> zero; it does need to be included) > >> > >> we need a choice here. AFAICT, the safest (a) > > > > I agree with that. > > > I would add that a Zero padding after UDP Options area is not neutral to > the (full IP payload) checksum because it still increases the IP Total > Length (it changes the "pseudo-header"). Good point; that one seems to keep escaping me :-( > >> 2. we don=E2=80=99t need OCS alignment; what we do need is to > > =E2=80=9Ccoordinate=E2=80=9D the > > > > alignment of a 16-bit of the length to the OCS checksum field > >> i.e.: > >> - calculate the length needed (IPlen - UDP len) > >> - if OCS checksum field is not 16-bit aligned to the start > > of the > >> option area, then swap bytes > >> - add the result to the OCS checksum (=E2=80=98pseudo header= =E2=80=99 > > seems a bit > >> heavy here, but same point) > > > > I believe that is correct. Padding could still be convenient, though, > > and I see no reason to disallow it (the current draft does permit > > padding for alignment). > > > > Would it be possible to leave this as a choice? > CCO draft, despite on sender's side required alignemnt, > on receiver's side only required that the complement of the sum of > Options and pseudoheader was zero, > in order to accept also a working CCO computed without alignment. +1 Mike Heard From nobody Mon Mar 11 14:20:58 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8681311E9; Mon, 11 Mar 2019 14:20:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <155233924986.23114.4098801711697398638@ietfa.amsl.com> Date: Mon, 11 Mar 2019 14:20:49 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc4960-bis-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:20:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Stream Control Transmission Protocol Authors : Randall R. Stewart Michael Tuexen Karen E. E. Nielsen Filename : draft-ietf-tsvwg-rfc4960-bis-01.txt Pages : 144 Date : 2019-03-11 Abstract: This document obsoletes RFC 4960, if approved. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: o acknowledged error-free non-duplicated transfer of user data, o data fragmentation to conform to discovered path MTU size, o sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, o optional bundling of multiple user messages into a single SCTP packet, and o network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc4960-bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc4960-bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 15:18:47 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D021279B1 for ; Mon, 11 Mar 2019 15:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXkMv-Pk4A-1 for ; Mon, 11 Mar 2019 15:18:43 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93F01311B9 for ; Mon, 11 Mar 2019 15:18:39 -0700 (PDT) Received: by bugle.employees.org (Postfix, from userid 1736) id B0158FECC01D; Mon, 11 Mar 2019 22:18:39 +0000 (UTC) Date: Mon, 11 Mar 2019 23:18:39 +0100 From: Derek Fawcus To: tsvwg Message-ID: <20190311221839.GA92478@bugle.employees.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 22:18:47 -0000 On Sat, Mar 09, 2019 at 11:28:57AM -0800, Joe Touch wrote: > This one’s a bit long - we need to converge quickly if the draft is going to be updated in time for the cutoff. > > Please comment asap… Sorry - I've been otherwise occupied; and hence this isn't a complete response... > 1. we can add in the option length, BUT that also means: > (a) we need to declare that the option area consumes the whole of the surplus area (no chance for other uses) > OR > (b) that the surplus area is always zero > OR > (c) that OCS covers even the surplus area (it doesn’t need to be zero; it does need to be included) > > we need a choice here. AFAICT, the safest (a) I agree on (a); but then I was never convinced on the possibily of other users, as future users would still need to be able to parse these options, in which case why would they not use them? The only use I could see for leaving surplus for non option use would be in the case of there being an option indicating 'the rest of the surplus is X', for some X. So really what we lose is the ability to have an option of more than 255 bytes. > 3. we have to deal with LITE/LITE+FRAG > we *can* use UDP CS=0, but that also may involve overriding the user’s desires here (i.e., the user API says “use UDP CS” and we’re not doing that) > which means we have a choice: > (d) override so that things work, i.e., force UDP CS=0 and then > (d.1) do OCS as a check on our stuff only > OR > (d.2) disallow the use of OCS (if CS=0, what’s the point?) > OR > (d.3) use OCS=0 (this seems like a waste) > OR > (e) ignore the user setting of CS, then: > (e.1) always do OCS as a check > OR > (e.2) if UDP CS=0, omit OCS (save space), basically like d.2 > OR > (e.3) if UDP CS=0, use OCS=0 (basically like e.2 > > If we do any of the (e) variants, we could either: > (f.1) require users to disable UDP CS to use OCS > OR > (f.2) ignore the user UDP CS setting > > So which is it? > > I don’t like assuming user correct configuration (f.1). > > So to me it’s (f.2) and (d.1). I'd split LITE w/o FRAG from LITE with FRAG. The latter would not involce overriding the users choice of there being no CS, as there is no UDP data as such. The only thing we'd lose is a check on the pseudo-header, so maybe encode that somewhere in the LITE+FRAG combo, dare I say as another option? So for LITE+FRAG, I'd agree (f.2) and (d.1) [As an aside, the only guarenteed way I've found to send w/o UDP checksum using the sockets API is by using RAW sockets.] > 5. the LITE only case > > The whole point of LITE is that some of the IP payload isn’t checksummed. > > > Given that we're supposed to veryify such receivers can accept > > LITE (w/o FRAG) and hold soft state, maybe this is acceptable? > > > We don’t have a requirement that such receivers can accept LITE before we start using it, so soft state won’t help here. > > > we can send > > LITE (w/o FRAG) using UDP checksum of zero, and the additional > > option encoding the actual checksum for the UDP data. > > > > This additional checksum could simply be the existing defined > > ACS option. > > ACS uses a CRC, not IP checksum. That’s a LOT more work in software, so this isn’t a viable alternative. Actually, my original thought here (which I then culled), was to have another option, or ACS. That other option would encode the current style of checksum, so for concerns about CPU cost of using CRC, we could mitigate it. What I had in mind was an option containing two 16 bit fields, one would encode the partial-checksum for the pseudo-header as the originator sent it, the other the partial-checksum for the original UDP payload. e.g.: [ Type = Frag-Chks | Len | part-phdr-chk | part-data-chk ] That way the receiver can recover from any NAT mangling of the packet which would otherwise mess with the checksum calculation. i.e. for the UDP portion, assuming the packet was encoded with UDP CS=0 1. Calculate partial checksum for pseudo-header as received 2. Compare to option part-phdr-chk 2a. If equal verify UDP data against part-data-chk 2b. If differ verify UDP data against part-data-chk + (part-phdr-chk - phdr-chk) The implementation of that can probably be optimised. > IMO, we leave this one alone. The whole point of LITE is to do less work - if that means the LITE data corrupts the entire packet, then so be it. Then LITE basically fails. However, I do agree that the LITE w/o FRAG case (incl. when using the proposed UDP CS=0 encoding) needs more consideration, and so am happy to leave that to a later revision of the draft. Especially as it would be good to avoid having the OCS/CCO option encoding the LITE data, but I'm not sure how we achieve that. Maybe this is one of the cases where we simply have to accept it will not pass through broken middle devices? Which would be a pity, but it may still pass through more than UDP-Lite does. i.e. maybe LITE w/o FRAG would simply have to be like in the current draft, and using no clever encoding tricks for CCO discovered problems? We already have the case that we won't pass through broken devices which drop packets where there is any slack space. DF From nobody Mon Mar 11 15:56:14 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6967913122A for ; Mon, 11 Mar 2019 15:56:01 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 lXSW0IjCyPZ1 for ; Mon, 11 Mar 2019 15:55:58 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 2C175131258 for ; Mon, 11 Mar 2019 15:55:57 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id t28so512475qte.6 for ; Mon, 11 Mar 2019 15:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FdZM3p51xiOM6izji+7zbkhzDqahNi3D6KpKqqG/1wI=; b=1NENW6OKnSsV+QjHWcBl+1hHmLdonZ7GP5Ebbz+BQ7yDOw/TZd2LNTj8MAP98DMQwG E3twTCJ6fN0lPWSRTLYCvAk29ku2gl53s3qfKNy7P8lByP0Sfp1W61bu8nTPY73hjZG6 2KinzvlGkbuKzJdkQcAVKJQwi73GeUShphDeXN01E4biTdTR/b3BjCrRfMQAGGVTO/A9 0t5ZPT3/WSw6g+da4MkxtrNXV6ZSuXYZGBOPFJFcRdE39picS++/Rfb5mWQgjvlOlUEi xAjK+QMB/gl/MRM5ffPcAk5bEOQtA/Lmnr7t/H8l3Zbl8EJuqGAT0gZEcb6LC2W5FEJm gUTQ== 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; bh=FdZM3p51xiOM6izji+7zbkhzDqahNi3D6KpKqqG/1wI=; b=J1pqeqX89I8If4824Kx5+Z3e5fpfamCZIVviaF0y2e7xH7g8VmSA1k8fY5J/zckrkw 4VIck42WYXnl5WPG7MzeqESD2Wlrr6kbnJgzyLGTnakFEEo+1DweuZIeq833JC3w+SVg r/+Gxh14X+acjlxarR0iFNxVJCVbFcSS1XDE8I2LRmwkTvsvS26bXHJOjeX9waUtzGcD +Lc2PLFNTaKzFG6nD7BO1vQkWiZ2yMCgpNgE8ajr5qRM91SkEImKJYfLBmacvIPLBrGG s5+WT/Axk2YYpssxxSBwDn5AVNvD0wc+1HKh4E2agdUBjLVQ8kK7BhWvxii9qjWvzjGC XJOQ== X-Gm-Message-State: APjAAAUwbI6YM2Nnj3n4HXFu9+UBuP5YfRz2AOx69MEwyrm//3rMtZNh Q7zQENd/GIoML2ZzqMXn1Osq4YKBt6JbnOcWYx1mA3te X-Google-Smtp-Source: APXvYqzrhanRUBY0hVmwACxRSe4f04cgvA1oRw0mEwHWwjn58jzFlRMqk6kbEG4WHWjHKEhBC27oIUwVDingIhCK33g= X-Received: by 2002:a0c:9681:: with SMTP id a1mr28265484qvd.72.1552344956002; Mon, 11 Mar 2019 15:55:56 -0700 (PDT) MIME-Version: 1.0 References: <155234457516.23066.2902218433537151460.idtracker@ietfa.amsl.com> In-Reply-To: From: Tom Herbert Date: Mon, 11 Mar 2019 15:55:44 -0700 Message-ID: To: tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 22:56:08 -0000 Hello, I've posted a draft that describe a common header to use in UDP surplus space (the bytes between the end of UDP payload and the end of the IP packet). The header allows disambiguation between uses of the UDP slack space, including possible non-standard uses via a required checksum. The header includes a type field to allow different uses of the surplus space. UDP options would be one use case, but the format is extensible to allow other uses. Tom ---------- Forwarded message --------- From: Date: Mon, Mar 11, 2019 at 3:49 PM Subject: New Version Notification for draft-herbert-udp-space-hdr-00.txt To: Tom Herbert A new version of I-D, draft-herbert-udp-space-hdr-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-udp-space-hdr Revision: 00 Title: UDP Surplus Space Header Document date: 2019-03-11 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-herbert-udp-space-hdr-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-udp-space-hdr/ Htmlized: https://tools.ietf.org/html/draft-herbert-udp-space-hdr-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-udp-space-hdr Abstract: This draft defines a header for surplus space in UDP. The UDP surplus space is bytes between the end of the UDP payload and the end of the IP packet. The purpose of the header is to disambiguate uses of the surplus space. The UDP surplus space header includes a type, length, and checksum field that covers the space. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Mar 11 16:22:16 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFC212AF7B for ; Mon, 11 Mar 2019 16:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cablelabs.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 s9-SH50TPKyD for ; Mon, 11 Mar 2019 16:22:04 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810138.outbound.protection.outlook.com [40.107.81.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A593131275 for ; Mon, 11 Mar 2019 16:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=joxCKF+HSlXTWVZDLSlKhXSwbHo2AlWN9ykPhLZlVGY=; b=oLUorqpUQ+g4CJjoxi3XYpsqm1g7YhvTuMCUVGb5OX4gXwwyNyRNWbKSx2cfNeBFqJB/0RZeEsS3iXaKvJFvGf2Q3gIdrrU00T/VIooV0glYzUxECsNfeLuVRY0Sfk1j+EeoiykLPSv0jlYJIrEIgpMOzxbY2/7BtBzlNSsSf5I= Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4654.namprd06.prod.outlook.com (52.135.117.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Mon, 11 Mar 2019 23:22:02 +0000 Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b%4]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 23:22:02 +0000 From: Greg White To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-white-tsvwg-nqb-01.txt Thread-Index: AQHU2F4WXIUki47U2k26NZEec7J30aYGrSSA Date: Mon, 11 Mar 2019 23:22:02 +0000 Message-ID: <4BCA2C06-25F6-4662-ADBC-A72097793140@cablelabs.com> References: <155234517020.23066.11385332140494635578.idtracker@ietfa.amsl.com> In-Reply-To: <155234517020.23066.11385332140494635578.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com; x-originating-ip: [2620:0:2b10:23:10e1:3bcc:abbe:9072] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce24854c-dc2a-4814-57bb-08d6a6785e38 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR06MB4654; x-ms-traffictypediagnostic: SN6PR06MB4654: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: 1; SN6PR06MB4654; 20:mAZonJosjs2J3RFX8PlMjagvZngcGrUu6If19XoO8719UVPuuO+LEh7L4MW8wmVe7dEJk6+xDN0hhjCzivcwQmNwP4F4EKyXNeAzT4bt5VGOkI/1aqI82ZdqmjWYuimtdzTpE2TWaU3pA+GVrhV8wGffPI9c5rGXDmir5ZK+47k= x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(366004)(346002)(396003)(376002)(136003)(199004)(189003)(2501003)(14444005)(561944003)(2906002)(256004)(33656002)(6116002)(8936002)(966005)(478600001)(68736007)(1730700003)(8676002)(81156014)(82746002)(81166006)(2351001)(305945005)(7736002)(14454004)(97736004)(83716004)(11346002)(446003)(2616005)(105586002)(106356001)(476003)(486006)(71190400001)(71200400001)(25786009)(86362001)(5640700003)(6512007)(6306002)(6436002)(316002)(6486002)(46003)(36756003)(186003)(15650500001)(76176011)(6916009)(58126008)(6506007)(102836004)(53936002)(66574012)(5660300002)(99286004)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4654; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ugXpaqnBa3KJZL1VPIPs4UhyliuA4m40LXWngDEhM+n+eTMM7V0hBFMOfU5g2cDsk2IKnjEKoGzsxlrm2RnowWruo6bWfJnajpkLP4e/KhiajUDOES6O5mYMtdgzh96fmuRB5kjq3yQl3nJ43v/1lmhyYwH8N35UrbmTBOzLKtFHXJN948l1innqySLAXQQ6qpVinpY5sRQTEZae/03o6s0yPw2WKzmcwDY+AQu2E2K4hgs9cKXU4kQa7GG1CPPbqSrqxsQgWa2KwUUYKVDDKZDj1uas+6XrPrlPWgl9yD1JoE13cj3jjOypf7bJjLGvRCGTuCqW/YM586q+6fvtNTfqEOPhF57wnEbfKQAykVGq4+NaaR5Qotr6+DpH75z0/64HpTWkJT7VtSaZljji9/R4zh2UqWGv00sXbuVSOkM= Content-Type: text/plain; charset="utf-8" Content-ID: <11FE295BF3EFE04E9129F4F6E46EC489@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce24854c-dc2a-4814-57bb-08d6a6785e38 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 23:22:02.4649 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4654 Archived-At: Subject: [tsvwg] New Version Notification for draft-white-tsvwg-nqb-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:22:15 -0000 VFNWV0csDQoNCkkgcG9zdGVkIGFuIHVwZGF0ZSB0byB0aGUgZHJhZnQgb24gTm9uLVF1ZXVlLUJ1 aWxkaW5nIGZsb3dzLiAgSSBoYXZlIGNoYW5nZWQgdGhlIGludGVuZGVkIHN0YXR1cyB0byBTdGFu ZGFyZHMgVHJhY2ssIGFuZCBoYXZlIHVwZGF0ZWQgdGhlIGxhbmd1YWdlIGFjY29yZGluZ2x5IChp LmUuIHRoaXMgaXMgbm93IGEgcHJvcG9zYWwgZm9yIHRoZSBkZWZpbml0aW9uIG9mIGEgUEhCIGFu ZCBEU0NQKS4NCg0KSSBjb25zaWRlcmVkIGFsbCBvZiB0aGUgY29tbWVudHMgb24gdGhlIG1haWxp bmcgbGlzdCwgYW5kIG1hZGUgYSBudW1iZXIgb2YgdXBkYXRlcy4gIEkgZGlkIG5vdCBtYWtlIGFs bCBvZiB0aGUgc3VnZ2VzdGVkIGNoYW5nZXMuICBJbiBwYXJ0aWN1bGFyIERhdmUgVGFodCBoYWQg c3VnZ2VzdGVkIHNvbWUgbW9kaWZpY2F0aW9ucyB0byB0aGlzIHBhcmFncmFwaDoNCg0KRmxvdyBx dWV1ZWluZyBhcHByb2FjaGVzIChzdWNoIGFzIGZxX2NvZGVsIFJGQzgyOTAgW1JGQyA4MjkwXSks IG9uIHRoZSBvdGhlciBoYW5kLCBhY2hpZXZlIGxhdGVuY3kgaW1wcm92ZW1lbnRzIGJ5IGFzc29j aWF0aW5nIHBhY2tldHMgaW50byAiZmxvdyIgcXVldWVzIGFuZCB0aGVuIHByaW9yaXRpemluZyAi c3BhcnNlIGZsb3dzIiwgaS5lLiBwYWNrZXRzIHRoYXQgYXJyaXZlIHRvIGFuIGVtcHR5IGZsb3cg cXVldWUuIEZsb3cgcXVldWVpbmcgZG9lcyBub3QgYXR0ZW1wdCB0byBkaWZmZXJlbnRpYXRlIGJl dHdlZW4gZmxvd3Mgb24gdGhlIGJhc2lzIG9mIHZhbHVlIChpbXBvcnRhbmNlIG9yIGxhdGVuY3kt c2Vuc2l0aXZpdHkpLCBpdCBzaW1wbHkgZ2l2ZXMgcHJlZmVyZW5jZSB0byBzcGFyc2UgZmxvd3Ms IGFuZCB0cmllcyB0byBndWFyYW50ZWUgdGhhdCB0aGUgbm9uLXNwYXJzZSBmbG93cyBhbGwgZ2V0 IGFuIGVxdWFsIHNoYXJlIG9mIHRoZSByZW1haW5pbmcgY2hhbm5lbCBjYXBhY2l0eS4gIEFzIGEg cmVzdWx0LCBmcSBtZWNoYW5pc21zIGNvdWxkIGJlIGNvbnNpZGVyZWQgbW9yZSBhcHByb3ByaWF0 ZSBmb3IgdW5tYW5hZ2VkIGVudmlyb25tZW50cyBhbmQgZ2VuZXJhbCBpbnRlcm5ldCB0cmFmZmlj Lg0KDQoxKSBIZSBoYWQgc3VnZ2VzdGVkIHJlcGxhY2luZyDigJxhc3NvY2lhdGluZyBwYWNrZXRz IGludG8gImZsb3ciIHF1ZXVlc+KAnSB3aXRoIOKAnGJyZWFraW5nIGZsb3dzIGJhY2sgaW50byBp bmRpdmlkdWFsIHBhY2tldHPigJ0uICBGcmFua2x5LCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aGF0 IHRoaXMgbWVhbnMuICBJIGRpZG4ndCBtYWtlIHRoaXMgY2hhbmdlLCBzaW5jZSBJIGFjdHVhbGx5 IGRvbuKAmXQgdGhpbmsgaXQgaGVscHMgdGhlIHJlYWRlciB1bmRlcnN0YW5kIGZxX2NvZGVsLiAg TWF5YmUgd2l0aCBtb3JlIGNvbnRleHQgaXQgbWFrZXMgc2Vuc2UsIGUuZy4gZGVzY3JpYmluZyB0 aGUgYmVoYXZpb3IgdG8gc29tZW9uZSB3aG8gYWxyZWFkeSB1bmRlcnN0YW5kcyBmcV9jb2RlbCwg b3IgYXMgc29tZSBraW5kIG9mIG91dGNvbWUgb2YgdGhlIGZsb3cgaGFzaGluZyBhbmQgc2NoZWR1 bGluZywgYnV0IGFzICp0aGUqIG9uZSBzZW50ZW5jZSBkZWZpbml0aW9uLCBpdCBkaWRuJ3Qgc2Vl bSB0byB3b3JrLiAgDQoNCjIpIEhlJ2Qgc3VnZ2VzdGVkIGNoYW5naW5nIOKAnGkuZS4gcGFja2V0 cyB0aGF0IGFycml2ZSB0byBhbiBlbXB0eSBmbG93IHF1ZXVlLuKAnSB0byDigJxpLmUuIHBhY2tl dHMgdGhhdCBhcnJpdmUgdG8gYW4gZW1wdHkgZmxvdyBxdWV1ZSB0aGF0IGVtcHRpZXMgZXZlcnkg cm91bmQu4oCdICBUaGUgZHJhZnQgZG9lcyBjb250YWluIHRoYXQgZGV0YWlsIGEgY291cGxlIG9m IHBhcmFncmFwaHMgbGF0ZXIsIGFmdGVyIGEgbGl0dGxlIGJpdCBtb3JlIGNvbnRleHQgaGFzIGJl ZW4gcHJvdmlkZWQuIOKAnEluIGZxX2NvZGVsLCBhIGZsb3cgcXVldWUgaXMgY29uc2lkZXJlZCBz cGFyc2UgaWYgaXQgaXMgZHJhaW5lZCBjb21wbGV0ZWx5IGJ5IGVhY2ggcGFja2V0IHRyYW5zbWlz c2lvbiwgYW5kIHJlbWFpbnMgZW1wdHkgZm9yIGF0IGxlYXN0IG9uZSBjeWNsZSBvZiB0aGUgcm91 bmQgcm9iaW4gb3ZlciB0aGUgYWN0aXZlIGZsb3dzICh0aGlzIGlzIGFwcHJveGltYXRlbHkgZXF1 aXZhbGVudCB0byBzYXlpbmcgdGhhdCBpdCB1dGlsaXplcyBsZXNzIHRoYW4gaXRzIGZhaXIgc2hh cmUgb2YgY2FwYWNpdHkpLuKAnSAgU28sIEkgZmVsdCBhcyBpZiB0aGlzIG9uZSB3YXMgYWxyZWFk eSBjb3ZlcmVkLg0KDQozKSBIZeKAmWQgc3VnZ2VzdGVkIGNoYW5naW5nIOKAnGdpdmVzIHByZWZl cmVuY2UgdG8gc3BhcnNlIGZsb3dz4oCdIHRvIOKAnGdpdmluZyBhIHNsaWdodCBwcmVmZXJlbmNl IHRvIHNwYXJzZSBmbG93cy7igJ0gIFRoZSBmcV9jb2RlbCBSRkMgaXMgcHJldHR5IGNsZWFyIHRo YXQgc3BhcnNlIChuZXcpIGZsb3dzIGFyZSBnaXZlbiBzdHJpY3QgcHJpb3JpdHkgb3ZlciBub24t c3BhcnNlIChvbGQpIGZsb3dzLiAgU28sIHNheWluZyDigJxhIHNsaWdodCBwcmVmZXJlbmNl4oCd IHNlZW1zIGRpc2luZ2VudW91cy4gICAgSeKAmW0gZ29pbmcgdG8gc3RhbmQgYnkgbXkgb3JpZ2lu YWwgd29yZGluZyB0aGVyZSB0b28uDQoNCjQpIEhl4oCZZCBzdWdnZXN0ZWQgY2hhbmdpbmcg4oCc YW5kIHRyaWVzIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSBub24tc3BhcnNlIGZsb3dzIGFsbCBnZXQg YW4gZXF1YWwgc2hhcmUgb2YgdGhlIHJlbWFpbmluZyBjaGFubmVsIGNhcGFjaXR54oCdIHRvIOKA nGludGVybGVhdmVzIGZsb3dzIGFzIGJlc3QgYXMgcG9zc2libGXigJ0uICBJIGRpZG4ndCBkZWxl dGUgdGhlIGZhaXIgc2NoZWR1bGluZyBwYXJ0LCBidXQgdGhlIGludGVybGVhdmluZyBwYXJ0IHdh cyBhIHVzZWZ1bCBhZGRpdGlvbi4gIEkgY2hhbmdlZCBpdCB0bzog4oCcYW5kIHRyaWVzIHRvIGd1 YXJhbnRlZSB0aGF0IHRoZSBub24tc3BhcnNlIGZsb3dzIGFsbCBnZXQgYW4gZXF1YWwgc2hhcmUg b2YgdGhlIHJlbWFpbmluZyBjaGFubmVsIGNhcGFjaXR5IGFuZCBhcmUgaW50ZXJsZWF2ZWQgd2l0 aCBvbmUgYW5vdGhlcuKAnQ0KDQotR3JlZw0KDQoNCg0K77u/T24gMy8xMS8xOSwgNDo1OSBQTSwg ImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3Jv dGU6DQoNCiAgICANCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2hpdGUtdHN2d2ct bnFiLTAxLnR4dA0KICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBX aGl0ZSBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYgcmVwb3NpdG9yeS4NCiAgICANCiAgICBO YW1lOgkJZHJhZnQtd2hpdGUtdHN2d2ctbnFiDQogICAgUmV2aXNpb246CTAxDQogICAgVGl0bGU6 CQlJZGVudGlmeWluZyBhbmQgSGFuZGxpbmcgTm9uIFF1ZXVlIEJ1aWxkaW5nIEZsb3dzIGluIGEg Qm90dGxlbmVjayBMaW5rDQogICAgRG9jdW1lbnQgZGF0ZToJMjAxOS0wMy0xMQ0KICAgIEdyb3Vw OgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAgUGFnZXM6CQk5DQogICAgVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13aGl0ZS10c3Z3 Zy1ucWItMDEudHh0DQogICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXdoaXRlLXRzdndnLW5xYi8NCiAgICBIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdoaXRlLXRzdndnLW5xYi0wMQ0KICAgIEh0 bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LXdoaXRlLXRzdndnLW5xYg0KICAgIERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtd2hpdGUtdHN2d2ctbnFiLTAxDQogICAgDQogICAgQWJzdHJh Y3Q6DQogICAgICAgVGhpcyBkcmFmdCBwcm9wb3NlcyB0aGUgZGVmaW5pdGlvbiBvZiBhIHN0YW5k YXJkaXplZCBEU0NQIHRvIGlkZW50aWZ5DQogICAgICAgTm9uLVF1ZXVlLUJ1aWxkaW5nIGZsb3dz LCBhbG9uZyB3aXRoIGEgUGVyLUhvcC1CZWhhdmlvciAoUEhCKSB0aGF0DQogICAgICAgcHJvdmlk ZXMgYSBzZXBhcmF0ZSBxdWV1ZSBmb3Igc3VjaCBmbG93cy4NCiAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAg IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQogICAgDQogICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICANCiAgICAN Cg0K From nobody Mon Mar 11 16:28:28 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE24124184 for ; Mon, 11 Mar 2019 16:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xuk5QvcieMR9 for ; Mon, 11 Mar 2019 16:28:22 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA087128B77 for ; Mon, 11 Mar 2019 16:28:22 -0700 (PDT) Received: by bugle.employees.org (Postfix, from userid 1736) id 605B6FECC035; Mon, 11 Mar 2019 23:28:22 +0000 (UTC) Date: Tue, 12 Mar 2019 00:28:22 +0100 From: Derek Fawcus To: tsvwg Message-ID: <20190311232822.GA31999@bugle.employees.org> References: <20190311221839.GA92478@bugle.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190311221839.GA92478@bugle.employees.org> User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: [tsvwg] LITE+FRAG UDP CS=0 (was Re: OCS option in draft-ietf-tsvwg-udp-options-07) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:28:25 -0000 On Mon, Mar 11, 2019 at 11:18:39PM +0100, Derek Fawcus wrote: > > Actually, my original thought here (which I then culled), was to have another > option, or ACS. That other option would encode the current style of checksum, > so for concerns about CPU cost of using CRC, we could mitigate it. > > What I had in mind was an option containing two 16 bit fields, one would > encode the partial-checksum for the pseudo-header as the originator sent > it, the other the partial-checksum for the original UDP payload. > > e.g.: [ Type = Frag-Chks | Len | part-phdr-chk | part-data-chk ] > > That way the receiver can recover from any NAT mangling of the packet which > would otherwise mess with the checksum calculation. > > i.e. for the UDP portion, assuming the packet was encoded with UDP CS=0 > > 1. Calculate partial checksum for pseudo-header as received > 2. Compare to option part-phdr-chk > 2a. If equal verify UDP data against part-data-chk > 2b. If differ verify UDP data against part-data-chk + (part-phdr-chk - phdr-chk) It might help to explain my line of reasoning here.. My first idea for using UDP CS=0 for LITE+FRAG was simply to move the original UDP CS in to an option. i.e. the host stack would operate as normal, building its UDP header. Then during building the options area, it would copy the UDP CS in to an option (call it the Moved Checksum - MCS), and zero the CS in the UDP header. So we end up with something like: [Kind=MCS|Len=4|16 bit checksum] Then I realised this would be broken by NATs. Hence concluding one would have to also carry the partial checksum for the original pseudo-header (i.e. src-ip/dst-ip/src-port/dst-port/proto) such that NAT manipulations can be compensated for: [Kind=MCS|Len=6|16 bit part-phdr-chk|16 bit original-chk] So the processing on the TX side to generate that is no more costly, the RX side would have a bit more work. Conceptually generating: new-chk = original-chk - (part-phdr-chk - rx-phdr-chk) Then writing that over the UDP CS field, before passing the packet in to the original receive / validate routine. Sending two partial checksums is just another way of achieving the same effect. Maybe the moved version is clearer? Since we know that this checksum is for the pseudo-header and UDP header alone, with len=0 and no carried data; I'm just wondering now if that can be improved? DF From nobody Mon Mar 11 16:29:07 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539FF1279B1 for ; Mon, 11 Mar 2019 16:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cablelabs.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 N22yTaS1uZmH for ; Mon, 11 Mar 2019 16:29:04 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700118.outbound.protection.outlook.com [40.107.70.118]) (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 0368C124184 for ; Mon, 11 Mar 2019 16:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9IxbTojdJfZnvLffIU9mRqV2FZ7ronVqCQ+li+q5Tnk=; b=Q2wOBxqZzQwodsz/5xWWHwXMesm4YpDo3IWmewsbY36dNrC0TAVgf1yBNL8itGM1qXz8QsRc6UWjVKBv7zQco9MtI1KKIfDMknuBkeJkcrTPr0trqlvOzYqFFfckF9/LRlTQoLENUTmMuaeQUqJbW6PhoZP7ra86iJMyYVXpAzw= Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB5344.namprd06.prod.outlook.com (20.178.7.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Mon, 11 Mar 2019 23:29:00 +0000 Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b%4]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 23:29:00 +0000 From: Greg White To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-white-tsvwg-lld-00.txt Thread-Index: AQHU2F7oTsc8of+7tUym2YCp4/WqfKYGrxYA Date: Mon, 11 Mar 2019 23:29:00 +0000 Message-ID: <204DA455-65DB-4BF9-9A0C-84BA6304E2DC@cablelabs.com> References: <155234552106.23142.787880441718627246.idtracker@ietfa.amsl.com> In-Reply-To: <155234552106.23142.787880441718627246.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com; x-originating-ip: [2620:0:2b10:23:10e1:3bcc:abbe:9072] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e7ecdd0-94c8-4194-b3e1-08d6a6795783 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR06MB5344; x-ms-traffictypediagnostic: SN6PR06MB5344: x-ms-exchange-purlcount: 6 x-microsoft-exchange-diagnostics: 1; SN6PR06MB5344; 20:8Y34Js3HSWi9JFdtSWrWaMJImvTV61aEhq4tSXvQXjO6PeXWrr/Kj4r9+p6ojqedV/+ort54igDDN9JqzT0SOuYiZ8kGoyX5rYJzaLs41GdYH6dSG/esyO4Us8n5/hKIuY98rEGIVsiXNR1ipM0AN7GQkFNZAzPVK40LrQF8/wc= x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(376002)(396003)(39850400004)(189003)(199004)(68736007)(6916009)(82746002)(86362001)(256004)(14444005)(6116002)(7736002)(99286004)(33656002)(305945005)(81156014)(8676002)(1730700003)(446003)(71200400001)(8936002)(486006)(2616005)(71190400001)(476003)(81166006)(36756003)(2906002)(46003)(83716004)(14454004)(478600001)(2351001)(97736004)(105586002)(25786009)(106356001)(102836004)(6306002)(66574012)(11346002)(6506007)(53936002)(2501003)(6486002)(186003)(6436002)(6512007)(76176011)(5660300002)(5640700003)(58126008)(316002)(966005)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB5344; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: yFNNPNiYbIn7vRROA+bBKyMp6TPExzTI5+Vo3nsaVoBb/Qs+ifXpK125b4a+Jc14DOMip86K3TI68rv+WBxtyxCFY5HfiaRDBpc9xRZr0QFThD+eft0CcFq8a0v2wKPKJ+wfNZn55DxWW3vEGCf5tKAjsVtMqcugSn+BDPSKclqWds6SnTlbhPBB30wJiGwEYN7oKiB6BVHt2/wK0GH1vse7U505xfFAqwZcuK9EUA2dPQXdTZ8hyykUnASDwqHvPrD8X8i/PsFQ+e2N38tmqj81PEmuqZAn9xOxtc2WM9vaY4S2zUiJ34AbLiYEBWLLs0JnAiOtsPOyjVu9ktRkk9fKgKWmnfCkgadW3XW9awmJYWHFvLxNwqtri6ps4eU+5HvVcf/3ZVSWqvhwmmPcNx99o7LXXHJHBeZTELy2G+M= Content-Type: text/plain; charset="utf-8" Content-ID: <9C7D32498BDB8B438A2AFA229AABFCFB@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e7ecdd0-94c8-4194-b3e1-08d6a6795783 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 23:29:00.7295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB5344 Archived-At: Subject: [tsvwg] New Version Notification for draft-white-tsvwg-lld-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:29:06 -0000 VFNWV0csDQoNCkkndmUgcG9zdGVkIGEgbmV3IGluZm9ybWF0aXZlIGRyYWZ0IHRoYXQgZ2l2ZXMg YW4gb3ZlcnZpZXcgb2YgdGhlIG5ldyBMb3cgTGF0ZW5jeSBET0NTSVMgc3BlY2lmaWNhdGlvbiAo c2VlIGxpbmtzIGJlbG93KS4gIFRoaXMgb3ZlcnZpZXcgbWF5IGJlIGludGVyZXN0aW5nIHRvIFRT VldHIHBhcnRpY2lwYW50cyBiZWNhdXNlIGl0IGluY2x1ZGVzIHN1cHBvcnQgZm9yIEw0UyAoaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWFxbS1k dWFscS1jb3VwbGVkKSBhbmQgZm9yIHRoZSBOUUIgUEhCIChodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LXdoaXRlLXRzdndnLW5xYikuDQoNCkJlc3QgUmVnYXJkcywN CkdyZWcNCg0KDQoNCu+7v09uIDMvMTEvMTksIDU6MDUgUE0sICJpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdoaXRlLXRzdndnLWxsZC0wMC50eHQNCiAgICBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdyZWcgV2hpdGUgYW5kIHBvc3RlZCB0byB0 aGUNCiAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAgDQogICAgTmFtZToJCWRyYWZ0LXdoaXRlLXRz dndnLWxsZA0KICAgIFJldmlzaW9uOgkwMA0KICAgIFRpdGxlOgkJTG93IExhdGVuY3kgRE9DU0lT IC0gVGVjaG5vbG9neSBPdmVydmlldw0KICAgIERvY3VtZW50IGRhdGU6CTIwMTktMDMtMTENCiAg ICBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgIFBhZ2VzOgkJMjUNCiAgICBVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdo aXRlLXRzdndnLWxsZC0wMC50eHQgDQogICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdoaXRlLXRzdndnLWxsZC8gDQogICAgSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aGl0ZS10c3Z3Zy1sbGQt MDAgDQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtd2hpdGUtdHN2d2ctbGxkIA0KICAgIA0KICAgIA0KICAgIEFic3RyYWN0Og0K ICAgICAgIE5PVEU6IFRoaXMgZG9jdW1lbnQgaXMgYSByZWZvcm1hdHRlZCB2ZXJzaW9uIG9mIFtM TEQtd2hpdGUtcGFwZXJdLg0KICAgIA0KICAgICAgIFRoZSBldm9sdXRpb24gb2YgdGhlIGJhbmR3 aWR0aCBjYXBhYmlsaXRpZXMgLSBmcm9tIGtpbG9iaXRzIHBlcg0KICAgICAgIHNlY29uZCB0byBn aWdhYml0cyAtIGFjcm9zcyBnZW5lcmF0aW9ucyBvZiBET0NTSVMgY2FibGUgYnJvYWRiYW5kDQog ICAgICAgdGVjaG5vbG9neSBoYXMgcGF2ZWQgdGhlIHdheSBmb3IgdGhlIGFwcGxpY2F0aW9ucyB0 aGF0IHRvZGF5IGZvcm0gb3VyDQogICAgICAgZGlnaXRhbCBsaXZlcy4gIEFsb25nIHdpdGggaW5j cmVhc2VkIGJhbmR3aWR0aCwgb3IgInNwZWVkIiwgdGhlDQogICAgICAgbGF0ZW5jeSBwZXJmb3Jt YW5jZSBvZiBET0NTSVMgdGVjaG5vbG9neSBoYXMgYWxzbyBpbXByb3ZlZCBpbiByZWNlbnQNCiAg ICAgICB5ZWFycy4gIEFsdGhvdWdoIGl0IG9mdGVuIGdldHMgbGVzcyBhdHRlbnRpb24sIGxhdGVu Y3kgcGVyZm9ybWFuY2UNCiAgICAgICBjb250cmlidXRlcyBhcyBtdWNoIG9yIG1vcmUgdG8gdGhl IGJyb2FkYmFuZCBleHBlcmllbmNlIGFuZCB0aGUNCiAgICAgICBmZWFzaWJpbGl0eSBvZiBmdXR1 cmUgYXBwbGljYXRpb25zIGFzIGRvZXMgc3BlZWQuDQogICAgDQogICAgICAgTG93IExhdGVuY3kg RE9DU0lTIHRlY2hub2xvZ3kgKExMRCkgaXMgYSBzcGVjaWZpY2F0aW9uIGRldmVsb3BlZCBieQ0K ICAgICAgIENhYmxlTGFicyBpbiBjb2xsYWJvcmF0aW9uIHdpdGggRE9DU0lTIHZlbmRvcnMgYW5k IGNhYmxlIG9wZXJhdG9ycw0KICAgICAgIHRoYXQgdGFja2xlcyB0aGUgdHdvIG1haW4gY2F1c2Vz IG9mIGxhdGVuY3kgaW4gdGhlIG5ldHdvcms6IHF1ZXVpbmcNCiAgICAgICBkZWxheSBhbmQgbWVk aWEgYWNxdWlzaXRpb24gZGVsYXkuICBMTEQgaW50cm9kdWNlcyBhbiBhcHByb2FjaA0KICAgICAg IHdoZXJlaW4gZGF0YSB0cmFmZmljIGZyb20gYXBwbGljYXRpb25zIHRoYXQgYXJlbid0IGNhdXNp bmcgbGF0ZW5jeQ0KICAgICAgIGNhbiB0YWtlIGEgZGlmZmVyZW50IGxvZ2ljYWwgcGF0aCB0aHJv dWdoIHRoZSBET0NTSVMgbmV0d29yayB3aXRob3V0DQogICAgICAgZ2V0dGluZyBodW5nIHVwIGJl aGluZCBkYXRhIGZyb20gYXBwbGljYXRpb25zIHRoYXQgYXJlIGNhdXNpbmcNCiAgICAgICBsYXRl bmN5LCBhcyBpcyB0aGUgY2FzZSBpbiB0b2RheSdzIEludGVybmV0IGFyY2hpdGVjdHVyZXMuICBU aGlzDQogICAgICAgbWVjaGFuaXNtIGRvZXNuJ3QgaW50ZXJmZXJlIHdpdGggdGhlIHdheSBhcHBs aWNhdGlvbnMgc2hhcmUgdGhlIHRvdGFsDQogICAgICAgYmFuZHdpZHRoIG9mIHRoZSBjb25uZWN0 aW9uLCBhbmQgaXQgZG9lc24ndCByZWR1Y2Ugb25lIGFwcGxpY2F0aW9uJ3MNCiAgICAgICBsYXRl bmN5IGF0IHRoZSBleHBlbnNlIG9mIG90aGVycy4gIEluIGFkZGl0aW9uLCBMTEQgaW1wcm92ZXMg dGhlDQogICAgICAgRE9DU0lTIHVwc3RyZWFtIG1lZGlhIGFjcXVpc2l0aW9uIGRlbGF5IHdpdGgg YSBmYXN0ZXIgcmVxdWVzdC1ncmFudA0KICAgICAgIGxvb3AgYW5kIGEgbmV3IHByb2FjdGl2ZSBz Y2hlZHVsaW5nIG1lY2hhbmlzbS4gIExMRCBtYWtlcyB0aGUNCiAgICAgICBpbnRlcm5ldCBleHBl cmllbmNlIGJldHRlciBmb3IgbGF0ZW5jeSBzZW5zaXRpdmUgYXBwbGljYXRpb25zIHdpdGhvdXQN CiAgICAgICBhbnkgbmVnYXRpdmUgaW1wYWN0IG9uIG90aGVyIGFwcGxpY2F0aW9ucy4NCiAgICAN CiAgICAgICBUaGUgbGF0ZXN0IGdlbmVyYXRpb24gb2YgRE9DU0lTIGVxdWlwbWVudCB0aGF0IGhh cyBiZWVuIGRlcGxveWVkIGluDQogICAgICAgdGhlIGZpZWxkIC0gRE9DU0lTIDMuMSAtIGV4cGVy aWVuY2VzIHR5cGljYWwgbGF0ZW5jeSBwZXJmb3JtYW5jZSBvZg0KICAgICAgIGFyb3VuZCAxMCBt aWxsaXNlY29uZHMgKG1zKSBvbiB0aGUgQWNjZXNzIE5ldHdvcmsgbGluay4gIEhvd2V2ZXIsDQog ICAgICAgdW5kZXIgaGVhdnkgbG9hZCwgdGhlIGxpbmsgY2FuIGV4cGVyaWVuY2UgZGVsYXkgc3Bp a2VzIG9mIDEwMCBtcyBvcg0KICAgICAgIG1vcmUuICBMTEQgc3lzdGVtcyBjYW4gZGVsaXZlciBh IGNvbnNpc3RlbnQgMSBtcyBkZWxheSBvbiB0aGUgRE9DU0lTDQogICAgICAgbmV0d29yayBmb3Ig dHJhZmZpYyB0aGF0IGlzbid0IGNhdXNpbmcgbGF0ZW5jeSwgaW1wZXJjZXB0aWJsZSBmb3INCiAg ICAgICBuZWFybHkgYWxsIGFwcGxpY2F0aW9ucy4gIFRoZSBleHBlcmllbmNlIHdpbGwgYmUgbW9y ZSBjb25zaXN0ZW50IHdpdGgNCiAgICAgICBtdWNoIHNtYWxsZXIgZGVsYXkgdmFyaWF0aW9uLg0K ICAgIA0KICAgICAgIExMRCBjYW4gYmUgZGVwbG95ZWQgYnkgZmllbGQtdXBncmFkaW5nIERPQ1NJ UyAzLjEgY2FibGUgbW9kZW0gYW5kDQogICAgICAgY2FibGUgbW9kZW0gdGVybWluYXRpb24gc3lz dGVtIGRldmljZXMgd2l0aCBuZXcgc29mdHdhcmUuICBUaGUNCiAgICAgICB0ZWNobm9sb2d5IGlu Y2x1ZGVzIHRvb2xzIHRoYXQgZW5hYmxlIGF1dG9tYXRpYyBwcm92aXNpb25pbmcgb2YgdGhlc2UN CiAgICAgICBuZXcgc2VydmljZXMsIGFuZCBpdCBhbHNvIGludHJvZHVjZXMgbmV3IHRvb2xzIHRv IHJlcG9ydCBzdGF0aXN0aWNzDQogICAgICAgb2YgbGF0ZW5jeSBwZXJmb3JtYW5jZSB0byB0aGUg b3BlcmF0b3IuDQogICAgDQogICAgICAgQ2FibGUgb3BlcmF0b3JzLCBET0NTSVMgZXF1aXBtZW50 IG1hbnVmYWN0dXJlcnMsIGFuZCBhcHBsaWNhdGlvbg0KICAgICAgIHByb3ZpZGVycyB3aWxsIGFs bCBoYXZlIHRvIGFjdCBpbiBvcmRlciB0byB0YWtlIGFkdmFudGFnZSBvZiBMTEQuDQogICAgICAg VGhpcyB3aGl0ZSBwYXBlciBleHBsYWlucyB0aGUgdGVjaG5vbG9neSBhbmQgZGVzY3JpYmVzIHRo ZSByb2xlIHRoYXQNCiAgICAgICBlYWNoIG9mIHRoZXNlIHBhcnRpZXMgcGxheXMgaW4gbWFraW5n IExMRCBhIHJlYWxpdHkuDQogICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAg IA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0K ICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQogICAgDQogICAgDQoNCg== From nobody Mon Mar 11 16:31:26 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F27C1311E3 for ; Mon, 11 Mar 2019 16:31:17 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkGMRKvtjqkg for ; Mon, 11 Mar 2019 16:31:14 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F851311B9 for ; Mon, 11 Mar 2019 16:31:14 -0700 (PDT) Received: from dancer.taht.net (c-73-162-29-198.hsd1.ca.comcast.net [73.162.29.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id DEB992200A; Mon, 11 Mar 2019 23:31:10 +0000 (UTC) From: Dave Taht To: Bob Briscoe Cc: David Pullen , tsvwg@ietf.org References: <87muouco0q.fsf@taht.net> Date: Mon, 11 Mar 2019 16:31:07 -0700 In-Reply-To: (Bob Briscoe's message of "Mon, 11 Mar 2019 20:17:55 +0000") Message-ID: <87lg1lm1j8.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [tsvwg] Technical review 5 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:31:25 -0000 Bob Briscoe writes: > Dave, > > While looking for your name, I found your posting from Xmas Day, that > I never replied to - sorry. It would have helped. > > The main thing I think you've missed is that the WRR scheduler between > the two queues doesn't actually do anything in all normal > circumstances. The DualQ actually even works with a strict priority > scheduler because of this. > > The scheduling is done by the senders, just as if the 2 queues were a > single FIFO. That's not obvious so let me explain... > > When there's traffic in the Classic queue, the ECN marking in the L4S > queue coupled over from the Classic AQM, causes the L4S sender to > leave enough space between it's packets for the classic queue. When > Koen first suggested this, I didn't think it would work, but it works > amazingly accurately. I'll believe it only after y'all subject it to bufferbloat.net's core benchmark suites - flent.org and irtt. or, after I get a chance to try it myself... Did you try any of those yet - notably the rrul series of tests? I'd love to get some tests with the --socket-stats option enabled to be able to look closely at the tcp rtts. > > The only reason for using WRR instead of strict priority is to give > the Classic queue a chance, in case of an unresponsive sender in the L > queue. It's good to keep the weight high (we recommend 15/16) so L4S > packets get served quickly. Still sounds to me like normal (as opposed to what you call classic - to me it's *normal*) But look, we're finally at the point where I can take a good hard look at this, at least at a black box level (due to the FRAND patent I simply cannot look at the code) > > Not using strict priority also ensures that an initial DNS or SYN > packet in the Classic queue is released quickly if there's a > continuous flow going in the L4S queue. > > In the Linux implementation, we also provide a scheduler called > time-shifted FIFO, but we recommend WRR (particularly in the DOCSIS > case, cos TS-FIFO needs packet time-stamping, which existing cable > modem hardware doesn't support). TS-FIFO just takes the packet that > arrived first, but for one queue it first subtracts from the arrival > time by a pre-configured amount (e.g. 30ms) to prioritize it. > > > > Bob > > On 25/12/2018 02:56, Dave Taht wrote: >> Bob Briscoe writes: >> >>> David, >>> >>> OK, you're right that we don't do a good job of justifying this, other >>> than hinting that WRR is already well-known. >>> >>> I've recorded much more of the thinking behind this choice. I've also >>> explained why the choice of WRR scheduler weight is not important, as >>> follows (additions in green): >>> >>> o A well-understood weighted scheduler such as weighted round robin >>> (WRR) is recommended. The scheduler weight for Classic should be >>> low, e.g. 1/16. Note that the coupled congestion signal typically >>> make L4S sources leave roughly equal per-flow capacity available >>> for classic flows. So, if the weight is small, its exact value is >>> unimportant because it does not normally determine capacity >>> shares. The weight is only important to prevent unresponsive L4S >>> traffic starving classic traffic. >> I note that the "fq" portion of fq_codel (RFC8290) has better >> min/max properties >> than straight drr, as does qfq. >> >> I am saddened that there is seemingly no fq or aqm component >> intended for >> "classic" flows in this design, as if it didn't need it. >> >> The first deployment of fq_codel (free.fr's) had the following >> weighted >> queue structure: >> >> drr 1 priority fq_codel (diffserv markings) >> drr 2 best effort fq_codel >> drr 3 background fq_codel >> >> and nearly the entire qos related deployment of this has essentially >> the >> same structure, including sch_cake. >> >> In deprioritizing "classic" to 1/16 the total possible flow volume, >> any >> form of weighted fair queuing can be used, but I still don't know >> why >> you wish to punish classic flows so much by eliding aqm and fq on >> those. >> >> >> >>> o Alternatively, a time-shifted FIFO (TS-FIFO) could be used. It >>> works by selecting the head packet that has waited the longest, >>> biased against the Classic traffic by a time-shift of tshift. To >>> implement time-shifted FIFO, the "if (scheduler() == lq )" test in >>> line 3 of the dequeue code would simply be replaced by "if ( >>> lq.time() + tshift >= cq.time() )". For the public Internet a >>> good value for tshift is 50ms. For private networks with smaller >>> diameter, about 4*target would be reasonable. TS-FIFO is a very >>> simple scheduler, but complexity might need to be added to address >>> some deficiencies (which is why it is not recommended over WRR): >>> >>> * TS-FIFO does not fully isolate latency in the L4S queue from >>> uncontrolled bursts in the Classic queue; >>> >>> * TS-FIFO is only appropriate if time-stamping of packets is >>> feasible; >>> >>> * Even if time-stamping is supported, the sojourn time of the >>> head packet is always stale. For instance, if a burst arrives >>> at an empty queue, the sojourn time will only measure the delay >>> of the burst once the burst is over, even though the queue knew >>> about it from the start. At the cost of more operations and >>> more storage, a 'scaled sojourn time' metric of queue delay can >>> be used, which is the sojourn time of a packet scaled by the >>> ratio of the queue sizes when the packet departed and arrived. >>> >>> Bob >>> >>> On 18/12/2018 19:53, David Pullen wrote: >>> >>> Hi Bob, >>> At the end of Appendix A, WRR is recommended over >>> time-shifted >>> FIFO, but no real justification is given. Why is WRR recommended? >>> Thanks, >>> - Dave >>> David Pullen Distinguished Engineer | Wired >>> Networking, Cable >>> Modems Broadcom office: 678.475.3143 | mobile: 678.477.4108 | fax: >>> 770.232.0211 4385 River Green Parkway | Duluth, GA 30096 >>> david.pullen@broadcom.com | broadcom.com From nobody Mon Mar 11 16:33:27 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD37E124184 for ; Mon, 11 Mar 2019 16:33:26 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivHsuYASzGV9 for ; Mon, 11 Mar 2019 16:33:24 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7B413122C for ; Mon, 11 Mar 2019 16:33:24 -0700 (PDT) Received: from dancer.taht.net (c-73-162-29-198.hsd1.ca.comcast.net [73.162.29.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 330F82200A; Mon, 11 Mar 2019 23:33:21 +0000 (UTC) From: Dave Taht To: Greg White Cc: Bob Briscoe , "tsvwg\@ietf.org" , Jonathan Morton References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> <63DC5E45-449A-4008-9041-95A3C7216FF4@cablelabs.com> Date: Mon, 11 Mar 2019 16:33:19 -0700 In-Reply-To: <63DC5E45-449A-4008-9041-95A3C7216FF4@cablelabs.com> (Greg White's message of "Mon, 11 Mar 2019 17:15:54 +0000") Message-ID: <87h8c9m1fk.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:33:27 -0000 Greg White writes: > On the item below, I am intending to finish up and submit a TSVWG > informational draft today that describes the (new) mandatory support > for L4S AQM and dual-queue requirement in DOCSIS 3.1 (CM & CMTS) > equipment. The draft will essentially be a reformat of this document: > > https://cablela.bs/low-latency-docsis-technology-overview-february-2019 > > These requirements were added in December, and will roll out as > firmware updates to existing DOCSIS 3.1 equipment (nearly 100% of > CMTSs, and a growing fraction of CMs) over time. I was unaware of this notice, and as I note, it's only march... Using up the last ECN bit in this way, for the sole benefit of the cable industry, strikes me as a poor standard for the internet. > > -Greg > > From: tsvwg on behalf of Bob Briscoe > > Date: Monday, March 11, 2019 at 10:29 AM > To: Dave Taht , "tsvwg@ietf.org" > Cc: Jonathan Morton > Subject: Re: [tsvwg] New Version Notification for > draft-morton-taht-tsvwg-sce-00.txt > > L4S is far from dead. It's merely been working differently from how > you're used to. Those working on an L4S AQM (at least those in the > cable industry) had to have a private WG for the last ~18 months, but > now we're allowed to publish and talk openly again. From nobody Mon Mar 11 16:50:13 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE9013120E for ; Mon, 11 Mar 2019 16:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cablelabs.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 ljdaL1hWbpde for ; Mon, 11 Mar 2019 16:50:02 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700135.outbound.protection.outlook.com [40.107.70.135]) (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 3B1A4131254 for ; Mon, 11 Mar 2019 16:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U8STvNEhg0vv2Czk7t6ZECsGl8EHVtnUnQgWX7G1THY=; b=fVN+jlyS+aOBHV2r6UcnRJzecrTVV6Z5zBMiQKjloriCzeY/xl7Ye4ElhN6w6+BnFQ5fGzGS61weng+ZBKGRKcLfCLLX1WpumL4b4WbOe1tkRt9CpCgzabObfgwmPM4Qs6EdDMS/x72ugJnSKE4QazIz4mBFxOpv+YPxRGVqRpc= Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4846.namprd06.prod.outlook.com (52.135.112.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19; Mon, 11 Mar 2019 23:49:59 +0000 Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b%4]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 23:49:59 +0000 From: Greg White To: Dave Taht CC: Bob Briscoe , "tsvwg@ietf.org" , Jonathan Morton Thread-Topic: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt Thread-Index: AQHU16gidytVluJIdkSixRL8FOY/naYGn8cA//+ofYCAAM4TFP//oAmA Date: Mon, 11 Mar 2019 23:49:59 +0000 Message-ID: <2CFCED24-68E9-4430-95FC-380E415D82B3@cablelabs.com> References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> <63DC5E45-449A-4008-9041-95A3C7216FF4@cablelabs.com> <87h8c9m1fk.fsf@taht.net> In-Reply-To: <87h8c9m1fk.fsf@taht.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com; x-originating-ip: [2620:0:2b10:23:10e1:3bcc:abbe:9072] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6eff9b41-8b1f-400f-ef1e-08d6a67c45e0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR06MB4846; x-ms-traffictypediagnostic: SN6PR06MB4846: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: 1; SN6PR06MB4846; 20:Q6Q0MJ7IFWTEi5TtCRLz9z8JTIxyIjpGNTpzIu9PI+TFBMiX8jDucDASqvh4xjf5s3C0cBFvZ1FMDxZg4GrPXn4yUJCMksMu/CnKp3ETLpHCk0h4SM/5XbOKrpF4XFq7PAuw9kB6goo/Tqtu6FXtFns5EK8vwMxv8uxAWHi1Mtk= x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(346002)(366004)(136003)(376002)(396003)(189003)(199004)(106356001)(76176011)(966005)(478600001)(46003)(2616005)(6246003)(4326008)(186003)(71190400001)(102836004)(71200400001)(446003)(25786009)(6506007)(36756003)(105586002)(6116002)(33656002)(476003)(11346002)(53546011)(229853002)(316002)(58126008)(99286004)(54906003)(256004)(53936002)(6436002)(6512007)(6306002)(14444005)(14454004)(6916009)(7736002)(6486002)(83716004)(81166006)(81156014)(8936002)(8676002)(86362001)(97736004)(66574012)(2906002)(82746002)(486006)(68736007)(305945005)(5660300002)(93886005)(15650500001)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4846; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Zcfw3bBwJNoDPAjFKiY3JtNHAcOeOdvsnvBDUYQZebW+zUAeUeqgdtdd3RAIilYI5qno6VhUQFS18icImMyMhHwMjzsYjYJ9YLahPoTArCxQtN5omOWmEyn8vL/Kr/JC+9pqbB/6hBdlwsdX4weRBw14hFhxp3ka+x106IIXkWG5rwkeRHl+q/RxHRiq6ebZe7OOalLq6R5WooI7pak+4NvUNjtl8AEN3Je2gmNlQ7tDDC3Gthfx7QenDqwii38eoB6poGHuzJURmis1DusvLv5qVz+1KChP/4OE0uApx+RCYxXD4x8LLG5aIdRRio3MmUu1gEjkeBc09yraxYRFpT4oIICGdxBSNXZRGPv6eHPUvMzPR7CPcgpCTRveCFYSNpwhpPsN1ci+Sdzv8lXtYl/QH9N7gQXZRmnfzB8mJrs= Content-Type: text/plain; charset="utf-8" Content-ID: <5A936DDD24396F43B3C1A5FFEC0EC073@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6eff9b41-8b1f-400f-ef1e-08d6a67c45e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 23:49:59.6177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4846 Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:50:12 -0000 SSdtIG5vdCBzdXJlIGhvdyB5b3UgbWlzaW50ZXJwcmV0ZWQgTDRTIGFzIGJlaW5nICJmb3IgdGhl IHNvbGUgYmVuZWZpdCBvZiB0aGUgY2FibGUgaW5kdXN0cnkiLiAgSXQgaXMgYSBzdGFuZGFyZHMt dHJhY2sgZHJhZnQgaGVyZSBhdCBJRVRGLiAgRnJvbSB3aGF0IEkgdW5kZXJzdGFuZCwgbXVsdGlw bGUgbmV0d29yayB0ZWNobm9sb2dpZXMgYXJlIGluIHRoZSBwcm9jZXNzIG9mIGltcGxlbWVudGlu ZyBpdC4gIE5vbmUgaGF2ZSBiZWVuIHB1YmxpYyBhYm91dCBpdCB1bnRpbCBub3cuDQoNCi1HcmVn DQoNCg0K77u/T24gMy8xMS8xOSwgNTozMyBQTSwgIkRhdmUgVGFodCIgPGRhdmVAdGFodC5uZXQ+ IHdyb3RlOg0KDQogICAgDQogICAgDQogICAgR3JlZyBXaGl0ZSA8Zy53aGl0ZUBDYWJsZUxhYnMu Y29tPiB3cml0ZXM6DQogICAgDQogICAgPiBPbiB0aGUgaXRlbSBiZWxvdywgSSBhbSBpbnRlbmRp bmcgdG8gZmluaXNoIHVwIGFuZCBzdWJtaXQgYSBUU1ZXRw0KICAgID4gaW5mb3JtYXRpb25hbCBk cmFmdCB0b2RheSB0aGF0IGRlc2NyaWJlcyB0aGUgKG5ldykgbWFuZGF0b3J5IHN1cHBvcnQNCiAg ICA+IGZvciBMNFMgQVFNIGFuZCBkdWFsLXF1ZXVlIHJlcXVpcmVtZW50IGluIERPQ1NJUyAzLjEg KENNICYgQ01UUykNCiAgICA+IGVxdWlwbWVudC4gVGhlIGRyYWZ0IHdpbGwgZXNzZW50aWFsbHkg YmUgYSByZWZvcm1hdCBvZiB0aGlzIGRvY3VtZW50Og0KICAgID4NCiAgICA+IGh0dHBzOi8vY2Fi bGVsYS5icy9sb3ctbGF0ZW5jeS1kb2NzaXMtdGVjaG5vbG9neS1vdmVydmlldy1mZWJydWFyeS0y MDE5DQogICAgPg0KICAgID4gVGhlc2UgcmVxdWlyZW1lbnRzIHdlcmUgYWRkZWQgaW4gRGVjZW1i ZXIsIGFuZCB3aWxsIHJvbGwgb3V0IGFzDQogICAgPiBmaXJtd2FyZSB1cGRhdGVzIHRvIGV4aXN0 aW5nIERPQ1NJUyAzLjEgZXF1aXBtZW50IChuZWFybHkgMTAwJSBvZg0KICAgID4gQ01UU3MsIGFu ZCBhIGdyb3dpbmcgZnJhY3Rpb24gb2YgQ01zKSBvdmVyIHRpbWUuDQogICAgDQogICAgSSB3YXMg dW5hd2FyZSBvZiB0aGlzIG5vdGljZSwgYW5kIGFzIEkgbm90ZSwgaXQncyBvbmx5IG1hcmNoLi4u DQogICAgDQogICAgVXNpbmcgdXAgdGhlIGxhc3QgRUNOIGJpdCBpbiB0aGlzIHdheSwgZm9yIHRo ZSBzb2xlIGJlbmVmaXQgb2YgdGhlIGNhYmxlDQogICAgaW5kdXN0cnksIHN0cmlrZXMgbWUgYXMg YSBwb29yIHN0YW5kYXJkIGZvciB0aGUgaW50ZXJuZXQuDQogICAgDQogICAgPg0KICAgID4gLUdy ZWcNCiAgICA+DQogICAgPiBGcm9tOiB0c3Z3ZyA8dHN2d2ctYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIEJvYiBCcmlzY29lDQogICAgPiA8aWV0ZkBib2JicmlzY29lLm5ldD4NCiAgICA+ IERhdGU6IE1vbmRheSwgTWFyY2ggMTEsIDIwMTkgYXQgMTA6MjkgQU0NCiAgICA+IFRvOiBEYXZl IFRhaHQgPGRhdmVAdGFodC5uZXQ+LCAidHN2d2dAaWV0Zi5vcmciIDx0c3Z3Z0BpZXRmLm9yZz4N CiAgICA+IENjOiBKb25hdGhhbiBNb3J0b24gPGNocm9tYXRpeDk5QGdtYWlsLmNvbT4NCiAgICA+ IFN1YmplY3Q6IFJlOiBbdHN2d2ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCiAgICA+ IGRyYWZ0LW1vcnRvbi10YWh0LXRzdndnLXNjZS0wMC50eHQNCiAgICA+DQogICAgPiBMNFMgaXMg ZmFyIGZyb20gZGVhZC4gSXQncyBtZXJlbHkgYmVlbiB3b3JraW5nIGRpZmZlcmVudGx5IGZyb20g aG93DQogICAgPiB5b3UncmUgdXNlZCB0by4gVGhvc2Ugd29ya2luZyBvbiBhbiBMNFMgQVFNIChh dCBsZWFzdCB0aG9zZSBpbiB0aGUNCiAgICA+IGNhYmxlIGluZHVzdHJ5KSBoYWQgdG8gaGF2ZSBh IHByaXZhdGUgV0cgZm9yIHRoZSBsYXN0IH4xOCBtb250aHMsIGJ1dA0KICAgID4gbm93IHdlJ3Jl IGFsbG93ZWQgdG8gcHVibGlzaCBhbmQgdGFsayBvcGVubHkgYWdhaW4uIA0KICAgIA0KDQo= From nobody Mon Mar 11 16:53:56 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DDA13122A for ; Mon, 11 Mar 2019 16:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkZJpWOt2bnU for ; Mon, 11 Mar 2019 16:53:45 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B71E13127F for ; Mon, 11 Mar 2019 16:53:41 -0700 (PDT) Received: by bugle.employees.org (Postfix, from userid 1736) id DC1DDFECC037; Mon, 11 Mar 2019 23:53:40 +0000 (UTC) Date: Tue, 12 Mar 2019 00:53:40 +0100 From: Derek Fawcus To: tsvwg Message-ID: <20190311235340.GA55313@bugle.employees.org> References: <155234457516.23066.2902218433537151460.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:53:55 -0000 On Mon, Mar 11, 2019 at 03:55:44PM -0700, Tom Herbert wrote: > Hello, > > I've posted a draft that describe a common header to use in UDP > surplus space (the bytes between the end of UDP payload and the end of > the IP packet). The header allows disambiguation between uses of the > UDP slack space, including possible non-standard uses via a required > checksum. The header includes a type field to allow different uses of > the surplus space. UDP options would be one use case, but the format > is extensible to allow other uses. Notes from a quick glance. The max length of 1020 would limit the current LITE+FRAG scheme for sending a max ethernet (1500 byte) FRAG encoded mesage, but maybe not a problem? How would the CCO issue be addressed? Especially so when multiple users of the surplus space are present, since they'd have to be co-ordinated. It does open up one other intersting posibility for the LITE alone case, namely that could be its own surplus user (outside of UDP options), encoded as the last surplus header: [ Type=LITE | Length = 1 | Checksum = fixed value ] and then the rest of the bytes in the following surplus area would comprise the LITE data. Obviously this would suffer from the same deployment issues we've been discussing wrt UDP-Options encoded LITE alone, but that might just be something we'd have to live with. It would mean that the LITE+FRAG case in UDP options could probably be simplified to be one option alone. DF From nobody Mon Mar 11 16:55:41 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27B7131131 for ; Mon, 11 Mar 2019 16:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MINRa8Mw2CFo for ; Mon, 11 Mar 2019 16:55:38 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93884129A87 for ; Mon, 11 Mar 2019 16:55:38 -0700 (PDT) Received: from dancer.taht.net (c-73-162-29-198.hsd1.ca.comcast.net [73.162.29.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 54C2A2200A; Mon, 11 Mar 2019 23:55:35 +0000 (UTC) From: Dave Taht To: Greg White Cc: Bob Briscoe , "tsvwg\@ietf.org" , Jonathan Morton References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> <63DC5E45-449A-4008-9041-95A3C7216FF4@cablelabs.com> <87h8c9m1fk.fsf@taht.net> <2CFCED24-68E9-4430-95FC-380E415D82B3@cablelabs.com> Date: Mon, 11 Mar 2019 16:55:33 -0700 In-Reply-To: <2CFCED24-68E9-4430-95FC-380E415D82B3@cablelabs.com> (Greg White's message of "Mon, 11 Mar 2019 23:49:59 +0000") Message-ID: <87bm2hm0ei.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:55:40 -0000 Greg White writes: > I'm not sure how you misinterpreted L4S as being "for the sole benefit > of the cable industry". It is a standards-track draft here at IETF. > From what I understand, multiple network technologies are in the > process of implementing it. None have been public about it until now. Publically, judging from the traffic on the ietf mailing lists, it appeared to have died. It wasn't until January or so that activity picked up.=20 we were public about our separate wg when we formed it back in august. The first output of that we just submitted as this draft, and there is code and data landing for public review now. Our charter is here: https://www.bufferbloat.net/projects/ecn-sane/wiki/ We looked at a lot more things than just tcp along the way. > > -Greg > > > =EF=BB=BFOn 3/11/19, 5:33 PM, "Dave Taht" wrote: > >=20=20=20=20=20 >=20=20=20=20=20 > Greg White writes: >=20=20=20=20=20 > > On the item below, I am intending to finish up and submit a TSVWG > > informational draft today that describes the (new) mandatory support > > for L4S AQM and dual-queue requirement in DOCSIS 3.1 (CM & CMTS) > > equipment. The draft will essentially be a reformat of this documen= t: > > > > https://cablela.bs/low-latency-docsis-technology-overview-february-= 2019 > > > > These requirements were added in December, and will roll out as > > firmware updates to existing DOCSIS 3.1 equipment (nearly 100% of > > CMTSs, and a growing fraction of CMs) over time. >=20=20=20=20=20 > I was unaware of this notice, and as I note, it's only march... >=20=20=20=20=20 > Using up the last ECN bit in this way, for the sole benefit of the ca= ble > industry, strikes me as a poor standard for the internet. >=20=20=20=20=20 > > > > -Greg > > > > From: tsvwg on behalf of Bob Briscoe > > > > Date: Monday, March 11, 2019 at 10:29 AM > > To: Dave Taht , "tsvwg@ietf.org" > > Cc: Jonathan Morton > > Subject: Re: [tsvwg] New Version Notification for > > draft-morton-taht-tsvwg-sce-00.txt > > > > L4S is far from dead. It's merely been working differently from how > > you're used to. Those working on an L4S AQM (at least those in the > > cable industry) had to have a private WG for the last ~18 months, b= ut > > now we're allowed to publish and talk openly again.=20 >=20=20=20=20=20 From nobody Mon Mar 11 17:01:36 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1BC13124B; Mon, 11 Mar 2019 17:01:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <155234888454.23211.14096201623514072643@ietfa.amsl.com> Date: Mon, 11 Mar 2019 17:01:24 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 00:01:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay (L4S) Authors : Koen De Schepper Bob Briscoe Filename : draft-ietf-tsvwg-ecn-l4s-id-06.txt Pages : 40 Date : 2019-03-11 Abstract: This specification defines the identifier to be used on IP packets for a new network service called low latency, low loss and scalable throughput (L4S). It is similar to the original (or 'Classic') Explicit Congestion Notification (ECN). 'Classic' ECN marking was required to be equivalent to a drop, both when applied in the network and when responded to by a transport. Unlike 'Classic' ECN marking, for packets carrying the L4S identifier, the network applies marking more immediately and more aggressively than drop, and the transport response to each mark is reduced and smoothed relative to that for drop. The two changes counterbalance each other so that the throughput of an L4S flow will be roughly the same as a 'Classic' flow under the same conditions. However, the much more frequent control signals and the finer responses to them result in ultra-low queuing delay without compromising link utilization, and low delay is maintained during high load. Examples of new active queue management (AQM) marking algorithms and examples of new transports (whether TCP- like or real-time) are specified separately. The new L4S identifier is the key piece that enables them to interwork and distinguishes them from 'Classic' traffic. It gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off, but it can be prevented from degrading the ultra-low delay and loss of the new scalable transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-06 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-l4s-id-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 17:02:01 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D466B131253 for ; Mon, 11 Mar 2019 17:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztAQW4WAkM1X for ; Mon, 11 Mar 2019 17:01:49 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73BAA13120C for ; Mon, 11 Mar 2019 17:01:49 -0700 (PDT) Received: by bugle.employees.org (Postfix, from userid 1736) id 00CD4FECC038; Tue, 12 Mar 2019 00:01:48 +0000 (UTC) Date: Tue, 12 Mar 2019 01:01:48 +0100 From: Derek Fawcus To: tsvwg Message-ID: <20190312000148.GB55313@bugle.employees.org> References: <155234457516.23066.2902218433537151460.idtracker@ietfa.amsl.com> <20190311235340.GA55313@bugle.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190311235340.GA55313@bugle.employees.org> User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 00:01:56 -0000 On Tue, Mar 12, 2019 at 12:53:40AM +0100, Derek Fawcus wrote: > > It does open up one other intersting posibility for the LITE alone > case, namely that could be its own surplus user (outside of UDP options), > encoded as the last surplus header: > > [ Type=LITE | Length = 1 | Checksum = fixed value ] OK - that would be length = 0. I misread. DF From nobody Mon Mar 11 17:08:30 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA2D13127A for ; Mon, 11 Mar 2019 17:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 ZI7dD3OH6FWg for ; Mon, 11 Mar 2019 17:08:21 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 9ED0B13124F for ; Mon, 11 Mar 2019 17:08:19 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2C01mYl011256; Tue, 12 Mar 2019 00:08:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=lHDbv1Y0XYNOdlh6V3Yf75hbxa5Mm4exU7GqgVSsVCQ=; b=NF3Hnd5bp+BnUDerCoUv0DwzZa0TQroR+pp2kaeQweW4AK6aHSvlTh1vjjQg7X0Vyddd QRbaN0bOTVa7AjiegbBuPwUfs+1CTvbC/IbaTTu0g4fc+CIjQjTxX9T3bOVEXKIgK76J 3eLTwdN2GnvKOnc5UepsM84gHGyae4tTzIm/7t3yvWHO5efS/Wd5U7Mg+e1nHO4NZebB QKCSTRyIoWq+U64QzZ5y/VqbOAsMtIjmTSjufFKfUR0UVVSZxFJ480wJqylxB1S485X+ dOJvG4yadvbrZiDxYyF4wkRlPlr985gRLITQxaf6/mfwVz4WU2AvDjz6DistjojB8ZRk PA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2r5x9v8q1b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Mar 2019 00:08:16 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2C02P9S018893; Mon, 11 Mar 2019 20:08:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2r49q0cj5v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Mar 2019 20:08:15 -0400 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Mar 2019 19:08:14 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.003; Mon, 11 Mar 2019 19:08:14 -0500 From: "Holland, Jake" To: Greg White , Dave Taht CC: Jonathan Morton , "tsvwg@ietf.org" Thread-Topic: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt Thread-Index: AQHU16ge7T0c1qojAUWcXtNdLokpK6YG85gAgAANFACAABW0MoAAWGeA//+PvgA= Date: Tue, 12 Mar 2019 00:08:12 +0000 Message-ID: <5A300B19-0D97-4FE4-BAAA-FACA9A4327F8@akamai.com> References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> <63DC5E45-449A-4008-9041-95A3C7216FF4@cablelabs.com> <87h8c9m1fk.fsf@taht.net> <2CFCED24-68E9-4430-95FC-380E415D82B3@cablelabs.com> In-Reply-To: <2CFCED24-68E9-4430-95FC-380E415D82B3@cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.228] Content-Type: text/plain; charset="utf-8" Content-ID: <4C4012823D6E4F429BD0F77FA385E9F7@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110164 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110164 Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 00:08:29 -0000 T24gMjAxOS0wMy0xMSwgMTY6NTAsICJHcmVnIFdoaXRlIiA8Zy53aGl0ZUBDYWJsZUxhYnMuY29t PiB3cm90ZToNCj4gSXQgaXMgYSBzdGFuZGFyZHMtdHJhY2sgZHJhZnQgaGVyZSBhdCBJRVRGDQoN CkkgdGhvdWdodCB0aGUgTDRTIGRyYWZ0cyB3ZXJlIGV4cGVyaW1lbnRhbCwgbm90IHN0YW5kYXJk cy10cmFjazoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ct YXFtLWR1YWxxLWNvdXBsZWQtMDgNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXRzdndnLWVjbi1sNHMtaWQtMDQNCg0KV2FzIHRoZXJlIG9uZSB0aGF0J3Mgc3RhbmRhcmRz IHRyYWNrPw0KDQpUaGFua3MgYW5kIHJlZ2FyZHMsDQpKYWtlDQoNCiAgICANCiAgICAtR3JlZw0K ICAgIA0KICAgIA0KICAgIE9uIDMvMTEvMTksIDU6MzMgUE0sICJEYXZlIFRhaHQiIDxkYXZlQHRh aHQubmV0PiB3cm90ZToNCiAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICBHcmVnIFdo aXRlIDxnLndoaXRlQENhYmxlTGFicy5jb20+IHdyaXRlczoNCiAgICAgICAgDQogICAgICAgID4g T24gdGhlIGl0ZW0gYmVsb3csIEkgYW0gaW50ZW5kaW5nIHRvIGZpbmlzaCB1cCBhbmQgc3VibWl0 IGEgVFNWV0cNCiAgICAgICAgPiBpbmZvcm1hdGlvbmFsIGRyYWZ0IHRvZGF5IHRoYXQgZGVzY3Jp YmVzIHRoZSAobmV3KSBtYW5kYXRvcnkgc3VwcG9ydA0KICAgICAgICA+IGZvciBMNFMgQVFNIGFu ZCBkdWFsLXF1ZXVlIHJlcXVpcmVtZW50IGluIERPQ1NJUyAzLjEgKENNICYgQ01UUykNCiAgICAg ICAgPiBlcXVpcG1lbnQuIFRoZSBkcmFmdCB3aWxsIGVzc2VudGlhbGx5IGJlIGEgcmVmb3JtYXQg b2YgdGhpcyBkb2N1bWVudDoNCiAgICAgICAgPg0KICAgICAgICA+IGh0dHBzOi8vY2FibGVsYS5i cy9sb3ctbGF0ZW5jeS1kb2NzaXMtdGVjaG5vbG9neS1vdmVydmlldy1mZWJydWFyeS0yMDE5DQog ICAgICAgID4NCiAgICAgICAgPiBUaGVzZSByZXF1aXJlbWVudHMgd2VyZSBhZGRlZCBpbiBEZWNl bWJlciwgYW5kIHdpbGwgcm9sbCBvdXQgYXMNCiAgICAgICAgPiBmaXJtd2FyZSB1cGRhdGVzIHRv IGV4aXN0aW5nIERPQ1NJUyAzLjEgZXF1aXBtZW50IChuZWFybHkgMTAwJSBvZg0KICAgICAgICA+ IENNVFNzLCBhbmQgYSBncm93aW5nIGZyYWN0aW9uIG9mIENNcykgb3ZlciB0aW1lLg0KICAgICAg ICANCiAgICAgICAgSSB3YXMgdW5hd2FyZSBvZiB0aGlzIG5vdGljZSwgYW5kIGFzIEkgbm90ZSwg aXQncyBvbmx5IG1hcmNoLi4uDQogICAgICAgIA0KICAgICAgICBVc2luZyB1cCB0aGUgbGFzdCBF Q04gYml0IGluIHRoaXMgd2F5LCBmb3IgdGhlIHNvbGUgYmVuZWZpdCBvZiB0aGUgY2FibGUNCiAg ICAgICAgaW5kdXN0cnksIHN0cmlrZXMgbWUgYXMgYSBwb29yIHN0YW5kYXJkIGZvciB0aGUgaW50 ZXJuZXQuDQogICAgICAgIA0KICAgICAgICA+DQogICAgICAgID4gLUdyZWcNCiAgICAgICAgPg0K ICAgICAgICA+IEZyb206IHRzdndnIDx0c3Z3Zy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg b2YgQm9iIEJyaXNjb2UNCiAgICAgICAgPiA8aWV0ZkBib2JicmlzY29lLm5ldD4NCiAgICAgICAg PiBEYXRlOiBNb25kYXksIE1hcmNoIDExLCAyMDE5IGF0IDEwOjI5IEFNDQogICAgICAgID4gVG86 IERhdmUgVGFodCA8ZGF2ZUB0YWh0Lm5ldD4sICJ0c3Z3Z0BpZXRmLm9yZyIgPHRzdndnQGlldGYu b3JnPg0KICAgICAgICA+IENjOiBKb25hdGhhbiBNb3J0b24gPGNocm9tYXRpeDk5QGdtYWlsLmNv bT4NCiAgICAgICAgPiBTdWJqZWN0OiBSZTogW3RzdndnXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQogICAgICAgID4gZHJhZnQtbW9ydG9uLXRhaHQtdHN2d2ctc2NlLTAwLnR4dA0KICAg ICAgICA+DQogICAgICAgID4gTDRTIGlzIGZhciBmcm9tIGRlYWQuIEl0J3MgbWVyZWx5IGJlZW4g d29ya2luZyBkaWZmZXJlbnRseSBmcm9tIGhvdw0KICAgICAgICA+IHlvdSdyZSB1c2VkIHRvLiBU aG9zZSB3b3JraW5nIG9uIGFuIEw0UyBBUU0gKGF0IGxlYXN0IHRob3NlIGluIHRoZQ0KICAgICAg ICA+IGNhYmxlIGluZHVzdHJ5KSBoYWQgdG8gaGF2ZSBhIHByaXZhdGUgV0cgZm9yIHRoZSBsYXN0 IH4xOCBtb250aHMsIGJ1dA0KICAgICAgICA+IG5vdyB3ZSdyZSBhbGxvd2VkIHRvIHB1Ymxpc2gg YW5kIHRhbGsgb3Blbmx5IGFnYWluLiANCiAgICAgICAgDQogICAgDQogICAgDQoNCg== From nobody Mon Mar 11 17:08:57 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8A013126C for ; Mon, 11 Mar 2019 17:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09RYs9jOgW_M for ; Mon, 11 Mar 2019 17:08:48 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D345131293 for ; Mon, 11 Mar 2019 17:08:48 -0700 (PDT) Received: by bugle.employees.org (Postfix, from userid 1736) id 68F56FECC038; Tue, 12 Mar 2019 00:08:47 +0000 (UTC) Date: Tue, 12 Mar 2019 01:08:47 +0100 From: Derek Fawcus To: tsvwg Message-ID: <20190312000847.GA66373@bugle.employees.org> References: <155234457516.23066.2902218433537151460.idtracker@ietfa.amsl.com> <20190311235340.GA55313@bugle.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190311235340.GA55313@bugle.employees.org> User-Agent: Mutt/1.11.1 (2018-12-01) Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 00:08:56 -0000 On Tue, Mar 12, 2019 at 12:53:40AM +0100, Derek Fawcus wrote: > > How would the CCO issue be addressed? > Especially so when multiple users of the surplus space are present, > since they'd have to be co-ordinated. Hmm - is this addressed by the fact that each surplus user would checksums to zero? If so, then combining this with a re-cast UDP-Options may well make things simpler. DF From nobody Mon Mar 11 17:12:38 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A67131189 for ; Mon, 11 Mar 2019 17:12:37 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 k2lKFGr2WW2V for ; Mon, 11 Mar 2019 17:12:35 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 485381310C6 for ; Mon, 11 Mar 2019 17:12:35 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id z17so690763qtn.4 for ; Mon, 11 Mar 2019 17:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MrHOAvavaiJgafVz2gqAWS8pyPYJ4JGijXrn2MZ8FXM=; b=Sr3cV0kyPxzxyVgosK4Pv7LQO5g/kMkDioq+e4EzzLbmo9c4cFP96/vZGy444mSW6X UzhiKFNJDUu6q5SPNTf8ItYSxwlNGN/dmTZa2vwbRFtu0y/TVY8VYb39EJCBLU1LEJn6 WUpwUvA+hUs/bljVTK1/xI0OzNQiwpbj6W6L5P/W59SnWZsrQX0wiIPEISH8J1LVglRN irZY86qerQY5kdn4+nn2mnjjuPiI1KLIDAQ8N+a+xgS93CINkwn0bQP9Xyz4XsYXVRym L6AACiDgFgNMn5to6ejfrLpRsOWe/3V0hDDSj5rdkjbrM5Rt/dIH6HFuOWo+Zw4Nv9lE VDpw== 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=MrHOAvavaiJgafVz2gqAWS8pyPYJ4JGijXrn2MZ8FXM=; b=R2d2jot/I+g2v7GFVsV5KscnW9NyGi/2jfOoaYHmd3sMbiFUF0pr80ucOI77D1yixw 1SdEeKDgaBdw27qEjRzhqBku0XScqSQ0X8Pjjuj4zOsLMHjjP7B1tXr+aDeusuTMpFH1 EH3MV8yaiTju9oxv3ZuBXA66Zsptp3tg5DzK75T7N/px0qXV6XhtNPhgCpW5onlrWxlp p7OkBbFibWVhRXrrfl04SywU/MT8uXrG2R0Sk0CFgcT69VMOxO4B2fRBDN33Cgqc4vW4 SIlm19pbAkLx2LCLhvWh6WmwaSkNS6dmeryFdxNkRlSgdDZ3+mPiUo7mB3Bw4HxjMLUi Zgkg== X-Gm-Message-State: APjAAAWQTsxAdj76ajYbKE4EZ6cM/8f1hd0PSINLBxNFmTr/J9CnVeF7 7KZHctrLU88V0Im/pBplU3DgAlmSRIi5fBbdqR60FGjW X-Google-Smtp-Source: APXvYqwuVQhsl8bYEvxHwjcycPvlU9OAHE6WAhtHUCF32DzuIwA8Kzl6PGPFoHuffc3em0w3L0nJSPi20BKqr81ySrw= X-Received: by 2002:a0c:9681:: with SMTP id a1mr28476260qvd.72.1552349554267; Mon, 11 Mar 2019 17:12:34 -0700 (PDT) MIME-Version: 1.0 References: <155234457516.23066.2902218433537151460.idtracker@ietfa.amsl.com> <20190311235340.GA55313@bugle.employees.org> In-Reply-To: <20190311235340.GA55313@bugle.employees.org> From: Tom Herbert Date: Mon, 11 Mar 2019 17:12:22 -0700 Message-ID: To: Derek Fawcus Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 00:12:37 -0000 On Mon, Mar 11, 2019 at 4:54 PM Derek Fawcus wrote: > > On Mon, Mar 11, 2019 at 03:55:44PM -0700, Tom Herbert wrote: > > Hello, > > > > I've posted a draft that describe a common header to use in UDP > > surplus space (the bytes between the end of UDP payload and the end of > > the IP packet). The header allows disambiguation between uses of the > > UDP slack space, including possible non-standard uses via a required > > checksum. The header includes a type field to allow different uses of > > the surplus space. UDP options would be one use case, but the format > > is extensible to allow other uses. > > Notes from a quick glance. > > The max length of 1020 would limit the current LITE+FRAG scheme for > sending a max ethernet (1500 byte) FRAG encoded mesage, but maybe > not a problem? > > How would the CCO issue be addressed? > Especially so when multiple users of the surplus space are present, > since they'd have to be co-ordinated. If I understand CCO correctly, the problem seems to be that some middle boxes incorrectly use the IP length instead of UDP length for checksum calculation. This seems to be both for the coverage of the UDP checksum as well as the length in the pseudo header. The first part is addressed since the checksum in the UDP surplus header sums to zero, so adding this to the checksum just over the UDP header and payload yields the same value. Determining that the IP length was used in the pseudo header would require an extra step. It seems like that could be done without any special options, just check the normal UDP checksum and if that fails add the checksum difference between the IP length and UDP length and see if that yields checksum zero. Tom > > It does open up one other intersting posibility for the LITE alone > case, namely that could be its own surplus user (outside of UDP options), > encoded as the last surplus header: > > [ Type=LITE | Length = 1 | Checksum = fixed value ] > > and then the rest of the bytes in the following surplus area would > comprise the LITE data. > > Obviously this would suffer from the same deployment issues we've > been discussing wrt UDP-Options encoded LITE alone, but that might > just be something we'd have to live with. > > It would mean that the LITE+FRAG case in UDP options could probably > be simplified to be one option alone. > > DF > From nobody Mon Mar 11 17:13:10 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594311310C6 for ; Mon, 11 Mar 2019 17:13:08 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 f7WevB2DMnYi for ; Mon, 11 Mar 2019 17:13:07 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 2BD7D1271FF for ; Mon, 11 Mar 2019 17:13:07 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id v20so626604qtv.12 for ; Mon, 11 Mar 2019 17:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8fWO+P26ompkNKHkoVklh7VBMr43/RrDNJzT58hyNHM=; b=eXB3npAan+XEkgbzDzV7PnbZPwBw0ks00vs/VpyiN08zi8QjgLR0jhBc6qtKsl4USH lQiXgPUaNcMrPOi4BLKk+EMlaNMop6OP5tNg5NLtF9gej5WllXysknt/x27YFCzf6EU8 vwPd6AfIYfg3BP7sUJ6KSD7NFBotanpa9X4bLjFmYn+fDXnGCEMvjgIvFuV6IpDM70t2 t/B871r//9dd6jpG7ytR+JSvzELLYdBM4odFb6KJDdysB2nMiNg2EeQi/TpKl6kCdQ5C Sv59OGhorIqHtGhceqsPz9trnHtA3rhPDfgsemxBIpL8eGkVGQJZiqQkezNyDv9gclIx 3p4g== 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=8fWO+P26ompkNKHkoVklh7VBMr43/RrDNJzT58hyNHM=; b=PHcKFV+D6X0NR8gtBzbzIIgaYNrAk7N7F99rBuvk8efw3kkL8KmsSw19eoWwoj3zJ2 cCva7ebcLPbr+IsSHWoFkJB/3cU1Lk2UHsBEQVUNIXm7kj4VcXWWzkF9fdZqdFGFKaW8 4Cx9t+RdPUU8axgSrqr8FSPQ1OsAioWOeLXnmruJ3Q7mcT6NEMss1B/J3iMP1Df+mGyf hPZKSbcuT6pf8yZf0vai6incMJQhK0tIYyFgnbkJn3k0wAutMi2GD2F9Pn4GVN0VhQyM 2UsNi/bfAMLaL8gdU6mTdYttZurytJYwVyyAC+hraoh51+o1Xc8kYVH94jK0MaS5aBie Jhcg== X-Gm-Message-State: APjAAAX9Vrv8pDopwRE+ezx6gDyDgDCtzSKyB30EyDMk7kjn8I4UHqXR zIe5QqqfA4pCnkz09YesHO4Ke3RhB8fr1CZV0W34yRRY X-Google-Smtp-Source: APXvYqxeH5kjxmi4/ru0B0UVzPc0D0b3tyGdMDjpoxavKjdbVbrOlUbKFgbnlfefvgbiF+31VDbtYRk+XxxjpZe59Xg= X-Received: by 2002:ac8:4746:: with SMTP id k6mr16119050qtp.200.1552349586155; Mon, 11 Mar 2019 17:13:06 -0700 (PDT) MIME-Version: 1.0 References: <155234457516.23066.2902218433537151460.idtracker@ietfa.amsl.com> <20190311235340.GA55313@bugle.employees.org> <20190312000847.GA66373@bugle.employees.org> In-Reply-To: <20190312000847.GA66373@bugle.employees.org> From: Tom Herbert Date: Mon, 11 Mar 2019 17:12:54 -0700 Message-ID: To: Derek Fawcus Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 00:13:08 -0000 On Mon, Mar 11, 2019 at 5:09 PM Derek Fawcus wrote: > > On Tue, Mar 12, 2019 at 12:53:40AM +0100, Derek Fawcus wrote: > > > > How would the CCO issue be addressed? > > Especially so when multiple users of the surplus space are present, > > since they'd have to be co-ordinated. > > Hmm - is this addressed by the fact that each surplus user would > checksums to zero? Yep :-) > > If so, then combining this with a re-cast UDP-Options may well > make things simpler. > > DF > From nobody Mon Mar 11 17:26:11 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D612797C for ; Mon, 11 Mar 2019 17:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cFwEPHl2W7M3 for ; Mon, 11 Mar 2019 17:26:08 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 0658E1271FF for ; Mon, 11 Mar 2019 17:26:08 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id b4so649550oif.6 for ; Mon, 11 Mar 2019 17:26:07 -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=ZjuTZCxJ5M1MncHcpkQ7z7m388KI++zsyBPM/0hrb+I=; b=l8jeiZEweFhexQW9t3zcgG0kS+W23tivslwqw89jLQQwwynnZOrEwD8p7tcq0+kzvl U8/tdd7PdAq1R5k15s5szk1ujIvFnHOfoK7F/9bK1LJmaAbuIUHZxIKqfn0JhysR6VMz W8RaYhAB74hdAvjZ5jzYJo5XcjxD9qmxnB+aqLEWiruUVRowgT10CrF5tUuP5l2vBlRb Q4og3Y5bohRd89XBweEQNkkFJr/GCJSeixESydVnlN+Ns9ZWFHW6ycXsXK2p9fSDEnmC 9nK2QLgc6VRE4n+dqMqU145TYivN7kLTS6tc+Iuj6hNyg9gomd+lZuP54ZzNAyq4LmNF J1fQ== 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=ZjuTZCxJ5M1MncHcpkQ7z7m388KI++zsyBPM/0hrb+I=; b=ADKW/FEflMEDpcnUK29IMdAvj3uU0iEQf2v2H0GXYUpXz8Rve3zJUBJxKgZ+1j6PuM 6D7cp2X6+a4Dl4Hon86Q++D9jzGdE3ao1tOPb58/2yZlP/r8pLWs7uuEot84qhH2Vo7z mnvr+7CNCpHkCmfT8v9rqMYPVX0XoGSqnATG7cCC+jkhfmRJPOy5EuweaoAk49iWufbd CeupBDy7koxxmiOkdnp67zxgh7yDZhz5LC9rxjDpAJvTUYvBUHv+bMCcBxC6FTPsk2C8 qPiOiA/CTPx5cwJMuvn5udSuZYhZLxxL/qhV0o06vB9C5UYUs5CsXapVan6ED2dSeEoz 7Iew== X-Gm-Message-State: APjAAAVgiYDQCCTi9DeOPT/dcPfRMFLaTqLR0S+J2cZHppQR+Z1/OmWH aA0bsz9qSq9+pAynltc2ho8umtqy0Ofw3y85rI0= X-Google-Smtp-Source: APXvYqzvcVarAcCS5SdwuvHB0lTWmuuYIjrVYhDEUGnWPCvtjZxpt29+LjS6Yp6dr0Fo9Y5BhYR7yiXy4rI/qpZm1AE= X-Received: by 2002:aca:488e:: with SMTP id v136mr1001oia.151.1552350367057; Mon, 11 Mar 2019 17:26:07 -0700 (PDT) MIME-Version: 1.0 References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> <63DC5E45-449A-4008-9041-95A3C7216FF4@cablelabs.com> <87h8c9m1fk.fsf@taht.net> <2CFCED24-68E9-4430-95FC-380E415D82B3@cablelabs.com> In-Reply-To: <2CFCED24-68E9-4430-95FC-380E415D82B3@cablelabs.com> From: Luca Muscariello Date: Mon, 11 Mar 2019 17:25:56 -0700 Message-ID: To: Greg White Cc: Dave Taht , Jonathan Morton , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="000000000000320d0f0583dabc20" Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 00:26:11 -0000 --000000000000320d0f0583dabc20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, I'm curious about the queue protection function in the LLD document. It seems to assume that a flow table is maintained to determine if a flow has the right to enter the low latency queue. Can you give more details about that component? Or point me to a reference? Thanks Luca On Mon, Mar 11, 2019 at 4:50 PM Greg White wrote: > I'm not sure how you misinterpreted L4S as being "for the sole benefit of > the cable industry". It is a standards-track draft here at IETF. From > what I understand, multiple network technologies are in the process of > implementing it. None have been public about it until now. > > -Greg > > > =EF=BB=BFOn 3/11/19, 5:33 PM, "Dave Taht" wrote: > > > > Greg White writes: > > > On the item below, I am intending to finish up and submit a TSVWG > > informational draft today that describes the (new) mandatory suppor= t > > for L4S AQM and dual-queue requirement in DOCSIS 3.1 (CM & CMTS) > > equipment. The draft will essentially be a reformat of this documen= t: > > > > > https://cablela.bs/low-latency-docsis-technology-overview-february-2019 > > > > These requirements were added in December, and will roll out as > > firmware updates to existing DOCSIS 3.1 equipment (nearly 100% of > > CMTSs, and a growing fraction of CMs) over time. > > I was unaware of this notice, and as I note, it's only march... > > Using up the last ECN bit in this way, for the sole benefit of the > cable > industry, strikes me as a poor standard for the internet. > > > > > -Greg > > > > From: tsvwg on behalf of Bob Briscoe > > > > Date: Monday, March 11, 2019 at 10:29 AM > > To: Dave Taht , "tsvwg@ietf.org" > > Cc: Jonathan Morton > > Subject: Re: [tsvwg] New Version Notification for > > draft-morton-taht-tsvwg-sce-00.txt > > > > L4S is far from dead. It's merely been working differently from how > > you're used to. Those working on an L4S AQM (at least those in the > > cable industry) had to have a private WG for the last ~18 months, b= ut > > now we're allowed to publish and talk openly again. > > > --000000000000320d0f0583dabc20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Greg,

I'm curious about the= queue protection function in the LLD document.
It seems to assum= e that a flow table is maintained to determine if a flow=C2=A0
ha= s the right to enter the low latency queue.

Can yo= u give more details about that component? Or point me to a reference?
=

Thanks
Luca


On Mon, Mar 1= 1, 2019 at 4:50 PM Greg White <= g.white@cablelabs.com> wrote:
I'm not sure how you misinterpreted L4S as being &= quot;for the sole benefit of the cable industry".=C2=A0 It is a standa= rds-track draft here at IETF.=C2=A0 From what I understand, multiple networ= k technologies are in the process of implementing it.=C2=A0 None have been = public about it until now.

-Greg


=EF=BB=BFOn 3/11/19, 5:33 PM, "Dave Taht" <dave@taht.net> wrote:



=C2=A0 =C2=A0 Greg White <g.white@CableLabs.com> writes:

=C2=A0 =C2=A0 > On the item below, I am intending to finish up and submi= t a TSVWG
=C2=A0 =C2=A0 > informational draft today that describes the (new) manda= tory support
=C2=A0 =C2=A0 > for L4S AQM and dual-queue requirement in DOCSIS 3.1 (CM= & CMTS)
=C2=A0 =C2=A0 > equipment. The draft will essentially be a reformat of t= his document:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > https://ca= blela.bs/low-latency-docsis-technology-overview-february-2019
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > These requirements were added in December, and will roll= out as
=C2=A0 =C2=A0 > firmware updates to existing DOCSIS 3.1 equipment (nearl= y 100% of
=C2=A0 =C2=A0 > CMTSs, and a growing fraction of CMs) over time.

=C2=A0 =C2=A0 I was unaware of this notice, and as I note, it's only ma= rch...

=C2=A0 =C2=A0 Using up the last ECN bit in this way, for the sole benefit o= f the cable
=C2=A0 =C2=A0 industry, strikes me as a poor standard for the internet.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -Greg
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > From: tsvwg <tsvwg-bounces@ietf.org> on behalf of Bob Briscoe=
=C2=A0 =C2=A0 > <ietf@bobbriscoe.net>
=C2=A0 =C2=A0 > Date: Monday, March 11, 2019 at 10:29 AM
=C2=A0 =C2=A0 > To: Dave Taht <dave@taht.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
=C2=A0 =C2=A0 > Cc: Jonathan Morton <chromatix99@gmail.com>
=C2=A0 =C2=A0 > Subject: Re: [tsvwg] New Version Notification for
=C2=A0 =C2=A0 > draft-morton-taht-tsvwg-sce-00.txt
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > L4S is far from dead. It's merely been working diffe= rently from how
=C2=A0 =C2=A0 > you're used to. Those working on an L4S AQM (at leas= t those in the
=C2=A0 =C2=A0 > cable industry) had to have a private WG for the last ~1= 8 months, but
=C2=A0 =C2=A0 > now we're allowed to publish and talk openly again. =


--000000000000320d0f0583dabc20-- From nobody Mon Mar 11 17:33:17 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DF4126CAD for ; Mon, 11 Mar 2019 17:33:15 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 rVzbi4F6WLEa for ; Mon, 11 Mar 2019 17:33:13 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 2972912788D for ; Mon, 11 Mar 2019 17:33:13 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id v10so700325qtp.8 for ; Mon, 11 Mar 2019 17:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tK6ijvcAjox/meUtz35cRxglUX8Xbk7SbEAgcEFXgko=; b=DmTFmpmJYfP0CYWgXyiXixBgZr0zLjkeljv6ak1YS4vmG0JL2XW18syCCxXmGuqfCH Le/QtCKRM/G0kCZ2wSj5KZn5lAqWaBrwsEl4US3GbEKoGnr4ZmEJ+uUd+dvCKG3ruHn1 wrG72BUx8m5KkZ0/QN34qOJl5A5ES7WS5FX5nYGIhLNUcV9rekjQ7xVYVnotRYkZREYT xg2HB++DXgzKoAuD5ZW3+zO22XhxftAIAnUwrZ2fSveD1xbh2UjIDnsVG14VQZXn2NxT vPFKRpCElj3NxpDhV3maHcTPaEzvQ7PBtcXiN0w7BmDLBLgL/19a+HfIVU4UHI4ecpuv 3E1A== 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=tK6ijvcAjox/meUtz35cRxglUX8Xbk7SbEAgcEFXgko=; b=r8hMAJRyFY2Ln+/yCxPmTt+erRaIi+NK0SkaiOs4bc8wRAfk+pNaDZ2HK2dLhlyX23 xaE6QQ5uMJ99n/zCTN9VltNbVzSEnsBwB0kaLmSl3WhXmqtn9UUx9/SROkDPBfxapsap wrpjI79Wrjos1K0ZJR9LrYZwQz9L2QBZVzZlRqUE4+8X0GKCFS0vUq9uSFRi7/UtzzfR rzsbvvwO+dDTNr1lEdORtdeBiO/rQo3+FWmEKUW2oXzdgz+psqqO8iFNnEf/EiITInyv XzzIyb7ZrZQ04dstm4rfJcgmSp8GoK8eCfWY7oNMwzP5zIMOHuHbl5N/e+kNrtlnX39n Azbg== X-Gm-Message-State: APjAAAWDvatSAw/2SL94EHwdwZG+2q7DYBqguZt2pG/67ZO7kAxfOAnT hSRZmAGiLhRLTF3VbqJLitLY4H6jn/sbLApcnWOBvXQh X-Google-Smtp-Source: APXvYqw4Xa8WXKYRN09bk5zaVzl0Dx4dyHCu1P/eCk3Ov3360nKJWgWNwwEoM40ts+F0mCxw9J6um7QWR+wCVdZomz8= X-Received: by 2002:a0c:9877:: with SMTP id e52mr28458885qvd.168.1552350792264; Mon, 11 Mar 2019 17:33:12 -0700 (PDT) MIME-Version: 1.0 References: <155234457516.23066.2902218433537151460.idtracker@ietfa.amsl.com> <20190311235340.GA55313@bugle.employees.org> In-Reply-To: <20190311235340.GA55313@bugle.employees.org> From: Tom Herbert Date: Mon, 11 Mar 2019 17:33:00 -0700 Message-ID: To: Derek Fawcus Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 00:33:16 -0000 On Mon, Mar 11, 2019 at 4:54 PM Derek Fawcus wrote: > > On Mon, Mar 11, 2019 at 03:55:44PM -0700, Tom Herbert wrote: > > Hello, > > > > I've posted a draft that describe a common header to use in UDP > > surplus space (the bytes between the end of UDP payload and the end of > > the IP packet). The header allows disambiguation between uses of the > > UDP slack space, including possible non-standard uses via a required > > checksum. The header includes a type field to allow different uses of > > the surplus space. UDP options would be one use case, but the format > > is extensible to allow other uses. > > Notes from a quick glance. > > The max length of 1020 would limit the current LITE+FRAG scheme for > sending a max ethernet (1500 byte) FRAG encoded mesage, but maybe > not a problem? > I don't think the intent of the header would be to cover payload data, just control data like options. That being said, there might be value in having a checksum somewhere else in LITE+FRAG that would cover all the payload. It's possible that we can get checksum offload to work with that (we pretty much lost the value of it when UDP length is set to 8 for LITE). Tom > How would the CCO issue be addressed? > Especially so when multiple users of the surplus space are present, > since they'd have to be co-ordinated. > > It does open up one other intersting posibility for the LITE alone > case, namely that could be its own surplus user (outside of UDP options), > encoded as the last surplus header: > > [ Type=LITE | Length = 1 | Checksum = fixed value ] > > and then the rest of the bytes in the following surplus area would > comprise the LITE data. > > Obviously this would suffer from the same deployment issues we've > been discussing wrt UDP-Options encoded LITE alone, but that might > just be something we'd have to live with. > > It would mean that the LITE+FRAG case in UDP options could probably > be simplified to be one option alone. > > DF > From nobody Mon Mar 11 18:35:23 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBB012950A for ; Mon, 11 Mar 2019 18:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 VtayQqkB1uGX for ; Mon, 11 Mar 2019 18:35:20 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C9FBD128CF2 for ; Mon, 11 Mar 2019 18:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rbs+xWSyuq/vp44tU62DZfY7HsLSP4OjgLHXiIyMr9g=; b=Bmv+9YA+SblcWSWT+ZxA5dlpZ DlXQXHkOIADEGyUg7oXSj1ljFRVCWXaxuat4X7BP0ELHgoAzAZCE88o+r40gy/fG2HMpcRltvxS8t TRf9gaTCvotu+/M3ykoQ/oyl6siZVr/VsCO2r9HWfl0uZgymQDOanDrdJtPOXWUOtYFlRvbstN7Br S60UwbXMqaQQQ5fHAYVFFpCAWPs0IUC2wZXLFZCJM6qqEN03tKMNxndeuACS3vUDy+r9tTdaXFVGa kozXbF0t9V2VXvDjyxju1rC6KVq2r155Y2ZyoPIIJzatK+ms4Mhrn+5bisNr2tvAsNwuADEd5g6pP egQtB718A==; Received: from [65.222.224.130] (port=19238 helo=[172.20.15.93]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3WK6-002MOJ-Rf; Mon, 11 Mar 2019 21:35:19 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16D57) In-Reply-To: Date: Mon, 11 Mar 2019 18:35:17 -0700 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <020B3514-1D5D-4850-A330-91222C430025@strayalpha.com> References: <155234457516.23066.2902218433537151460.idtracker@ietfa.amsl.com> To: Tom Herbert X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 01:35:23 -0000 We already have more than sufficient TLV space in the current option definit= ion to allow for other uses - or even other uses with their own sub-definiti= ons - of the slack space. I.e., if this is the direction we want to go, we can trivially go there with= one KIND in the current system. Joe > On Mar 11, 2019, at 3:55 PM, Tom Herbert wrote: >=20 > Hello, >=20 > I've posted a draft that describe a common header to use in UDP > surplus space (the bytes between the end of UDP payload and the end of > the IP packet). The header allows disambiguation between uses of the > UDP slack space, including possible non-standard uses via a required > checksum. The header includes a type field to allow different uses of > the surplus space. UDP options would be one use case, but the format > is extensible to allow other uses. >=20 > Tom >=20 > ---------- Forwarded message --------- > From: > Date: Mon, Mar 11, 2019 at 3:49 PM > Subject: New Version Notification for draft-herbert-udp-space-hdr-00.txt > To: Tom Herbert >=20 >=20 >=20 > A new version of I-D, draft-herbert-udp-space-hdr-00.txt > has been successfully submitted by Tom Herbert and posted to the > IETF repository. >=20 > Name: draft-herbert-udp-space-hdr > Revision: 00 > Title: UDP Surplus Space Header > Document date: 2019-03-11 > Group: Individual Submission > Pages: 7 > URL: > https://www.ietf.org/internet-drafts/draft-herbert-udp-space-hdr-00.txt > Status: https://datatracker.ietf.org/doc/draft-herbert-udp-space-h= dr/ > Htmlized: https://tools.ietf.org/html/draft-herbert-udp-space-hdr-00= > Htmlized: > https://datatracker.ietf.org/doc/html/draft-herbert-udp-space-hdr >=20 >=20 > Abstract: > This draft defines a header for surplus space in UDP. The UDP surplus > space is bytes between the end of the UDP payload and the end of the > IP packet. The purpose of the header is to disambiguate uses of the > surplus space. The UDP surplus space header includes a type, length, > and checksum field that covers the space. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Mon Mar 11 18:41:53 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC9A12AF84 for ; Mon, 11 Mar 2019 18:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 1pI1ELF06Kph for ; Mon, 11 Mar 2019 18:41:50 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 00A5512AF7D for ; Mon, 11 Mar 2019 18:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5mM7NhD1TnI2g4+25bhBPzmdyXDb9TbbOo1xftuB6/c=; b=jb+9ohs91iPBSmLt3uMlgVRVm ieamfeIHjjIVDodKAF6DuRWrZ95JR7/gTtwWnsE8Z+fOUErIjjocaxIykSB2mD6EEO3NyGOj0/An9 4tD1r1bBDNDru/DX3P/HUtRESRBtXOW7YAWlufpPU1F6Iqf8NOv99CtTQH0/aOQ5rIcg4tYE94OkB PkkUhCycwF5obdCz64zskswurYDscKrFxV8R2Wc4aYNRrjVRtMiFJw4LIHZbjGExNl4/BpQ02J2cz d5Jsf+MS0ju++qhapnVNdFW7cTNXPHISM4M80NUhWE+guiBhfOvEApTzmDWrvcnCyT6r96e0vB/bL bzXD5M9QQ==; Received: from [65.222.224.130] (port=25287 helo=[172.20.15.93]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3WQM-002UGw-Az; Mon, 11 Mar 2019 21:41:48 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16D57) In-Reply-To: <20190311221839.GA92478@bugle.employees.org> Date: Mon, 11 Mar 2019 18:41:45 -0700 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <134F56B0-D4D2-4159-8268-2A9CDB9DD0CC@strayalpha.com> References: <20190311221839.GA92478@bugle.employees.org> To: Derek Fawcus X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 01:41:52 -0000 > On Mar 11, 2019, at 3:18 PM, Derek Fawcus wrote: >=20 > The only use I could see for leaving surplus for non option use > would be in the case of there being an option indicating > 'the rest of the surplus is X', for some X. >=20 > So really what we lose is the ability to have an option of more > than 255 bytes We can easily declare one final option that is =E2=80=9Cremainder=E2=80=9D. Note that comes with some caveats: - it wouldn=E2=80=99t have a length; like NOP, EOL, and OCS, it would just b= e a flag. - it would not be defined as being included in the OCS (if it were, it would= be a conventional option IMO), which means any use of that area would need t= o consider a checksum area that can be used like CCO (NOTE - I=E2=80=99m not= suggesting including that area by default; the CCO trick is a fix for a pot= hole, but we should not be designing every mechanism to REQUIRE compensation= for potholes that ought to be fixed) And yes, this (IMO) correctly inverts Tom Herbert=E2=80=99s proposal; it lea= ves the checksums as first-class and =E2=80=9Cother=E2=80=9D trailer uses as= second. Joe= From nobody Mon Mar 11 18:43:06 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3758512AF83 for ; Mon, 11 Mar 2019 18:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Fc4RMOuDDMbt for ; Mon, 11 Mar 2019 18:43:04 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 6FBEE12AF7D for ; Mon, 11 Mar 2019 18:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VdkCKFLCACdAaBXgYOIcnidFED++noF2rTl2EldET18=; b=MHOePfhoiQwQfBU1ijWetLAMp z/uzfw0clJLoCy5vXPALBMnPno5N8o1m12iWKkGpBOjnJTjW9LO7JNQzz7WZpU87Yfim/7wdgFCMI Qivo9369dBPdX6Ayqax5qAU/aukN6FGHghNQH84Lwlp9+DDpUSCg+6JGdGuKXo8PLCjRRzzzI2B3b CrsUcjqu1tVXm/mPyhajxV0DAHYRvrozixyfKpK38jBfuiNrwrChUaFmEz83hsj65d3XIjBaeUlMR HpSGVWwsBFKOQkIU4adLCjj/P0GY1d2QevY49Pvva33t96tyhT2HzuwYTfDvb3PPbvkdWCRvgB3aC 0LacYR03A==; Received: from [65.222.224.130] (port=50923 helo=[172.20.15.93]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3WRb-002WP5-EP; Mon, 11 Mar 2019 21:43:04 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16D57) In-Reply-To: <20190311232822.GA31999@bugle.employees.org> Date: Mon, 11 Mar 2019 18:43:02 -0700 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190311221839.GA92478@bugle.employees.org> <20190311232822.GA31999@bugle.employees.org> To: Derek Fawcus X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] LITE+FRAG UDP CS=0 (was Re: OCS option in draft-ietf-tsvwg-udp-options-07) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 01:43:05 -0000 FYI - all of the stuff below was considered when designing LITE+FRAG and sug= gesting the reassembled packet had its own reassembly checksum - that did NO= T include the pseudo header.=20 I.e., IMO, the LITE+FRAG mechanism we have already does basically all we CAN= do. > On Mar 11, 2019, at 4:28 PM, Derek Fawcus wrote: >=20 >> On Mon, Mar 11, 2019 at 11:18:39PM +0100, Derek Fawcus wrote: >>=20 >> Actually, my original thought here (which I then culled), was to have ano= ther >> option, or ACS. That other option would encode the current style of chec= ksum, >> so for concerns about CPU cost of using CRC, we could mitigate it. >>=20 >> What I had in mind was an option containing two 16 bit fields, one would >> encode the partial-checksum for the pseudo-header as the originator sent >> it, the other the partial-checksum for the original UDP payload. >>=20 >> e.g.: [ Type =3D Frag-Chks | Len | part-phdr-chk | part-data-chk ] >>=20 >> That way the receiver can recover from any NAT mangling of the packet whi= ch >> would otherwise mess with the checksum calculation. >>=20 >> i.e. for the UDP portion, assuming the packet was encoded with UDP CS=3D0= >>=20 >> 1. Calculate partial checksum for pseudo-header as received >> 2. Compare to option part-phdr-chk >> 2a. If equal verify UDP data against part-data-chk >> 2b. If differ verify UDP data against part-data-chk + (part-phdr-chk - p= hdr-chk) >=20 > It might help to explain my line of reasoning here.. >=20 > My first idea for using UDP CS=3D0 for LITE+FRAG was simply to move > the original UDP CS in to an option. >=20 > i.e. the host stack would operate as normal, building its UDP header. > Then during building the options area, it would copy the > UDP CS in to an option (call it the Moved Checksum - MCS), > and zero the CS in the UDP header. >=20 > So we end up with something like: >=20 > [Kind=3DMCS|Len=3D4|16 bit checksum] >=20 > Then I realised this would be broken by NATs. >=20 > Hence concluding one would have to also carry the partial > checksum for the original pseudo-header > (i.e. src-ip/dst-ip/src-port/dst-port/proto) such that > NAT manipulations can be compensated for: >=20 > [Kind=3DMCS|Len=3D6|16 bit part-phdr-chk|16 bit original-chk] >=20 > So the processing on the TX side to generate that is no > more costly, the RX side would have a bit more work. >=20 > Conceptually generating: >=20 > new-chk =3D original-chk - (part-phdr-chk - rx-phdr-chk) >=20 > Then writing that over the UDP CS field, before passing the > packet in to the original receive / validate routine. >=20 > Sending two partial checksums is just another way of achieving > the same effect. Maybe the moved version is clearer? >=20 > Since we know that this checksum is for the pseudo-header > and UDP header alone, with len=3D0 and no carried data; > I'm just wondering now if that can be improved? >=20 > DF >=20 From nobody Mon Mar 11 18:49:14 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DDE12D4E9 for ; Mon, 11 Mar 2019 18:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 JMDJ_5yyYH15 for ; Mon, 11 Mar 2019 18:49:11 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D0D6612B003 for ; Mon, 11 Mar 2019 18:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KrWnN+K49AruF9Yj32biPikwCGmLNJ7mH4oxKGS8cq0=; b=P4tBIDEjTGqwQyAN/ixwGt0is w4oTmNyIsdJWRSLqskgP07PYZ2fb5bgSuAD/RjOWrCTiYJkGt6wc0wU5GIZ09vReM/tU13qV2GThM 7yVSy5PrKcPuDkZcKIHWNGngodLCR6F721ShThE/j0jY3gH6lWhAoQQ8IcdkEe/46ufqmQIX1tm9Y MnI8VTTikasqLrng2OY88eBld0Kpx8j0ZYVWOqLWuO7IBp9LlYHfi1IGzPSX4//hm4F5iW2F9GRxI cRkWZcUhvGvjYQ2eoy6r1hXD8FZ5TZBR9QCtwrDUrhX6BI0VeNTIvZY4pM1x+NHyxdwWuKTQTTMLN EMnb4BRCA==; Received: from [65.222.224.130] (port=64123 helo=[172.20.15.93]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3WXW-002dAY-Nf; Mon, 11 Mar 2019 21:49:11 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16D57) In-Reply-To: Date: Mon, 11 Mar 2019 18:49:09 -0700 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Herbert X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 01:49:13 -0000 On Mar 11, 2019, at 12:56 PM, Tom Herbert wrote: >> =46rom the draft: >=20 > "The primary purpose of OCS is to detect non-standard (i.e., > non-option) uses of the options area". >=20 > Given that the checksum is optional, I don't see how this works to > detect non-standard use of the checksum area. For instance, if some > random garbage bytes are in the option area then the only way the > non-standard use is detected is if by chance the type for OCS happens > to appear in the data and is parsed as being an OCS option. Of course > that's exceedingly unlikely to happen, so garbage data is likely to be > proessed as options. A receiver that cares can require OCS, as has already been noted several tim= es (I can check in the next rev that this is mentioned in the text). > As I mentioned previously, UDP options space should start with a fixed > size header that includes a two byte checksum. This will eliminate any > ambiguity and solves other problems (like the corrupted OCS type field > problem), That just forces senders to use OCS, which wastes space when it=E2=80=99s no= t needed or desired (or the space is needed for other purposes). It also for= ces a particular alignment that may not be desired. Joe= From nobody Mon Mar 11 18:51:12 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F14712D4E9 for ; Mon, 11 Mar 2019 18:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.78 X-Spam-Level: *** X-Spam-Status: No, score=3.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 N0yrmao_uC0t for ; Mon, 11 Mar 2019 18:51:09 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 5947812B003 for ; Mon, 11 Mar 2019 18:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1NuNFWf8Q+/UbYQIeunzAZrsQXE46+IYP9t7IMCM6B8=; b=ajgcRfNHlxkO33FNlcJJXLN0l 86enP4hlunkex3ZWEO3NeJge2O7PvlHsCDYLRBJ71bju5iFUdtC0+h/oYVn9hiWs3bwcSctQez7O4 eX5ExBuSNJsBn3hdm+2jTNZOTFA0TUdoLvdzj/a8l29kMHvlPF/tAEkhbRKl0D8X1mcDTYFfV3rnC IE2vexjuBJUoVME+C2K2WgHwZ1la36M0ENwUhzi4v8nF82OmosUxVYOCEoAvJ57k5G4m7aOp0R7Cn AhGy5uIv7XWo120fUdJLFfZgLNap0qVZBd9BVSaFqH6EnzgxGJyv2xu1enE8hzCp3HOMmcD3SSZPe m4SCRYAgg==; Received: from [65.222.224.130] (port=58605 helo=[172.20.15.93]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3WZO-002fLs-3g; Mon, 11 Mar 2019 21:51:06 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16D57) In-Reply-To: Date: Mon, 11 Mar 2019 18:51:05 -0700 Cc: Raffaele Zullo , tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <8FDF5CF0-1421-496B-B051-29E13522363E@strayalpha.com> References: <136FF703-4DFE-4B32-A722-67122F28C894@strayalpha.com> <32fee79db0d64dd078e3025a8a5c89ff@erg.abdn.ac.uk> To: "C. M. Heard" X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 01:51:10 -0000 +1 The current wording was, FWIW, intended to continue to allow OCS alignment i= f desired. Joe > On Mar 11, 2019, at 1:28 PM, C. M. Heard wrote: >=20 >> On Mon, 11 Mar 2019 19:27:08 +0000 PM Raffaele Zullo wrote: >>> On 2019-03-11 16:26, C. M. Heard wrote: >>>> On Sat, 9 Mar 2019 11:28:57 -0800 Joe Touch wrote: >>>> Well, there are several implications here: >>>>=20 >>>> 1. we can add in the option length, BUT that also means: >>>> (a) we need to declare that the option area consumes the >>> whole of >>>> the surplus area (no chance for other uses) >>>> OR >>>> (b) that the surplus area is always zero >>>> OR >>>> (c) that OCS covers even the surplus area (it doesn=E2=80=99t ne= ed >>> to be >>>> zero; it does need to be included) >>>>=20 >>>> we need a choice here. AFAICT, the safest (a) >>>=20 >>> I agree with that. >>=20 >>=20 >> I would add that a Zero padding after UDP Options area is not neutral to >> the (full IP payload) checksum because it still increases the IP Total >> Length (it changes the "pseudo-header"). >=20 > Good point; that one seems to keep escaping me :-( >=20 >>>> 2. we don=E2=80=99t need OCS alignment; what we do need is to >>> =E2=80=9Ccoordinate=E2=80=9D the >>>=20 >>> alignment of a 16-bit of the length to the OCS checksum field >>>> i.e.: >>>> - calculate the length needed (IPlen - UDP len) >>>> - if OCS checksum field is not 16-bit aligned to the start >>> of the >>>> option area, then swap bytes >>>> - add the result to the OCS checksum (=E2=80=98pseudo header=E2=80= =99 >>> seems a bit >>>> heavy here, but same point) >>>=20 >>> I believe that is correct. Padding could still be convenient, though, >>> and I see no reason to disallow it (the current draft does permit >>> padding for alignment). >>>=20 >>=20 >> Would it be possible to leave this as a choice? >> CCO draft, despite on sender's side required alignemnt, >> on receiver's side only required that the complement of the sum of >> Options and pseudoheader was zero, >> in order to accept also a working CCO computed without alignment. >=20 > +1 >=20 > Mike Heard From nobody Mon Mar 11 19:18:08 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B96112AF7F for ; Mon, 11 Mar 2019 19:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cablelabs.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 1MzASk5BUZFg for ; Mon, 11 Mar 2019 19:18:04 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700122.outbound.protection.outlook.com [40.107.70.122]) (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 3C9BC129A86 for ; Mon, 11 Mar 2019 19:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FPYfYbfiq+Pjg7kd9NSrRcOlIoP2FgxF0oN9sJSM44U=; b=Q12I8jl2fY8P/yqNpdkLbx7tHQNC0Kdx8JCPjlkG9EJ0OITKROVJbXdN47PueoEm7WJSREZNB93aY50BSUllaoaLG8iowscWrKRJ0Gyu/Nn3/cYkpPHCRGbEjuZawICSrNqByyaHrm0zHpQXzIBPUbzM8W0niK/TsIGHCsNQJeI= Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4045.namprd06.prod.outlook.com (52.132.123.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Tue, 12 Mar 2019 02:18:01 +0000 Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b%4]) with mapi id 15.20.1686.021; Tue, 12 Mar 2019 02:18:01 +0000 From: Greg White To: Luca Muscariello CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] New Version Notification for draft-white-tsvwg-lld-00.txt Thread-Index: AQHU2HnRyW07oTC9ek+bGSwvy18MNA== Date: Tue, 12 Mar 2019 02:18:01 +0000 Message-ID: <0289E1B3-9AFF-4633-A9B1-6BAEE96B7692@cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 x-originating-ip: [73.14.190.183] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e7f3b032-468c-485b-c276-08d6a690f3c4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR06MB4045; x-ms-traffictypediagnostic: SN6PR06MB4045: x-ms-exchange-purlcount: 7 x-microsoft-exchange-diagnostics: 1; SN6PR06MB4045; 20:TQOokQ1qiNwK6Sb87H9MbV4ZLPocMitLS7hLzcqY0eq1nE82SsCx4vd3d4yeZyjqnpWgsvgD4AVXfrJFQGpyKw4WoEndMqDkOuvymj0U5pTj04Cactu9oNAuCkFfa2ACAD3VU1Kj6V6cR0xfLsQGZNkCif9fXcTHQxp0fJ6lJH8= x-microsoft-antispam-prvs: x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(366004)(136003)(39840400004)(376002)(396003)(189003)(199004)(106356001)(8936002)(6246003)(316002)(6916009)(81166006)(81156014)(83716004)(25786009)(8676002)(99286004)(966005)(186003)(256004)(14444005)(86362001)(97736004)(6486002)(36756003)(5660300002)(26005)(66574012)(68736007)(6436002)(6116002)(58126008)(229853002)(82746002)(3846002)(66066001)(478600001)(53936002)(14454004)(4326008)(2616005)(476003)(6346003)(6512007)(486006)(105586002)(33656002)(6506007)(102836004)(6306002)(53546011)(2906002)(305945005)(71190400001)(71200400001)(15650500001)(7736002)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4045; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lQGNUCSPmDrWKb945mNjdgyVVx/GO1tBv3Ple5ZcKOi2UjIWeT03ik2IUFLxEfZgJRUF3bz3f2QIa0LyroNIUYct7hhBAXtp1vh5pU70tB+KTpjM/+ppnP7VPHeAAWwjKM7MwObJba4eSZ//ZefA72EAx3uDMuA0wO604IGzeSALFRYsJCCtMQS0mUtRa6ng0KbInL7JsjodrDHkh+Ub96AbiWp6tp22QCib/2/LxrOYiNysTe9eyn/Htg+9fhble94CM79uPPFbFXSfTXobfCaDxphxTvVoBD2LA8IV2jFcQqDYPPHJ2EeiqSsopFLFLUsZI9GEJCkkjeUKCPJQPM/N+XeqrrTcAC/42uP6m/wcZRDDpSLcn4Mr0c0yoe+CUPZEKD8x9uiu98ecVe3fqekjfU0jNBx97A7k0zQUvw8= Content-Type: text/plain; charset="utf-8" Content-ID: <2A8C0CFD1569104A9F0665FC865E53A9@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7f3b032-468c-485b-c276-08d6a690f3c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 02:18:01.2812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4045 Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-white-tsvwg-lld-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 02:18:07 -0000 SGkgTHVjYSwgDQoNCllvdSBjYW4gZmluZCB0aGUgZGV0YWlscyBpbiBBbm5leCBQIG9mIHRoZSBE T0NTSVMgTVVMUEl2My4xIHNwZWMuDQpodHRwczovL3NwZWNpZmljYXRpb24tc2VhcmNoLmNhYmxl bGFicy5jb20vQ00tU1AtTVVMUEl2My4xDQoNCi1HcmVnDQoNCg0KRnJvbTogTHVjYSBNdXNjYXJp ZWxsbyA8bHVjYS5tdXNjYXJpZWxsb0BnbWFpbC5jb20+DQpEYXRlOiBNb25kYXksIE1hcmNoIDEx LCAyMDE5IGF0IDY6MjYgUE0NClRvOiBHcmVnIFdoaXRlIDxnLndoaXRlQENhYmxlTGFicy5jb20+ DQpDYzogRGF2ZSBUYWh0IDxkYXZlQHRhaHQubmV0PiwgSm9uYXRoYW4gTW9ydG9uIDxjaHJvbWF0 aXg5OUBnbWFpbC5jb20+LCAidHN2d2dAaWV0Zi5vcmciIDx0c3Z3Z0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbdHN2d2ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbW9ydG9u LXRhaHQtdHN2d2ctc2NlLTAwLnR4dA0KDQpIaSBHcmVnLA0KDQpJJ20gY3VyaW91cyBhYm91dCB0 aGUgcXVldWUgcHJvdGVjdGlvbiBmdW5jdGlvbiBpbiB0aGUgTExEIGRvY3VtZW50Lg0KSXQgc2Vl bXMgdG8gYXNzdW1lIHRoYXQgYSBmbG93IHRhYmxlIGlzIG1haW50YWluZWQgdG8gZGV0ZXJtaW5l IGlmIGEgZmxvdyANCmhhcyB0aGUgcmlnaHQgdG8gZW50ZXIgdGhlIGxvdyBsYXRlbmN5IHF1ZXVl Lg0KDQpDYW4geW91IGdpdmUgbW9yZSBkZXRhaWxzIGFib3V0IHRoYXQgY29tcG9uZW50PyBPciBw b2ludCBtZSB0byBhIHJlZmVyZW5jZT8NCg0KVGhhbmtzDQpMdWNhDQoNCg0K77u/T24gMy8xMS8x OSwgNToyOSBQTSwgInRzdndnIG9uIGJlaGFsZiBvZiBHcmVnIFdoaXRlIiA8dHN2d2ctYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZy53aGl0ZUBDYWJsZUxhYnMuY29tPiB3cm90ZToNCg0K ICAgIFRTVldHLA0KICAgIA0KICAgIEkndmUgcG9zdGVkIGEgbmV3IGluZm9ybWF0aXZlIGRyYWZ0 IHRoYXQgZ2l2ZXMgYW4gb3ZlcnZpZXcgb2YgdGhlIG5ldyBMb3cgTGF0ZW5jeSBET0NTSVMgc3Bl Y2lmaWNhdGlvbiAoc2VlIGxpbmtzIGJlbG93KS4gIFRoaXMgb3ZlcnZpZXcgbWF5IGJlIGludGVy ZXN0aW5nIHRvIFRTVldHIHBhcnRpY2lwYW50cyBiZWNhdXNlIGl0IGluY2x1ZGVzIHN1cHBvcnQg Zm9yIEw0UyAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LXRzdndnLWFxbS1kdWFscS1jb3VwbGVkKSBhbmQgZm9yIHRoZSBOUUIgUEhCIChodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdoaXRlLXRzdndnLW5xYikuDQogICAg DQogICAgQmVzdCBSZWdhcmRzLA0KICAgIEdyZWcNCiAgICANCiAgICANCiAgICANCiAgICBPbiAz LzExLzE5LCA1OjA1IFBNLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPiB3cm90ZToNCiAgICANCiAgICAgICAgDQogICAgICAgIEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC13aGl0ZS10c3Z3Zy1sbGQtMDAudHh0DQogICAgICAgIGhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBXaGl0ZSBhbmQgcG9zdGVkIHRvIHRoZQ0K ICAgICAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAgICAgIA0KICAgICAgICBOYW1lOgkJZHJhZnQt d2hpdGUtdHN2d2ctbGxkDQogICAgICAgIFJldmlzaW9uOgkwMA0KICAgICAgICBUaXRsZToJCUxv dyBMYXRlbmN5IERPQ1NJUyAtIFRlY2hub2xvZ3kgT3ZlcnZpZXcNCiAgICAgICAgRG9jdW1lbnQg ZGF0ZToJMjAxOS0wMy0xMQ0KICAgICAgICBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0K ICAgICAgICBQYWdlczoJCTI1DQogICAgICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2hpdGUtdHN2d2ctbGxkLTAwLnR4dCANCiAg ICAgICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXdoaXRlLXRzdndnLWxsZC8gDQogICAgICAgIEh0bWxpemVkOiAgICAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2hpdGUtdHN2d2ctbGxkLTAwIA0KICAgICAgICBIdG1s aXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13 aGl0ZS10c3Z3Zy1sbGQgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgQWJzdHJhY3Q6DQog ICAgICAgICAgIE5PVEU6IFRoaXMgZG9jdW1lbnQgaXMgYSByZWZvcm1hdHRlZCB2ZXJzaW9uIG9m IFtMTEQtd2hpdGUtcGFwZXJdLg0KICAgICAgICANCiAgICAgICAgICAgVGhlIGV2b2x1dGlvbiBv ZiB0aGUgYmFuZHdpZHRoIGNhcGFiaWxpdGllcyAtIGZyb20ga2lsb2JpdHMgcGVyDQogICAgICAg ICAgIHNlY29uZCB0byBnaWdhYml0cyAtIGFjcm9zcyBnZW5lcmF0aW9ucyBvZiBET0NTSVMgY2Fi bGUgYnJvYWRiYW5kDQogICAgICAgICAgIHRlY2hub2xvZ3kgaGFzIHBhdmVkIHRoZSB3YXkgZm9y IHRoZSBhcHBsaWNhdGlvbnMgdGhhdCB0b2RheSBmb3JtIG91cg0KICAgICAgICAgICBkaWdpdGFs IGxpdmVzLiAgQWxvbmcgd2l0aCBpbmNyZWFzZWQgYmFuZHdpZHRoLCBvciAic3BlZWQiLCB0aGUN CiAgICAgICAgICAgbGF0ZW5jeSBwZXJmb3JtYW5jZSBvZiBET0NTSVMgdGVjaG5vbG9neSBoYXMg YWxzbyBpbXByb3ZlZCBpbiByZWNlbnQNCiAgICAgICAgICAgeWVhcnMuICBBbHRob3VnaCBpdCBv ZnRlbiBnZXRzIGxlc3MgYXR0ZW50aW9uLCBsYXRlbmN5IHBlcmZvcm1hbmNlDQogICAgICAgICAg IGNvbnRyaWJ1dGVzIGFzIG11Y2ggb3IgbW9yZSB0byB0aGUgYnJvYWRiYW5kIGV4cGVyaWVuY2Ug YW5kIHRoZQ0KICAgICAgICAgICBmZWFzaWJpbGl0eSBvZiBmdXR1cmUgYXBwbGljYXRpb25zIGFz IGRvZXMgc3BlZWQuDQogICAgICAgIA0KICAgICAgICAgICBMb3cgTGF0ZW5jeSBET0NTSVMgdGVj aG5vbG9neSAoTExEKSBpcyBhIHNwZWNpZmljYXRpb24gZGV2ZWxvcGVkIGJ5DQogICAgICAgICAg IENhYmxlTGFicyBpbiBjb2xsYWJvcmF0aW9uIHdpdGggRE9DU0lTIHZlbmRvcnMgYW5kIGNhYmxl IG9wZXJhdG9ycw0KICAgICAgICAgICB0aGF0IHRhY2tsZXMgdGhlIHR3byBtYWluIGNhdXNlcyBv ZiBsYXRlbmN5IGluIHRoZSBuZXR3b3JrOiBxdWV1aW5nDQogICAgICAgICAgIGRlbGF5IGFuZCBt ZWRpYSBhY3F1aXNpdGlvbiBkZWxheS4gIExMRCBpbnRyb2R1Y2VzIGFuIGFwcHJvYWNoDQogICAg ICAgICAgIHdoZXJlaW4gZGF0YSB0cmFmZmljIGZyb20gYXBwbGljYXRpb25zIHRoYXQgYXJlbid0 IGNhdXNpbmcgbGF0ZW5jeQ0KICAgICAgICAgICBjYW4gdGFrZSBhIGRpZmZlcmVudCBsb2dpY2Fs IHBhdGggdGhyb3VnaCB0aGUgRE9DU0lTIG5ldHdvcmsgd2l0aG91dA0KICAgICAgICAgICBnZXR0 aW5nIGh1bmcgdXAgYmVoaW5kIGRhdGEgZnJvbSBhcHBsaWNhdGlvbnMgdGhhdCBhcmUgY2F1c2lu Zw0KICAgICAgICAgICBsYXRlbmN5LCBhcyBpcyB0aGUgY2FzZSBpbiB0b2RheSdzIEludGVybmV0 IGFyY2hpdGVjdHVyZXMuICBUaGlzDQogICAgICAgICAgIG1lY2hhbmlzbSBkb2Vzbid0IGludGVy ZmVyZSB3aXRoIHRoZSB3YXkgYXBwbGljYXRpb25zIHNoYXJlIHRoZSB0b3RhbA0KICAgICAgICAg ICBiYW5kd2lkdGggb2YgdGhlIGNvbm5lY3Rpb24sIGFuZCBpdCBkb2Vzbid0IHJlZHVjZSBvbmUg YXBwbGljYXRpb24ncw0KICAgICAgICAgICBsYXRlbmN5IGF0IHRoZSBleHBlbnNlIG9mIG90aGVy cy4gIEluIGFkZGl0aW9uLCBMTEQgaW1wcm92ZXMgdGhlDQogICAgICAgICAgIERPQ1NJUyB1cHN0 cmVhbSBtZWRpYSBhY3F1aXNpdGlvbiBkZWxheSB3aXRoIGEgZmFzdGVyIHJlcXVlc3QtZ3JhbnQN CiAgICAgICAgICAgbG9vcCBhbmQgYSBuZXcgcHJvYWN0aXZlIHNjaGVkdWxpbmcgbWVjaGFuaXNt LiAgTExEIG1ha2VzIHRoZQ0KICAgICAgICAgICBpbnRlcm5ldCBleHBlcmllbmNlIGJldHRlciBm b3IgbGF0ZW5jeSBzZW5zaXRpdmUgYXBwbGljYXRpb25zIHdpdGhvdXQNCiAgICAgICAgICAgYW55 IG5lZ2F0aXZlIGltcGFjdCBvbiBvdGhlciBhcHBsaWNhdGlvbnMuDQogICAgICAgIA0KICAgICAg ICAgICBUaGUgbGF0ZXN0IGdlbmVyYXRpb24gb2YgRE9DU0lTIGVxdWlwbWVudCB0aGF0IGhhcyBi ZWVuIGRlcGxveWVkIGluDQogICAgICAgICAgIHRoZSBmaWVsZCAtIERPQ1NJUyAzLjEgLSBleHBl cmllbmNlcyB0eXBpY2FsIGxhdGVuY3kgcGVyZm9ybWFuY2Ugb2YNCiAgICAgICAgICAgYXJvdW5k IDEwIG1pbGxpc2Vjb25kcyAobXMpIG9uIHRoZSBBY2Nlc3MgTmV0d29yayBsaW5rLiAgSG93ZXZl ciwNCiAgICAgICAgICAgdW5kZXIgaGVhdnkgbG9hZCwgdGhlIGxpbmsgY2FuIGV4cGVyaWVuY2Ug ZGVsYXkgc3Bpa2VzIG9mIDEwMCBtcyBvcg0KICAgICAgICAgICBtb3JlLiAgTExEIHN5c3RlbXMg Y2FuIGRlbGl2ZXIgYSBjb25zaXN0ZW50IDEgbXMgZGVsYXkgb24gdGhlIERPQ1NJUw0KICAgICAg ICAgICBuZXR3b3JrIGZvciB0cmFmZmljIHRoYXQgaXNuJ3QgY2F1c2luZyBsYXRlbmN5LCBpbXBl cmNlcHRpYmxlIGZvcg0KICAgICAgICAgICBuZWFybHkgYWxsIGFwcGxpY2F0aW9ucy4gIFRoZSBl eHBlcmllbmNlIHdpbGwgYmUgbW9yZSBjb25zaXN0ZW50IHdpdGgNCiAgICAgICAgICAgbXVjaCBz bWFsbGVyIGRlbGF5IHZhcmlhdGlvbi4NCiAgICAgICAgDQogICAgICAgICAgIExMRCBjYW4gYmUg ZGVwbG95ZWQgYnkgZmllbGQtdXBncmFkaW5nIERPQ1NJUyAzLjEgY2FibGUgbW9kZW0gYW5kDQog ICAgICAgICAgIGNhYmxlIG1vZGVtIHRlcm1pbmF0aW9uIHN5c3RlbSBkZXZpY2VzIHdpdGggbmV3 IHNvZnR3YXJlLiAgVGhlDQogICAgICAgICAgIHRlY2hub2xvZ3kgaW5jbHVkZXMgdG9vbHMgdGhh dCBlbmFibGUgYXV0b21hdGljIHByb3Zpc2lvbmluZyBvZiB0aGVzZQ0KICAgICAgICAgICBuZXcg c2VydmljZXMsIGFuZCBpdCBhbHNvIGludHJvZHVjZXMgbmV3IHRvb2xzIHRvIHJlcG9ydCBzdGF0 aXN0aWNzDQogICAgICAgICAgIG9mIGxhdGVuY3kgcGVyZm9ybWFuY2UgdG8gdGhlIG9wZXJhdG9y Lg0KICAgICAgICANCiAgICAgICAgICAgQ2FibGUgb3BlcmF0b3JzLCBET0NTSVMgZXF1aXBtZW50 IG1hbnVmYWN0dXJlcnMsIGFuZCBhcHBsaWNhdGlvbg0KICAgICAgICAgICBwcm92aWRlcnMgd2ls bCBhbGwgaGF2ZSB0byBhY3QgaW4gb3JkZXIgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgTExELg0KICAg ICAgICAgICBUaGlzIHdoaXRlIHBhcGVyIGV4cGxhaW5zIHRoZSB0ZWNobm9sb2d5IGFuZCBkZXNj cmliZXMgdGhlIHJvbGUgdGhhdA0KICAgICAgICAgICBlYWNoIG9mIHRoZXNlIHBhcnRpZXMgcGxh eXMgaW4gbWFraW5nIExMRCBhIHJlYWxpdHkuDQogICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KICAgICAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgICAgICANCiAgICAgICAgVGhlIElFVEYg U2VjcmV0YXJpYXQNCiAgICAgICAgDQogICAgICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Mon Mar 11 19:24:23 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261E112AF7F for ; Mon, 11 Mar 2019 19:24:22 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 hux1dH8gJ0p3 for ; Mon, 11 Mar 2019 19:24:20 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 5B308129A86 for ; Mon, 11 Mar 2019 19:24:20 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id z76so540255qkb.12 for ; Mon, 11 Mar 2019 19:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LSDc+lWcROTx/wKAkb35cjSJ/RkA736jE9iXtNPFkRk=; b=g5d/zqw2g2lrGY/qitqyFHANV9duNEBzkHDWmGg+UzqDzvPKtcU7eU1ubk10UE+wgy g97Pq1WKqzhL7Lf8VEeN/eYPECIkDMx6SVIh/zxaNQGc119rzZPnKDBXkUDAlMNON+zE JlSjZL/md0HgA6OClABMjjeVd3kHX8QZiXfi0VlZ5NJfja1xeTk77j3RVuUxORVbT5bP DMx55t6CNOD2hgda6Ld7krr05FAauF5TBsw8Ho9wCSeYmtsrcATFizN2fUl4gwPRCtCG 12Yz1DXrlOqfUZtJPD6etyYl+KaCwtM3rXf1Y20+VTzT9o8pn6xgo9yH2eNFNbGhSy+r VIPA== 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:content-transfer-encoding; bh=LSDc+lWcROTx/wKAkb35cjSJ/RkA736jE9iXtNPFkRk=; b=JwIBEAP+fnBr8Wsk77EaIU9Mw8IZRIS7Ovz1LP7V98tUKcIMz1Qir9NMymcPpqoQ7q iXFQuJJE5mavAkR5egJMEy++FvQwuulVNIb4SvrGlO51dVIzfWMkrJkJkyR/yw7naOTm rfCvPI9IYF08DsIbeiqh4P+mUDuatlyqi/VgyyDRHgHSrLW/4cG9HswTo1C2XEcsQiQS RTVDh6bTtKYj7krxf95wbackjBiKwy7gcBl0S0KvCoXNFc8Xy0/zpZOh4z0wEHbgCyoB o2pFfZTdy/5NWxXJiRXmUGuomnAZm3JLc+SnbSXArZcH4Q6QxzqJQak0aVpR/MKvW7en PbVA== X-Gm-Message-State: APjAAAVY7laZtLM4j/iJmgMJv7JWdpjCLDb0XCMvjvPL+xSTuW0VLtIV gkbVo4bMJV9bTNLXUx5cWo2rrClqthXaQAJkYHtQHQIV X-Google-Smtp-Source: APXvYqylZTPrhSzivTQH+evTN7KDKiXqWUKqru+x4Mn68Bry9HRL9q8p8bsuWtTdyqE0H2KwNeqT1lBwfg6XD56SQVs= X-Received: by 2002:a05:620a:15f5:: with SMTP id p21mr27260857qkm.168.1552357459354; Mon, 11 Mar 2019 19:24:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Mon, 11 Mar 2019 19:24:08 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 02:24:22 -0000 On Mon, Mar 11, 2019 at 6:49 PM Joe Touch wrote: > > > > On Mar 11, 2019, at 12:56 PM, Tom Herbert wrote: > > >> From the draft: > > > > "The primary purpose of OCS is to detect non-standard (i.e., > > non-option) uses of the options area". > > > > Given that the checksum is optional, I don't see how this works to > > detect non-standard use of the checksum area. For instance, if some > > random garbage bytes are in the option area then the only way the > > non-standard use is detected is if by chance the type for OCS happens > > to appear in the data and is parsed as being an OCS option. Of course > > that's exceedingly unlikely to happen, so garbage data is likely to be > > proessed as options. > > A receiver that cares can require OCS, as has already been noted several = times (I can check in the next rev that this is mentioned in the text). > Considering that this is an application based mechanism, how would the average user even know to care about this? It's better to not give the option and just provide something that is robust out of the box. > > As I mentioned previously, UDP options space should start with a fixed > > size header that includes a two byte checksum. This will eliminate any > > ambiguity and solves other problems (like the corrupted OCS type field > > problem), > > That just forces senders to use OCS, which wastes space when it=E2=80=99s= not needed or desired (or the space is needed for other purposes). It also= forces a particular alignment that may not be desired. > The overhead of header with checksum, length, and type and alignment to four bytes is at four to seven bytes (minus three if the OCS would be enabled). IMO the overhead, both on the wire and processing, is inconsequential to the benefits of robustness and extensibility in using the surplus space that a header offers. Tom > Joe From nobody Mon Mar 11 19:38:35 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411B7130DE4 for ; Mon, 11 Mar 2019 19:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cablelabs.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 RWoFoEoGL4XQ for ; Mon, 11 Mar 2019 19:38:31 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740129.outbound.protection.outlook.com [40.107.74.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0EC130D7A for ; Mon, 11 Mar 2019 19:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K1zkIutsOQrZCnH5rE6EDD8x6YVYU6KRItPki08KsXI=; b=c2EjJ7/vsbVYQkNQBFJFsZ7b05FiO2cyh7ChNUfpevBL7iBnS6sB2DL7Fo5Ola+6s8WexSByDS3Oe78lzHK24SBh7fSNrpD3n5dBCGiIbgpHLO3NZMkaUwkubh4GiD8sEFNPFHkPJoe80OLKtasOtVa+eYmA5GTNSpP+j/B4HsY= Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB5070.namprd06.prod.outlook.com (52.135.110.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.21; Tue, 12 Mar 2019 02:38:28 +0000 Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::712c:21cc:3dcf:637b%4]) with mapi id 15.20.1686.021; Tue, 12 Mar 2019 02:38:28 +0000 From: Greg White To: "Holland, Jake" , Dave Taht CC: Jonathan Morton , "tsvwg@ietf.org" Thread-Topic: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt Thread-Index: AQHU16gidytVluJIdkSixRL8FOY/naYGn8cA//+ofYCAAM4TFP//oAmAgABprAD//8VmgA== Date: Tue, 12 Mar 2019 02:38:27 +0000 Message-ID: References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net> <75227bef-6757-26ea-9071-43265ceb9abe@bobbriscoe.net> <63DC5E45-449A-4008-9041-95A3C7216FF4@cablelabs.com> <87h8c9m1fk.fsf@taht.net> <2CFCED24-68E9-4430-95FC-380E415D82B3@cablelabs.com> <5A300B19-0D97-4FE4-BAAA-FACA9A4327F8@akamai.com> In-Reply-To: <5A300B19-0D97-4FE4-BAAA-FACA9A4327F8@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com; x-originating-ip: [73.14.190.183] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c014b5b1-5465-428e-70e1-08d6a693cee2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR06MB5070; x-ms-traffictypediagnostic: SN6PR06MB5070: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: 1; SN6PR06MB5070; 20:w+f/L/3lM3rI/m3ro+78vz3XXuRlphjvqkCIVEW6LPE4bI5mWkPMghgYcosV1DQWm26cCx+NR85nhygkB8bncEMVglvbA3nm1GXYi/bUBe4T+KtTnAuQ7cItvrfv46PSMllH+lAHXElZN7HBzrApTiEKuWJt0qO1fyGgtCh2Y3M= x-microsoft-antispam-prvs: x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(346002)(376002)(396003)(136003)(366004)(199004)(189003)(53936002)(97736004)(14454004)(966005)(6486002)(15650500001)(6436002)(478600001)(229853002)(102836004)(86362001)(256004)(316002)(58126008)(14444005)(66066001)(93886005)(6246003)(83716004)(71200400001)(186003)(5660300002)(6512007)(26005)(110136005)(2906002)(54906003)(66574012)(6306002)(106356001)(76176011)(99286004)(71190400001)(53546011)(2616005)(105586002)(446003)(476003)(8936002)(33656002)(68736007)(486006)(6506007)(8676002)(4326008)(81156014)(82746002)(25786009)(36756003)(305945005)(3846002)(7736002)(6116002)(81166006)(11346002)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB5070; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: B/tFAjuvktvTyq2ftKIKWRTddKF6YpZfB2FQXkqmJRnXE2eWVKxuw166JhMd+cpd2TnfBQme2KXQo8h2gGFEWlSpwrqJ4YAs10BMWc90y4E5I8XZ3ZuM2DMapPUcl5WZX2tYoB/V4Wk8JsNWDrQV9vXTR3AiPYkEFgQVscFXpiUTpozosidE2k4OFJxMS4JDlTyXkaUvBY9wRDNw8HMqQrHg8TA/E4ocAvQBadOn14eldoASydAXqDwFUWjYE1SW3nLOZhiDG68cD/8Kq3X2ZJ+Rh2Pvnd736RHOTRrWuyzwQE6UV+NPG/wDKXbXCdeiUxJ3t7lJIU5ett/kk3t1RFy+vDFKo4VHdTIpf/jvFyQ9g96/w5D8qzg81oHHgkk1AZjZECVTvSWsYHFUIn1mXjNcRM6McC13nctiQt9hsLg= Content-Type: text/plain; charset="utf-8" Content-ID: <9C21A17DEB40384983601E33FF0C1F84@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: c014b5b1-5465-428e-70e1-08d6a693cee2 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 02:38:27.9532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB5070 Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 02:38:34 -0000 SSBzdGFuZCBjb3JyZWN0ZWQuICBUaGV5IGFyZSBleHBlcmltZW50YWwuIE5vbmV0aGVsZXNzLCB0 aGV5IGFyZSBub3QgcHJvcHJpZXRhcnkgc3BlY3MgZm9yIHRoZSBjYWJsZSBpbmR1c3RyeS4gDQoN ClRoZSBET0NTSVMgaW1wbGVtZW50YXRpb25zIG9mIEw0UyBhcmUgZW50aXJlbHkgaW4gZmlybXdh cmUgYW5kIGNhbiBiZSBlbmFibGVkL2Rpc2FibGVkIGJ5IHRoZSBvcGVyYXRvciB2aWEgY29uZmln dXJhdGlvbiBzZXR0aW5ncy4NCg0KLUdyZWcNCg0K77u/T24gMy8xMS8xOSwgNjowOCBQTSwgIkhv bGxhbmQsIEpha2UiIDxqaG9sbGFuZEBha2FtYWkuY29tPiB3cm90ZToNCg0KICAgIE9uIDIwMTkt MDMtMTEsIDE2OjUwLCAiR3JlZyBXaGl0ZSIgPGcud2hpdGVAQ2FibGVMYWJzLmNvbT4gd3JvdGU6 DQogICAgPiBJdCBpcyBhIHN0YW5kYXJkcy10cmFjayBkcmFmdCBoZXJlIGF0IElFVEYNCiAgICAN CiAgICBJIHRob3VnaHQgdGhlIEw0UyBkcmFmdHMgd2VyZSBleHBlcmltZW50YWwsIG5vdCBzdGFu ZGFyZHMtdHJhY2s6DQogICAgDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdHN2d2ctYXFtLWR1YWxxLWNvdXBsZWQtMDgNCiAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA0DQogICAgDQogICAgV2FzIHRo ZXJlIG9uZSB0aGF0J3Mgc3RhbmRhcmRzIHRyYWNrPw0KICAgIA0KICAgIFRoYW5rcyBhbmQgcmVn YXJkcywNCiAgICBKYWtlDQogICAgDQogICAgICAgIA0KICAgICAgICAtR3JlZw0KICAgICAgICAN CiAgICAgICAgDQogICAgICAgIE9uIDMvMTEvMTksIDU6MzMgUE0sICJEYXZlIFRhaHQiIDxkYXZl QHRhaHQubmV0PiB3cm90ZToNCiAgICAgICAgDQogICAgICAgICAgICANCiAgICAgICAgICAgIA0K ICAgICAgICAgICAgR3JlZyBXaGl0ZSA8Zy53aGl0ZUBDYWJsZUxhYnMuY29tPiB3cml0ZXM6DQog ICAgICAgICAgICANCiAgICAgICAgICAgID4gT24gdGhlIGl0ZW0gYmVsb3csIEkgYW0gaW50ZW5k aW5nIHRvIGZpbmlzaCB1cCBhbmQgc3VibWl0IGEgVFNWV0cNCiAgICAgICAgICAgID4gaW5mb3Jt YXRpb25hbCBkcmFmdCB0b2RheSB0aGF0IGRlc2NyaWJlcyB0aGUgKG5ldykgbWFuZGF0b3J5IHN1 cHBvcnQNCiAgICAgICAgICAgID4gZm9yIEw0UyBBUU0gYW5kIGR1YWwtcXVldWUgcmVxdWlyZW1l bnQgaW4gRE9DU0lTIDMuMSAoQ00gJiBDTVRTKQ0KICAgICAgICAgICAgPiBlcXVpcG1lbnQuIFRo ZSBkcmFmdCB3aWxsIGVzc2VudGlhbGx5IGJlIGEgcmVmb3JtYXQgb2YgdGhpcyBkb2N1bWVudDoN CiAgICAgICAgICAgID4NCiAgICAgICAgICAgID4gaHR0cHM6Ly9jYWJsZWxhLmJzL2xvdy1sYXRl bmN5LWRvY3Npcy10ZWNobm9sb2d5LW92ZXJ2aWV3LWZlYnJ1YXJ5LTIwMTkNCiAgICAgICAgICAg ID4NCiAgICAgICAgICAgID4gVGhlc2UgcmVxdWlyZW1lbnRzIHdlcmUgYWRkZWQgaW4gRGVjZW1i ZXIsIGFuZCB3aWxsIHJvbGwgb3V0IGFzDQogICAgICAgICAgICA+IGZpcm13YXJlIHVwZGF0ZXMg dG8gZXhpc3RpbmcgRE9DU0lTIDMuMSBlcXVpcG1lbnQgKG5lYXJseSAxMDAlIG9mDQogICAgICAg ICAgICA+IENNVFNzLCBhbmQgYSBncm93aW5nIGZyYWN0aW9uIG9mIENNcykgb3ZlciB0aW1lLg0K ICAgICAgICAgICAgDQogICAgICAgICAgICBJIHdhcyB1bmF3YXJlIG9mIHRoaXMgbm90aWNlLCBh bmQgYXMgSSBub3RlLCBpdCdzIG9ubHkgbWFyY2guLi4NCiAgICAgICAgICAgIA0KICAgICAgICAg ICAgVXNpbmcgdXAgdGhlIGxhc3QgRUNOIGJpdCBpbiB0aGlzIHdheSwgZm9yIHRoZSBzb2xlIGJl bmVmaXQgb2YgdGhlIGNhYmxlDQogICAgICAgICAgICBpbmR1c3RyeSwgc3RyaWtlcyBtZSBhcyBh IHBvb3Igc3RhbmRhcmQgZm9yIHRoZSBpbnRlcm5ldC4NCiAgICAgICAgICAgIA0KICAgICAgICAg ICAgPg0KICAgICAgICAgICAgPiAtR3JlZw0KICAgICAgICAgICAgPg0KICAgICAgICAgICAgPiBG cm9tOiB0c3Z3ZyA8dHN2d2ctYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEJvYiBCcmlz Y29lDQogICAgICAgICAgICA+IDxpZXRmQGJvYmJyaXNjb2UubmV0Pg0KICAgICAgICAgICAgPiBE YXRlOiBNb25kYXksIE1hcmNoIDExLCAyMDE5IGF0IDEwOjI5IEFNDQogICAgICAgICAgICA+IFRv OiBEYXZlIFRhaHQgPGRhdmVAdGFodC5uZXQ+LCAidHN2d2dAaWV0Zi5vcmciIDx0c3Z3Z0BpZXRm Lm9yZz4NCiAgICAgICAgICAgID4gQ2M6IEpvbmF0aGFuIE1vcnRvbiA8Y2hyb21hdGl4OTlAZ21h aWwuY29tPg0KICAgICAgICAgICAgPiBTdWJqZWN0OiBSZTogW3RzdndnXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yDQogICAgICAgICAgICA+IGRyYWZ0LW1vcnRvbi10YWh0LXRzdndnLXNj ZS0wMC50eHQNCiAgICAgICAgICAgID4NCiAgICAgICAgICAgID4gTDRTIGlzIGZhciBmcm9tIGRl YWQuIEl0J3MgbWVyZWx5IGJlZW4gd29ya2luZyBkaWZmZXJlbnRseSBmcm9tIGhvdw0KICAgICAg ICAgICAgPiB5b3UncmUgdXNlZCB0by4gVGhvc2Ugd29ya2luZyBvbiBhbiBMNFMgQVFNIChhdCBs ZWFzdCB0aG9zZSBpbiB0aGUNCiAgICAgICAgICAgID4gY2FibGUgaW5kdXN0cnkpIGhhZCB0byBo YXZlIGEgcHJpdmF0ZSBXRyBmb3IgdGhlIGxhc3QgfjE4IG1vbnRocywgYnV0DQogICAgICAgICAg ICA+IG5vdyB3ZSdyZSBhbGxvd2VkIHRvIHB1Ymxpc2ggYW5kIHRhbGsgb3Blbmx5IGFnYWluLiAN CiAgICAgICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQoNCg== From nobody Mon Mar 11 19:43:16 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FB7130E13 for ; Mon, 11 Mar 2019 19:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 A-ycc8LmGr3U for ; Mon, 11 Mar 2019 19:43:08 -0700 (PDT) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142B712D84D for ; Mon, 11 Mar 2019 19:43:07 -0700 (PDT) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 609EA136E8B for ; Mon, 11 Mar 2019 22:43:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=IbE ZEJEzLFOImolf2YSaKUI/2gU=; b=DuJP02AR/QfvaiiGXZQLYPvb9IE6hqDxXzI e94HxZu3k67slKwSAd94bQmEqsIbFvxo+91JJruVwzbuFMRAMpNMPCgOmBh7sUVR LcadzklqgTVJExpHD4G8c0uSlSDMw+0C2nbgC+oPn7qAGW9giejvYlwthYdifOFw i40l5auA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= Oac/iIDnTYiVh4x/j9O5kN++xKSYA/AbMZv2fxo610ufX1DMs4jG5V4P6H7B1ZpP EhjswWk5enZYLhDFs2eN3oxORy4KEFLhky5Wm0uwyL+stRxn6klQchK3U5ae6Kvf ZlibbBJtv6UOOkYISXFZb2dvWISIdeaiuo617cjAlq0= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5859B136E8A for ; Mon, 11 Mar 2019 22:43:06 -0400 (EDT) Received: from mail-io1-f51.google.com (unknown [209.85.166.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id D0D06136E88 for ; Mon, 11 Mar 2019 22:43:05 -0400 (EDT) Received: by mail-io1-f51.google.com with SMTP id x4so773481ion.2 for ; Mon, 11 Mar 2019 19:43:05 -0700 (PDT) X-Gm-Message-State: APjAAAUD8yCdGG1T41/UzMISXg5XMr+3xOLBFwFYOuydwjh2BYtF92KS kF/heFvAPm0xI9yLnBrhtpcz+CN8UHxDqhcfaK8= X-Google-Smtp-Source: APXvYqxjJRBEjnilx5YxUkTecG/sDI5/t7rPKWfjrz2DSPhq4AVlMSQIBOgaCnu6HWyJ98ZfnxfGB5RSnUjyqkTs9pM= X-Received: by 2002:a5d:8acf:: with SMTP id e15mr20497319iot.24.1552358585338; Mon, 11 Mar 2019 19:43:05 -0700 (PDT) MIME-Version: 1.0 From: "C. M. Heard" Date: Mon, 11 Mar 2019 19:42:53 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Tom Herbert Cc: tsvwg Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 9040941E-4470-11E9-9DA8-DF19F34BB12D-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 02:43:14 -0000 On Mon, 11 Mar 2019 17:12:22 -0700 Tom Herbert wrote: > If I understand CCO correctly, the problem seems to be that some > middle boxes incorrectly use the IP length instead of UDP length for > checksum calculation. This seems to be both for the coverage of the > UDP checksum as well as the length in the pseudo header. The first > part is addressed since the checksum in the UDP surplus header sums to > zero, so adding this to the checksum just over the UDP header and > payload yields the same value. Determining that the IP length was used > in the pseudo header would require an extra step. It seems like that > could be done without any special options, just check the normal UDP > checksum and if that fails add the checksum difference between the IP > length and UDP length and see if that yields checksum zero. The problem with that suggestion is that it does not permit a UDP packet with a trailer to traverse middleboxes that validate the checksum using the IP payload length instead of the UDP length. That is the main problem that CCO was designed to solve. See https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00 Mike Heard From nobody Mon Mar 11 19:54:16 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E569130E2B for ; Mon, 11 Mar 2019 19:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Pd2p36SvVJxK for ; Mon, 11 Mar 2019 19:54:12 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 9112F130E0A for ; Mon, 11 Mar 2019 19:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=flZnRHNeSZCc09LxtU5CVFviB5qURvOO1bWjYgrLvA8=; b=wOFrl/cmG2fohCD2KX8rRYJx4 8Dw4Wv6K5tgQoAH/6dUhI3KUtkFV7PjdMoKX/EPHusZ6KTKskWQp3bCC+PV5zgndXA7BuAdNzUm1p fKdjzbAh4Uc/Z6tB2kUYtzAUvgg42lDGKkCNLnxy5ze9K5DerIxFkVdaftsQGblmKTnTk5f3A9QgI GFkPv1gVohV4H8Bm6FRphf13LWomwF7bbLQ0iuKHPi0ZYxC60LGfEWtSE6/HF0QNT6J2UZG0s3G4U 9KpnDJLWT3V2bdbLirsAbEvN/Gti7yJac5wxYsPSBs3jis2BnJGfsLdUQzhhOB8JzgiFo8+ChrmyV NeC/ivilQ==; Received: from [65.222.224.130] (port=26357 helo=[172.20.15.93]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3XYR-003r84-2N; Mon, 11 Mar 2019 22:54:11 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16D57) In-Reply-To: Date: Mon, 11 Mar 2019 19:54:10 -0700 Cc: tsvwg Content-Transfer-Encoding: 7bit Message-Id: References: To: Tom Herbert X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 02:54:14 -0000 > On Mar 11, 2019, at 7:24 PM, Tom Herbert wrote: > > Considering that this is an application based mechanism, how would the > average user even know to care about this? The same way they know and care about udp checksums or not. > It's better to not give the > option and just provide something that is robust out of the box. We already have plenty of choices that are more risky, including CS=0. The point is to be flexible - were not designing for today only. And space - even a few bytes - is absolutely a significant consideration. Joe From nobody Mon Mar 11 20:35:07 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E641130E6D for ; Mon, 11 Mar 2019 20:35:06 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 5cqJ_u43seyW for ; Mon, 11 Mar 2019 20:35:04 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 3D9B6130E79 for ; Mon, 11 Mar 2019 20:35:04 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id d16so1027363qtn.10 for ; Mon, 11 Mar 2019 20:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NRPjv+iK4rCDR19zDcv41/2MTa8uAk/1eswqteAVP9k=; b=IojRS5vOxEKnT4mVTZsNVvHVh95OZseHLocFfs/a36sxGsapIvDnEJ3ojRIB/OeNm0 g/rGsXyJ+xdIPlgtMWzOTM0sPmmgsPpWnpgcS8GXg7JFrc5iJC2B9/uQjeESYiqZB9QK +Na3sSOvd3dAediu2fs2TOJghr39+kS+SyJG7rdO8VfU6+9/17UX55Rx14oXRf2WHUAm FByCkQNXmalMVxKWjsyWr0f25STWS8eyy9poM0zkkWOV+b8+mMDi1Gh71Bd19vKZedqu nwAl5iIJGBZbIPYV9LR6NvvPyllu8+V+6CsYyZMxQRVXTErFJvmYdJQFRM8g3WGRs3Hu H6CQ== 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=NRPjv+iK4rCDR19zDcv41/2MTa8uAk/1eswqteAVP9k=; b=ZNTIDA2yyHtiEuSXv4W6YUzD1JeXcAD+9ItqLE0XUW4Oj5P7Q19AjvRZJb2X7H9kIB y9fexcyE6Ld525dNXrwkr4aub0OSx2Dw65TVp2HAA509ooV7WvQyj3bpdlejl1vZv1pO EPdSlPP+5Zw1NRTrALF1VPETtbbu20L/bzhVW0W2ZPNNOSLlxHhldhBDvLvtEMOlAM7h jlYULgPwKga8zmf4pQWvPhi1cJXD4IBXERIm1xYwqO6SFkF3/ybPfLb3jtFkLTpgKJEw jdgAHYpc266HDuPuAqyMtmxLaobx7gBtRmOxw2ONbOpMCdjv7qcxaLSsv4hWmpP9jrdi VV+g== X-Gm-Message-State: APjAAAUXNoPbg40/2/YTDvNwkBXYefAbUb6ll5aayEklh/KuL+CMSrry aOGXe9eCMzNyv6W+p/xhwAnM6h+GDHcNMpEsNE04cw== X-Google-Smtp-Source: APXvYqzmG6A4Op0/jlwCPUh807Sm5o7RGtlSjZQVwMHa+KiosUWk2otxcSsAZFKjRsyy2gWvSayCNdvCMRvd/wikP60= X-Received: by 2002:ac8:3328:: with SMTP id t37mr5134685qta.246.1552361703345; Mon, 11 Mar 2019 20:35:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Mon, 11 Mar 2019 20:34:52 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 03:35:06 -0000 On Mon, Mar 11, 2019 at 7:54 PM Joe Touch wrote: > > > > > On Mar 11, 2019, at 7:24 PM, Tom Herbert wrote: > > > > Considering that this is an application based mechanism, how would the > > average user even know to care about this? > > The same way they know and care about udp checksums or not. > > > It's better to not give the > > option and just provide something that is robust out of the box. > > We already have plenty of choices that are more risky, including CS=0. > That's more an argument that UDP checksums should not be zero, rather than a fixed checksum is not needed in UDP surplus space. I agree with that. Given that every NIC offloads the checksum anyway, the recommendation really should be to always use the UDP checksum (it's required in IPv6 anyway and we get better performance in cases of encapsulation). > The point is to be flexible - were not designing for today only. > Robustness trumps flexibility. > And space - even a few bytes - is absolutely a significant consideration. > It depends on several factors whether the overhead is justified. For instance, a four byte alignment requirement really does have any impact since IP and UDP are already four byte aligned and MTUs are almost always divisible by four (i.e. alignment doesn't reduce available MTU). If the common deployment case is to always enable OCS (seems like in Appendix A of the UDP options draft the intended default is to enable it), then the overhead of the header reduces to one byte. An overhead of one byte really is not worth discussion. Tom > Joe From nobody Mon Mar 11 21:11:09 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF89130EB1 for ; Mon, 11 Mar 2019 21:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 0gFH3kQYQkbm for ; Mon, 11 Mar 2019 21:11:05 -0700 (PDT) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8E0130E7C for ; Mon, 11 Mar 2019 21:11:05 -0700 (PDT) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 7919E143DDA for ; Tue, 12 Mar 2019 00:11:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=LYA pxMmBXxuxcg9LwkkEqvO2wu8=; b=V4nHtvMWA5CktEQmdf9EV33vVgxgpzuDHSi iMgJQGE/pj4nTjPMXOQ0PvnFMJuCuXkBib0ba6nv13gvETAcufmurM5EbbUxZjJN 2lgYhrLHboF9/aChG/DtqUWkqryTl1U+ic4d9uiYd0jVM7zcJVeeRqcn9WKpCYOz HqVi8ias= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= KhL4Y86h/8qPNAq3sAnPHo8CBSlo1pOJnxl/rCp9aczj0sQ+VpI4kXCD0uFDlcYf SxOY1x6OcHyiomdNqP1OtTk3HPXYC9TsyV7PSzmV/LoNcr54nnd06ywMjt9yVN18 VTNrnNOpI3Ql3Z3Qm7TkzUmNfuLtOJdOaxysj3j5R3Q= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 714FF143DD9 for ; Tue, 12 Mar 2019 00:11:04 -0400 (EDT) Received: from mail-io1-f50.google.com (unknown [209.85.166.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 0AB7E143DD6 for ; Tue, 12 Mar 2019 00:11:04 -0400 (EDT) Received: by mail-io1-f50.google.com with SMTP id n11so916653ioh.1 for ; Mon, 11 Mar 2019 21:11:04 -0700 (PDT) X-Gm-Message-State: APjAAAWaQ0GYrHJ4OP24NK5YRMa2dufNu+zluCVugLbBSvAriENgBgjG bDtaNE6oFC0vGOUxARvjOyjIagcytyH80MPwlhw= X-Google-Smtp-Source: APXvYqy3Adsz/PRRm4B7+qxOBeLGVBdAxzG6K9tqKLOkqa/Eq5in8/NIE61sEexUPuwdumu+HwmdUFsmLH7lJPo33og= X-Received: by 2002:a5d:97c8:: with SMTP id k8mr19881604ios.267.1552363863521; Mon, 11 Mar 2019 21:11:03 -0700 (PDT) MIME-Version: 1.0 From: "C. M. Heard" Date: Mon, 11 Mar 2019 21:10:51 -0700 X-Gmail-Original-Message-ID: Message-ID: To: tsvwg Cc: Joe Touch Content-Type: multipart/alternative; boundary="000000000000a5c0fa0583dde0f8" X-Pobox-Relay-ID: DA4C1A7C-447C-11E9-95C4-F733E42159A7-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] Alternative version of the UDP FRAG option X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 04:11:07 -0000 --000000000000a5c0fa0583dde0f8 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 11, 2019 at 9:26 AM C. M. Heard wrote: > I'd like to float a different idea, namely, putting the UDP user data > inside the FRAG option itself. Well, that proposal was rather obviously flawed by limiting fragment sizes to ~240 bytes. My apologies. I withdraw the FRAG proposal in https://mailarchive.ietf.org/arch/msg/tsvwg/JZ8ohgwMs9eRPRQ6KJDqUZTJxSk However, I think that the following simpler version will actually work: maintain the format of the FRAG option as currently defined, but instead of having the option capture preceding conventional or LITE user data as fragment data, insist that it appear ***last*** in the option list and have it capture all remaining octets in the packet as fragment data. By convention, if this option appears, OCS would cover all UDP options as well as all octets in the UDP trailer that follow the FRAG option. The following requirements would apply: >> When the FRAG option appears, it MUST come last in the UDP options list. All remaining options in the packet are interpreted as fragment data. >> OCS, if present, covers both the FRAG option and the trailing fragment data. >> A host that wishes to signal that it is able to accept and process the FRAG option MAY do so by transmitting an unfragmented datagram with an empty terminal FRAG option whose Offset and Checksum fields are set to zero. >> Non-empty FRAG options MUST NOT be present in packets with ordinary UDP user data or LITE data. Any such options MUST be silently dropped. >> UDP options other than OCS and padding MUST NOT accompany the FRAG option in non-terminal fragments. Any such options MUST be silently dropped. All other options that apply to a reassembled packet must accompany the FRAG header in the terminal fragment. This proposal does not suffer from the disadvantage that a legacy receiver could misinterpret a UDP fragment as a complete datagram, as does the currently-defined version of FRAG without LITE. And it avoids the problem that OCS does not cover the currently defined version of FRAG+LITE. Note that because of their unusual property of capturing following or preceding data, FRAG and LITE would have to be mandatory to recognize, but I do not believe that they should be mandatory to generate or process. An implementation that cannot process these options should silently drop packets that contain them. There's probably something wrong; if so, please tell me what it is. Mike Heard --000000000000a5c0fa0583dde0f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 11, 2019 at 9:26 AM C. M. Heard <heard@pobox.com> wrote= :
> I'd like to float a different idea, namely, putting th= e UDP user data
> inside the FRAG option itself.
Well, that proposal was rather obviously flawed by limiting fra= gment
sizes to ~240 bytes. My apologies. I withdraw the FRAG prop= osal in


=
However, I think that the following simpler version will ac= tually work:
maintain the format of the FRAG option as currently = defined, but instead
of having the option capture preceding conve= ntional or LITE user data as
fragment data, insist that it appear= ***last*** in the option list and
have it capture all remaining = octets in the packet as fragment data. By
convention, if this opt= ion appears, OCS would cover all UDP options as
well as all octet= s in the UDP trailer that follow the FRAG option.

The following requirements would apply:

   >> When the FRAG option appears, it MUST come last in the UDP =
options
   list.  All remaining options in the packet are interpreted as fragment
   data.

   >> OCS, if present, covers both the =
FRAG option and the trailing
   fragment data.

   >> A host that wishes to signal that it i=
s able to accept and process
   the FRAG option MAY do so by transmitting an unfragmented datagram
   with an empty terminal FRAG option whose Offset and Checksum fields
   are set to zero.

>> Non= -empty FRAG options MUST NOT be present in packets with ordinary UDP user data or LITE data. Any such options MUST be silently dropped.

>> UDP options other than OCS= and padding MUST NOT accompany the FRAG option in non-terminal fragments. Any such options MUST be silently dropped. All other options that apply to a reassembled packet must accompany the FRAG header in the terminal fragment.

This proposal does not suffer from th= e disadvantage that a legacy receiver
could misinterpret a=C2=A0<= span style=3D"line-height:1.5">UDP fragment as a complete datagram, as does= the
currently-defined ver= sion of FRAG without LITE.=C2=A0 And it avoids the problem
=
that OCS does not cover the currently = defined version of FRAG+LITE.

Note that bec= ause of their unusual property of capturing following or
precedin= g data, FRAG and LITE would have to be mandatory to
recognize, bu= t I do not believe that they should be mandatory to
generate or p= rocess. An implementation that cannot process these
options shoul= d silently drop packets that contain them.

There&#= 39;s probably something wrong; if so, please tell me what it is.
=
Mike Heard
--000000000000a5c0fa0583dde0f8-- From nobody Mon Mar 11 21:38:10 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E83130E6F for ; Mon, 11 Mar 2019 21:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 R7vHVRL_KLDB for ; Mon, 11 Mar 2019 21:38:07 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 269CA130EB2 for ; Mon, 11 Mar 2019 21:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=94i/URw7xE0+lZDehLmQ0OIKdTW7GhPu1jWJjIGAL2c=; b=ZVCj5quw8OAWW052Ae+hM4xZ7 /qCNATQiV1xRp7HUTwI52o0IqcgsFdoJqpmgtfW3ts+hHm6ReCfjlxs3dcVMqjzmFPc/6EI3/qbP+ qAnAP+UR11s5Tb+ecnPZR9Mdl/ZSYbXlG6FzforQsejSgHGOVvdMR6oFc8pMquSGJhGNx+XuDR3n1 M7cvrEGUO04obIaQ2nbLKZLsEVYrCUayOIOL50/xRp8wCzfbXY55wP/AaHVKV0gAy9vnwUI720H5q fgivtn2VO6LlvRGBN8qSkb3rjHIKz1pxmGx5aR0wWm3OuOCKk1IpV4EfcmaFotU0LL35YxmFDLjF+ Tn3IhT9og==; Received: from [172.58.185.254] (port=56184 helo=[IPv6:2607:fb90:6495:f38:e440:2e8:a9c0:df98]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3ZAz-001ZP5-Mi; Tue, 12 Mar 2019 00:38:06 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Tue, 12 Mar 2019 00:38:04 -0400 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <077795C0-ED8F-4F19-ACB9-75E3D65EF737@strayalpha.com> References: To: Tom Herbert X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 04:38:08 -0000 > On Mar 11, 2019, at 11:34 PM, Tom Herbert wrote: >=20 > That's more an argument that UDP checksums should not be zero, We tried to force that with IPv6 then realized it isn=E2=80=99t what we want= ed.=20 Same logic applies here for the same reason.=20 Joe=20= From nobody Mon Mar 11 21:44:44 2019 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF0312867A for ; Mon, 11 Mar 2019 21:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 BHbKv0OI0oQi for ; Mon, 11 Mar 2019 21:44:42 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 F23E51277C9 for ; Mon, 11 Mar 2019 21:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LZ6dGWqrv3Kr7pgCX0lhLr/lKE/FOLAZ0D5ZN7+xisk=; b=tjt7f/fpPspBGgWSW+JTyoxwz xtBN5ydNR2nCeu+c9HV4hr9V+Wif7YQSziZZvJhtz8LyKlDs+8ThvBlMndqpRR1alLbwW52pRiuxp 3ZibAxAKP0SQ+DeMPY1k5fuMCGw8sI7ZYJKJTX+1zOuv9pSEGPBTvssspr6CsDHYwp9FWIlWzEeOW M6hb6raTyCg294wUWGTTLk0FiQf+VjLkbDTkTWmrsej+IychCoxr2R6cfZSf43YCs/+GnTVu1PYOl bztw+mgWkPdhDsjfFwFrYaiYaHt4+0GazHVhx1nT1n+7qANG3gMQQTkDPsoHXz+84lR45ScFA9y3Z hPHqaFW2A==; Received: from [172.58.185.254] (port=35243 helo=[IPv6:2607:fb90:6495:f38:e440:2e8:a9c0:df98]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3ZHL-001iCY-9I; Tue, 12 Mar 2019 00:44:40 -0400 Content-Type: multipart/alternative; boundary=Apple-Mail-28E081DD-89E2-4CED-B1D5-8408467003B9 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Tue, 12 Mar 2019 00:44:38 -0400 Cc: tsvwg Content-Transfer-Encoding: 7bit Message-Id: <2C035E8C-A59F-4523-9B8D-BBA573C6DEFB@strayalpha.com> References: To: "C. M. Heard" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Alternative version of the UDP FRAG option X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 04:44:43 -0000 --Apple-Mail-28E081DD-89E2-4CED-B1D5-8408467003B9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Frag+lite can still be checksummed after reassembly as is. We don=E2=80=99t w= ant or need to do that check twice and can=E2=80=99t usefully string togethe= r partial sums.=20 Joe > On Mar 12, 2019, at 12:10 AM, C. M. Heard wrote: >=20 > On Mon, Mar 11, 2019 at 9:26 AM C. M. Heard wrote: > > I'd like to float a different idea, namely, putting the UDP user data > > inside the FRAG option itself. >=20 > Well, that proposal was rather obviously flawed by limiting fragment > sizes to ~240 bytes. My apologies. I withdraw the FRAG proposal in >=20 > https://mailarchive.ietf.org/arch/msg/tsvwg/JZ8ohgwMs9eRPRQ6KJDqUZTJxSk >=20 > However, I think that the following simpler version will actually work: > maintain the format of the FRAG option as currently defined, but instead > of having the option capture preceding conventional or LITE user data as > fragment data, insist that it appear ***last*** in the option list and > have it capture all remaining octets in the packet as fragment data. By > convention, if this option appears, OCS would cover all UDP options as > well as all octets in the UDP trailer that follow the FRAG option. >=20 > The following requirements would apply: >=20 > >> When the FRAG option appears, it MUST come last in the UDP options > list. All remaining options in the packet are interpreted as fragment > data. >=20 > >> OCS, if present, covers both the FRAG option and the trailing > fragment data. >=20 > >> A host that wishes to signal that it is able to accept and process > the FRAG option MAY do so by transmitting an unfragmented datagram > with an empty terminal FRAG