From nobody Wed Aug 9 13:10:14 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE7F1324C0 for ; Wed, 9 Aug 2017 13:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojr4qZMSiKnl for ; Wed, 9 Aug 2017 13:10:11 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 1B6C31324BE for ; Wed, 9 Aug 2017 13:10:10 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-05-598b6c212e6c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.EA.06959.12C6B895; Wed, 9 Aug 2017 22:10:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Wed, 9 Aug 2017 22:10:08 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: ICE WG CC: Peter Thatcher , "fandreas@cisco.com" Thread-Topic: Draft ICE WG meeting minutes from IETF 99 Thread-Index: AdMRS39wrED8grWGSqiQjtB3Dm7KhQ== Date: Wed, 9 Aug 2017 20:10:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-711E6979-1916-4676-810A-6AC82F9C58EA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2K7ja5iTnekwY/j4hbvL+hafLtQa3Ft +WtWB2aPKb83snos2FTqsWTJT6YA5igum5TUnMyy1CJ9uwSujO0Nx1gLFrpW/PtyiL2B8ZpT FyMnh4SAicSj/omMXYxcHEICRxglJmyaAuUsYpT4/ewOO0gVm4CtxJPWfawgtoiApETLn41g NrNAmMSehWeZQGxhASOJlc3bGSFqzCXW317KDmHrSfzvusHcxcjBwSKgIvF4mQxImFfAXuLU //9sIDajgJjE91NrmCBGikvcejKfCeI4EYmHF0+zQdiiEi8f/2MFuY1ZYDKjxIsVx1kgBglK nJz5hGUCo+AsJP2zkNXNQlIHURQvcWzNGmYIW15i+9s5QDYHkK0jMXkhI0RYW2LZwtdQJRoS nd8msqIqB7GtJWb8OsgGYZtKvD76EapXUWJK90P2BYw8qxhFi1OLi3PTjYz0Uosyk4uL8/P0 8lJLNjEC4/Lglt9WOxgPPnc8xCjAwajEw1v/oitSiDWxrLgy9xCjCtCcRxtWX2CUYsnLz0tV EuGNSemOFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJanZqakFqEUyWiYNTqoHR 98uvjes+i6svZ/wxPWQ666cCiyOP3i96vM6swa+IYXXZRsbNmUxXo32FS/d23ZiS28Xzt92+ Tjb26jT3vw8D89ayLImv6DI/KTflzw3dvA2PArelfd/x5pHBKq3dP+1vH1FMTb9YzBHwtKPM /d+Mgt1P1GPjHy7OfslfYp68zpQjZXHX/a9PlViKMxINtZiLihMBoZGWp9MCAAA= Archived-At: Subject: [Ice] Draft ICE WG meeting minutes from IETF 99 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 20:10:13 -0000 --Apple-Mail-711E6979-1916-4676-810A-6AC82F9C58EA Content-Type: multipart/alternative; boundary=Apple-Mail-93901AF2-B025-404A-8B7D-374E63A4B19C Content-Transfer-Encoding: 7bit --Apple-Mail-93901AF2-B025-404A-8B7D-374E63A4B19C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The draft meeting minutes from the IETF 99 ICE meeting are available here: https://datatracker.ietf.org/meeting/99/materials/minutes-99-ice Please review the minutes and let us know if you have any questions or comme= nts. Thanks, Ari= --Apple-Mail-93901AF2-B025-404A-8B7D-374E63A4B19C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
The draft meeting minutes from the IETF 99 ICE meeting are available here:
https://datatracker.ietf.org/meeting/99/materials/minutes-99-ice

Please review the minutes and let us know if you have any questions or comments.


Thanks,
Ari
--Apple-Mail-93901AF2-B025-404A-8B7D-374E63A4B19C-- --Apple-Mail-711E6979-1916-4676-810A-6AC82F9C58EA Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR5DCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF6jCCA9KgAwIBAgIRAPoMA5z/l/RYsixy5v8S2z8w DQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjAyMTQ1NjQyWhcNMTcxMjAyMTQ1NjQxWjBlMREwDwYD VQQKDAhFcmljc3NvbjEVMBMGA1UEAwwMQXJpIEtlcsOkbmVuMScwJQYJKoZIhvcNAQkBFhhhcmku a2VyYW5lbkBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VhcmlrZXIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCJDr/JbhnJ9M4/bnGBCyYu4s57UPPPpoDmq/xpr5fvMANbVM0+weVHISM3 bk56dTvelI8wz/B7TpYZ60QP2XA7pZhJcRbr3M0fuyES/sTehYWRnEt6Zv+UHqV1U1Fzd+Y9zwAi 9smZvU7/DWHrylywwb/MJMMcSnwr1DDII/ZZcFRwFxnefrsW5JZzGEktM5JzEyJeBvMzLnfnxlRU ZnBKmjWHo6+NY0zGE/av3O9VT6tWKewgurAHciLqBK4yF6reffE2e+k+GPmcODoeAdTZb82sT8qh ilGGjHJL/0yBghdLIcpq7iajSEcCCPQ0PDOTjk5hz+kHWR56vuD6pPkTAgMBAAGjggG+MIIBujBI BgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3Nw Mi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVy YS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjAjBgNVHREEHDAagRhhcmkua2VyYW5l bkBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYI KwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBRO3s66I+x4qLz+nDBzngqpTuX64DAfBgNVHSME GDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQAD ggIBAFYpgmqF4ZIcZkZLtjukdgdQj1wxRgeaGAiguqpZxuR4YOq8exKpgAIA5m3FZ+icGCVY2DYa nwzP+5+IKjvjspD5hb3J+fY1egdVgcq5ku2DDG2ReJ0dp39XFAksNEJ8Z5O/QHEXy4X7TmFamArH WJEHkd690X6pvnkdwJXD+TnIUr5l42cjgUkKEPg0g+2Kgdp1NGdoFbCtuwrUtZpBgu0VEVQfq5qo dINAXqciN3C0qf3gwu3bvQixCPvaq8M4eTdda3Dun5bSbQPLpZtIw3Kw0RqH2CnR8+zyFuKsrnKo 4Sn66D0h/YoVkeAoLAlmSGH/dYgWIVlqxXZR8302DHjWWWxl7bwKMDnD3uq2dnzoNpO8TmTc0O/l RqEFHZvEPOe+JkWPCFQ9KZhcl9qcodbVKilY+Yhndh73O8VJRtg15NSzFNuNiS7PjkGuTNYhK/be ztgM3DH8vftAtvQCg2O6rYShT11RMiIjn7aCIhpkqJLltBiX3aAbT6FXXi7mEtbN83tDKp2Izn42 bcqOJdk9b/5OEP8NMPGXIlVNZY/yFvumhLKy1T7Go8rQRe2OB+D6MxEVpHSGZ2UIycyMV2VpPyVM pbcM8/vz6xDPay+f8lwFjcRM90lLBJh4RACNs0Ya8ncPGYY0LnFegBPrBrzQF82UPstkRx/iy0P2 52avMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIG A1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQw NTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoC ggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJh rhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLd aIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P5 4ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO 8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwz GAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7i rYUYFpq4TyocQ7qpHdYASC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+ j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPW Ie57lyj0n3e1rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/ W5kpAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2Nz cC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAG AQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmww HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU sQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJ KoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py 9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdB ihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5Ux WdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QT KDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG 2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8 sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH 3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYm p7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZ dDq1kIHIw0vF4PBTVMZtMYICmTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UE AwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAPoMA5z/l/RYsixy5v8S2z8wCQYFKw4D AhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODA5 MjAxMDA2WjAjBgkqhkiG9w0BCQQxFgQUMEIYDdadlNJUGIVLY1GuvZwJp1wwXgYJKwYBBAGCNxAE MVEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIRAPoMA5z/l/RYsixy5v8S2z8wYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA+gwDnP+X 9FiyLHLm/xLbPzANBgkqhkiG9w0BAQEFAASCAQB4zkG4JoGO3VwAPunhspm+h3AZ4fHOKtwj2agS GBRgzjfPD4OwgjNEDmvE05jbESwymINd2LGY9KP7N5MntkMSjw6adkn7YgTp5MiEaNsipVpGsRN6 bp/WfPkSqy03BZPDEFNvEHG/N911QuNDjQbwxs+b3/BPM+toSNulgbfcW6yhhio97+mUqKv/k7sC oY0rPMrPF+ZV2Bni/9myHL4nyXiM5h62dxKt0aK55m43nL1VxQPiNG7p67CR77N5NJqWPSouF8kq cJ7RkKCFFJlq1GocjzGX1Uy6C0vM79xwGDB+SPJXOfpnhljeR55nYRzP0Qck0oHStsDHraHB4CAd AAAAAAAA --Apple-Mail-711E6979-1916-4676-810A-6AC82F9C58EA-- From nobody Wed Aug 30 08:19:17 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FB01320D8 for ; Wed, 30 Aug 2017 08:19:15 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 cpJB4LwUoPAl for ; Wed, 30 Aug 2017 08:19:12 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 E401E120721 for ; Wed, 30 Aug 2017 08:19:11 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id v29so28505474qtv.3 for ; Wed, 30 Aug 2017 08:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0fQt5nD9JVYrPf21gBPWa7Fr8lGlBulPucrB7Kvhz8Q=; b=CoOiucwhMIZMDTbzBBMjwU3rIP67Lk7iyxFWvWuXmdh8In9NXYRo6ktxITlnU9TSRo XiLdeHlOja2QiDvHZtWRBuOe5rKHJMRouH8DjbnmZp1I8bYB8d2DyU4aqNdZl5yzyOiV 2lOa2od+L99/DCqLOtU0WIaWqQ0g3L0u0tL9CMwc/bgvEhA2eOcahUqV0UmZLwqs+YF7 z65cXC5uVC1UiwUxElsV1r8KoJjfEuHee387y9C45wCuS+QVed0bF7Ht4P8RgPnDG/i6 0pK1A40Ljjsu9e3AzB1TAXCcISToapvMkhDj2Oxf7vXcINXJ8rLCUNOI9q8o/j4UH2Qr Mt0A== 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=0fQt5nD9JVYrPf21gBPWa7Fr8lGlBulPucrB7Kvhz8Q=; b=PX+kGTOY733TPN8k8+9B0V/MpVpWtuRrqXITHGav8yfpAHNg/f/MqOe6KiYrxAtIIf UgzNS4UtQU3/8BcUXM3P1PomeF0uIRI0oeLtSjnuCbvKEVb6MlEqwMMko/XYis6fmTgS 2nY8kZmQOqrU7Ugh45ebKWgaiTMJo89khT4u/E44VfN+CKzhKb1L3JRdcDV/oRmYZJnr huPVradA5X5Ph3wQ/BanShVvVsjNl/x565LrmFzYaBhEPuyn9PgvI/Qm45l1Ha8Qndds yVv45McY5wLmu8KaTlGd0aUGWt9tMhmShslkrUs6gYxVUeXId0iKPk6CbFd8KnLh7RMx +mbw== X-Gm-Message-State: AHYfb5jm2azZpX3OY/wn9lq254JrtynTaGNu+a+OH3KvSaoZO19aYvii FG6ClYz4XGju+jo6614eFPADjZVCZdEL10M= X-Google-Smtp-Source: ADKCNb5yQHeq6IliiFD/54dxDy40D0RZtz0BsCobl+JXql4vFDLYHS/qrlTBb9CjpWG1e4rcbU96vYESxcZo1XtVe3c= X-Received: by 10.200.15.236 with SMTP id f41mr2378422qtk.115.1504106350806; Wed, 30 Aug 2017 08:19:10 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> From: Peter Thatcher Date: Wed, 30 Aug 2017 15:19:00 +0000 Message-ID: To: Christer Holmberg , Bernard Aboba Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a1148acb0bf20800557fa0cab" Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:19:15 -0000 --001a1148acb0bf20800557fa0cab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable #2 and #3 are fine, but I'm not a fan of #1. Your reasoning for saying that an agent can't switch candidate pairs is that it prevents the remote side from being able to release resources. But the switching side would only switch if the candidate pair recently received an ICE check response (in other words, it knows the candidate pair works), in which case it knows that resources have not been released. In other words, if the remote side chose to release resources, the local side wouldn't do the switch. So the remote side is free to release resources; it's not prevented from doing so. If it does, then the local side will notice and not do a switch. But if the remote side doesn't release the resources, then the local side may switch. In other words, I think we can allow switching and resource release both. On Thu, Jul 27, 2017 at 4:01 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Would anyone disagree with the following: > > > > 1) explicitly indicating that re-nomination is **NOT** allowed > without ICE restart; and > > 2) once a pair has been selected, agents need to be able to send * > *AND** receive media using that pair =E2=80=93 but not using any other pa= ir > (read: resources associated with other pairs may be released); and > > 3) PRIOR to selection, agents need to be able to send **AND** > receive media on any valid pair (RFC 7675 adds restrictions, but that=E2= =80=99s > outside the scope of 5245bis) > > > > Regards, > > > > Christer > > > > *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Christer Holmber= g > *Sent:* 25 July 2017 10:17 > *To:* Bernard Aboba > *Cc:* ice@ietf.org > *Subject:* Re: [Ice] Re-nomination and candidate pair switching in RFC > 5245bis > > > > Hi Bernard, > > > > Regarding sending media PRIOR to nomination, we have previously agreed > that any valid pair can be used for that. Perhaps it needs more > clarification. > > > > Regarding receiving media after nomination, it was discussed in Prague, a= s > it is covered by Peter=E2=80=99s PR. I don=E2=80=99t have access to the P= R/minutes right > now, but I think the outcome was that an agent is only expected to receiv= e > media on the nominated pair (otherwise it cannot free resources). > > > > Regards, > > > > Christer > > > > *From:* Bernard Aboba [mailto:bernard.aboba@gmail.com > ] > *Sent:* 25 July 2017 02:29 > *To:* Christer Holmberg > *Cc:* ice@ietf.org > *Subject:* Re: [Ice] Re-nomination and candidate pair switching in RFC > 5245bis > > > > Christer said: > > > > "The whole discussion began when I was given a comment that the text abov= e > should be modified, to clarify that the pair used for media can change > after a pair has been selected. > > But, if the outcome is that the pair can NOT change, maybe we need to > clarify THAT instead :)" > > > > [BA] Currently, use of the "ice2" ICE option forestalls use of aggressive > nomination (e.g. setting the nominated flag on more than one pair). Sinc= e > only the selected pair can be used to send media, that would seem to rule > out changing the pair used for media after a pair has been selected: > > > > Once a candidate pair has been selected > > only that candidate pair (referred to as selected pair) is used for > > sending media. > > > > What about changing the pair used for media prior to selection? On this > point, the text seems less clear than it could be. > > > > Prior to nomination, the specification allows the sending of media on a > successful pair: > > > > o Once there is at least one nominated pair in the VALID LIST for > > every component of at least one media stream and the state of the > > CHECK LIST is Running: > > > > ... > > > > * The agent MUST continue to respond to any checks it may still > > receive for that media stream, and MUST perform triggered > > checks if required by the processing of Section 6.3 . > > > > * The agent MAY begin transmitting media for this media stream as > > described in Section 11.1 > . > > > > However, the specification is not clear enough about the receiving side; > while it recommends that implementations be prepared to receive prior to > nomination, it does not require this. From Section 11.2: > > > > ICE implementations SHOULD by default be > > prepared to receive media on any of the candidates provided in the > > most recent candidate exchange with the peer. > > > > What happens if an implementation is NOT prepared to receive media? > > In WebRTC, an implementation cannot send without consent, which > > suggests that perhaps an unwilling receiver could use consent to > > influence the potential sender. > > > > However, the specification does not even reference RFC 7675, > > so it is left unclear about how this is to be done. > > For example, a receiver might not reply to a consent > > request if the inability to receive is temporary ("I'm not ready yet"), > > but that might cause consent to time out prior to nomination and > > might even influence pair selection inappropriately. > > > > Another choice might be to revoke consent (which would > > invalidate the pair). But that's pretty drastic unless the > > pair is truly unacceptable. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected pair= : > > > > Eventually, there will be only a single nominated pair in the VALID > > LIST for each component. Once the state of the CHECK LIST is set to > > Completed, that exact pair is selected by ICE for sending and > > receiving media for that component. > > > >Based on that text, an implementation might still release resources (e.g= . > unused TURN candidates) post-nomination. Given this, the "ice2" ICE optio= n > doesn't address >potential interoperability issues resulting from differe= nt > resource release behaviors (although it does clear indicate lack of suppo= rt > for aggressive nomination): > > The whole discussion began when I was given a comment that the text above > should be modified, to clarify that the pair used for media can change > after a pair has been selected. > > But, if the outcome is that the pair can NOT change, maybe we need to > clarify THAT instead :) > > > NOTE: A controlling agent that does not support this specification > > (i.e. it is implemented according to RFC 5245) might nominate more > > than one candidate pair. This was referred to as aggressive > > nomination in RFC 5245. The usage of the 'ice2' ice option by > > endpoints supporting this specifcation should prevent such > > controlling agents from using aggressive nomination. > > > >Christer also said: > > > >"Also, my understanding was that endpoints supporting RFC 7675 might > maintain consent on pairs currently not > >used for media, in order to be able to re-nominate in case consent for > the currently nominated pair expires. However, > >RFC 7675 does not explicitly say anything about that." > > > >[BA] RFC 7675 Section 5 says: > > > > Initial consent to send traffic is obtained using ICE [RFC5245]. An > > endpoint gains consent to send on a candidate pair when the pair > > enters the Succeeded ICE state. > > > >Given this, an RFC 5245bis implementation might request consent to send = to > >multiple remote peer candidates, so as to keep them alive. However, > >there is nothing in RFC 7675 that requires the responder to grant > >consent for that. For example, based on the text in RFC 5245bis > >Section 7.1.1, a conforming implementation might well revoke > >consent on local candidates other than the local candidate in the > >selected pair. > > Sure - the responder is not mandated to grant consent to multiple > candidates after nomination. But, the option to do seems to be there > (unless I've understood the RFC wrong), and the only reason to do so woul= d > be possible re-nomination. > > Anyway, I don't have any strong feelings which way we go, but we do need > to make it clear in the spec whether re-nomination is allowed or not. > > Regards, > > Christer > > > > On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi > , > >[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected pair= : > > > > Eventually, there will be only a single nominated pair in the VALID > > LIST for each component. Once the state of the CHECK LIST is set to > > Completed, that exact pair is selected by ICE for sending and > > receiving media for that component. > > > >Based on that text, an implementation might still release resources (e.g= . > unused TURN candidates) post-nomination. Given this, the "ice2" ICE optio= n > doesn't address >potential interoperability issues resulting from differe= nt > resource release behaviors (although it does clear indicate lack of suppo= rt > for aggressive nomination): > > The whole discussion began when I was given a comment that the text above > should be modified, to clarify that the pair used for media can change > after a pair has been selected. > > But, if the outcome is that the pair can NOT change, maybe we need to > clarify THAT instead :) > > > NOTE: A controlling agent that does not support this specification > > (i.e. it is implemented according to RFC 5245) might nominate more > > than one candidate pair. This was referred to as aggressive > > nomination in RFC 5245. The usage of the 'ice2' ice option by > > endpoints supporting this specifcation should prevent such > > controlling agents from using aggressive nomination. > > > >Christer also said: > > > >"Also, my understanding was that endpoints supporting RFC 7675 might > maintain consent on pairs currently not > >used for media, in order to be able to re-nominate in case consent for > the currently nominated pair expires. However, > >RFC 7675 does not explicitly say anything about that." > > > >[BA] RFC 7675 Section 5 says: > > > > Initial consent to send traffic is obtained using ICE [RFC5245]. An > > endpoint gains consent to send on a candidate pair when the pair > > enters the Succeeded ICE state. > > > >Given this, an RFC 5245bis implementation might request consent to send = to > >multiple remote peer candidates, so as to keep them alive. However, > >there is nothing in RFC 7675 that requires the responder to grant > >consent for that. For example, based on the text in RFC 5245bis > >Section 7.1.1, a conforming implementation might well revoke > >consent on local candidates other than the local candidate in the > >selected pair. > > Sure - the responder is not mandated to grant consent to multiple > candidates after nomination. But, the option to do seems to be there > (unless I've understood the RFC wrong), and the only reason to do so woul= d > be possible re-nomination. > > Anyway, I don't have any strong feelings which way we go, but we do need > to make it clear in the spec whether re-nomination is allowed or not. > > Regards, > > Christer > > > > > > On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > Hi Bernard, > > Support of 5245bis is also negotiated, using the =E2=80=9Cice2=E2=80=9D I= CE option. > > Also, my understanding was that endpoints supporting RFC 7675 might > maintain consent on pairs currently not used for media, in order to be ab= le > to re-nominate in case consent for the currently nominated pair expires. > However, RFC 7675 does not explicitly say anything about that. > > Regards, > > Christer > > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: 20 July 2017 14:22 > To: ice@ietf.org > Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis > > During the ICE WG meeting today, there was discussion of whether > RFC5245bis should indicate that it is possible to re-nominate pairs > (proposed by Peter), or whether it is possible to switch from one interfa= ce > to another (Cullen). While these capabilities are desirable, attempting = to > add them to RFC 5245bis without negotiation has the potential to break > interoperability with existing RFC 5245 implementations. > > In my experience, this is an area where RFC 5245 implementations have ver= y > different interpretations. For example, some implementations (e.g. ones > that did not support aggressive) discard non-selected candidate pairs aft= er > nomination. These implementations (e.g. particularly ones included in > previous product releases) cannot be assumed to change their behavior aft= er > RFC 5245bis is published. This raises the possibility that that > interoperability could be impacted. > > Since in practice the desired candidate pair switching capabilities are > most likely to be supported in WebRTC implementations supporting Trickle > ICE, my recommendation is to think of candidate pair switching as a Trick= le > ICE capability. Since Trickle-ICE support is negotiated, clarifications > relating to candidate-pair switching can be linked to that negotiation. > > This provides a potential way forward that bypasses potential > interoperability issues. For example, if text on candidate-pair switchin= g > is to be added to (either to RFC 5245bis or Trickle-ICE) then the text > could say that support for these behaviors can only be assumed if they ar= e > explicitly negotiated. The Trickle-ICE document could then create normati= ve > requirements for support of the new behaviors by stating that support for > them is mandatory when supporting full-Trickle. > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a1148acb0bf20800557fa0cab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
#2 and #3 are fine, but I'm not a fan of #1.

<= /div>
Your reasoning for saying that an agent can't switch candidat= e pairs is that it prevents the remote side from being able to release reso= urces.=C2=A0 But the switching side would only switch if the candidate pair= recently received an ICE check response (in other words, it knows the cand= idate pair works), in which case it knows that resources have not been rele= ased.

In other words, if the remote side chose to = release resources, the local side wouldn't do the switch.=C2=A0 So the = remote side is free to release resources; it's not prevented from doing= so.=C2=A0 If it does, then the local side will notice and not do a switch.= =C2=A0 But if the remote side doesn't release the resources, then the = local side may switch.

In other words, I think we = can allow switching and resource release both.=C2=A0

On Thu, Jul 27, 2017 at 4:01 AM Christe= r Holmberg <christer.h= olmberg@ericsson.com> wrote:

Hi,

=C2=A0

Would anyone disagree with the follow= ing:

=C2=A0

<= span>1)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 explicitly indicating that re-no= mination is *NOT* allowed without ICE restart; and

<= span>2)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 once a pair has been selected, a= gents need to be able to send *AND* receive media using that pair = =E2=80=93 but not using any other pair (read: resources associated with other pairs may be release= d); and

<= span>3)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 PRIOR to selection, agents need = to be able to send *AND* receive media on any valid pair (RFC 7675 a= dds restrictions, but that=E2=80=99s outside the scope of 5245bis)

=C2=A0

Regards,

=C2=A0

Christer

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: = Ice [mailto:ice-b= ounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 25 July 2017 10:17
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: ice@ietf.org
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC= 5245bis

=C2=A0

Hi Bernard,

=C2=A0

Regarding sending media PRIOR to nomi= nation, we have previously agreed that any valid pair can be used for that.= Perhaps it needs more clarification.

=C2=A0

Regarding receiving media after nomin= ation, it was discussed in Prague, as it is covered by Peter=E2=80=99s PR. = I don=E2=80=99t have access to the PR/minutes right now, but I think the outcome was that an agent is only ex= pected to receive media on the nominated pair (otherwise it cannot free res= ources).

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Bernard Aboba [mailto:bernard.aboba@gmail.com]
Sent: 25 July 2017 02:29
To: Christer Holmberg <christer.holmberg@ericsson= .com>
Cc: ice@ietf.org
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC= 5245bis

=C2=A0

Christer said:=C2=A0

=C2=A0

"The whole disc= ussion began when I was given a comment that the text above should be modif= ied, to clarify that the pair used for media can change after a pair has be= en selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)"=C2=A0

=C2=A0

[BA]=C2=A0Currently,= use of the "ice2" ICE option forestalls use of aggressive nomina= tion (e.g. setting the nominated flag on more than one pair).=C2=A0 Since o= nly the selected pair can be used to send media, that would seem to rule out changing the pair used for media after a pair has been se= lected:=C2=A0

=C2=A0

=C2=A0=C2=A0 Once a candidate pair has bee=
n selected
=C2=A0=C2=A0 only that candidate pair (ref=
erred to as selected pair) is used for
=C2=A0=C2=A0 sending media.<=
/span>

=C2=A0

What about changing the pair used for media prior to= selection?=C2=A0 On this point, the text seems less clear than it could be= .=C2=A0

=C2=A0

Prior to nomination,= the specification allows the sending of media on a successful pair:=

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Once there is at leas=
t one nominated pair in the VALID LIST for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 every compo=
nent of at least one media stream and the state of the=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHECK LIST =
is Running:
=C2=A0
...
=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*=C2=
=A0 The agent MUST continue to respond to any checks it may still=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 receive for that media stream, and MUST perform triggered<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 checks if required by the processing of Section 6.3.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 The=
 agent MAY begin transmitting media for this media stream as=C2=A0

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0described in Section 11= .1.

=C2=A0

However, the specifi= cation is not clear enough about the receiving side; while it recommends th= at implementations be prepared to receive prior to nomination, it does not = require this.=C2=A0From Section 11.2:=C2=A0

=C2=A0

=C2=A0=C2=A0 ICE implementations SHOULD by=
 default be
=C2=A0=C2=A0 prepared to receive media on =
any of the candidates provided in the
=C2=A0=C2=A0 most recent candidate exchang=
e with the peer.
=C2=A0
What happens if an implementation is NOT p=
repared to receive media?
In WebRTC, an implementation cannot send w=
ithout consent, which 
suggests that perhaps an unwilling receive=
r could use consent to
influence the potential sender. =

=C2=A0
However, the specification does not even r=
eference RFC 7675,
so it is left unclear about how this is to=
 be done.
For example, a receiver might not reply to=
 a consent
request if the inability to receive is tem=
porary ("I'm not ready yet"),
but that might cause consent to time out p=
rior to nomination and
might even influence pair selection inappr=
opriately.
=C2=A0
Another choice might be to revoke consent =
(which would
invalidate the pair).=C2=A0 But that's=
 pretty drastic unless the
pair is truly unacceptable. =

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

>[BA] RFC 5245bis Section 7.1.1 continues to = imply a single selected pair:=C2=A0
>
>=C2=A0 =C2=A0Eventually,= there will be only a single nominated pair in the VALID
>=C2=A0 =C2=A0LIST for ea= ch component.=C2=A0 Once the state of the CHECK LIST is set to
>=C2=A0 =C2=A0Completed, = that exact pair is selected by ICE for sending and
>=C2=A0 =C2=A0receiving m= edia for that component.
>
>Based on that text, an i= mplementation might still release resources (e.g. unused TURN candidates) p= ost-nomination. Given this, the=C2=A0"ice2" ICE option doesn'= t address >potential interoperability issues resulting from different re= source release behaviors (although it does clear indicate lack of support for agg= ressive nomination):=C2=A0

The whole discussion began when I was given a comment that the text above s= hould be modified, to clarify that the pair used for media can change after= a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)

>=C2=A0 =C2=A0NOTE: A con= trolling agent that does not support this specification
>=C2=A0 =C2=A0(i.e. it is= implemented according to RFC 5245) might nominate more
>=C2=A0 =C2=A0than one ca= ndidate pair.=C2=A0 This was referred to as aggressive
>=C2=A0 =C2=A0nomination = in RFC 5245.=C2=A0 The usage of the 'ice2' ice option by
>=C2=A0 =C2=A0endpoints s= upporting this specifcation should prevent such
>=C2=A0 =C2=A0controlling= agents from using aggressive nomination.
>
>Christer also said:=C2= =A0
>
>"Also, my understan= ding was that endpoints supporting RFC 7675 might maintain consent on pairs= currently not
>used for media, in order= to be able to re-nominate in case consent for the currently nominated pair= expires. However,
>RFC 7675 does not explic= itly say anything about that."
>
>[BA] RFC 7675 Section 5 = says:=C2=A0
>
>=C2=A0 =C2=A0Initial con= sent to send traffic is obtained using ICE [RFC5245].=C2=A0 An
>=C2=A0 =C2=A0endpoint ga= ins consent to send on a candidate pair when the pair
>=C2=A0 =C2=A0enters the = Succeeded ICE state.
>
>Given this, an RFC 5245b= is implementation might request consent to send to
>multiple remote peer can= didates, so as to keep them alive. However,
>there is nothing in RFC = 7675 that requires the responder to grant
>consent for that.=C2=A0 = For example, based on the text in RFC 5245bis
>Section 7.1.1, a conform= ing implementation might well revoke
>consent on local candida= tes other than the local candidate in the
>selected pair.
Sure - the responder is not mandated to grant consent to multiple candidate= s after nomination. But, the option to do seems to be there (unless I'v= e understood the RFC wrong), and the only reason to do so would be possible= re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do nee= d to make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer

=C2=A0

On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi
,
>[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected pai= r:=C2=A0
>
>=C2=A0 =C2=A0Eventually, there will be only a single nominated pair in = the VALID
>=C2=A0 =C2=A0LIST for each component.=C2=A0 Once the state of the CHECK= LIST is set to
>=C2=A0 =C2=A0Completed, that exact pair is selected by ICE for sending = and
>=C2=A0 =C2=A0receiving media for that component.
>
>Based on that text, an implementation might still release resources (e.= g. unused TURN candidates) post-nomination. Given this, the=C2=A0"ice2= " ICE option doesn't address >potential interoperability issues= resulting from different resource release behaviors (although it does clear indicate lack of support for aggressive nomination):=C2=A0
The whole discussion began when I was given a comment that the text above s= hould be modified, to clarify that the pair used for media can change after= a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)

>=C2=A0 =C2=A0NOTE: A controlling agent that does not support this speci= fication
>=C2=A0 =C2=A0(i.e. it is implemented according to RFC 5245) might nomin= ate more
>=C2=A0 =C2=A0than one candidate pair.=C2=A0 This was referred to as agg= ressive
>=C2=A0 =C2=A0nomination in RFC 5245.=C2=A0 The usage of the 'ice2&#= 39; ice option by
>=C2=A0 =C2=A0endpoints supporting this specifcation should prevent such=
>=C2=A0 =C2=A0controlling agents from using aggressive nomination.
>
>Christer also said:=C2=A0
>
>"Also, my understanding was that endpoints supporting RFC 7675 mig= ht maintain consent on pairs currently not
>used for media, in order to be able to re-nominate in case consent for = the currently nominated pair expires. However,
>RFC 7675 does not explicitly say anything about that."
>
>[BA] RFC 7675 Section 5 says:=C2=A0
>
>=C2=A0 =C2=A0Initial consent to send traffic is obtained using ICE [RFC= 5245].=C2=A0 An
>=C2=A0 =C2=A0endpoint gains consent to send on a candidate pair when th= e pair
>=C2=A0 =C2=A0enters the Succeeded ICE state.
>
>Given this, an RFC 5245bis implementation might request consent to send= to
>multiple remote peer candidates, so as to keep them alive. However,
>there is nothing in RFC 7675 that requires the responder to grant
>consent for that.=C2=A0 For example, based on the text in RFC 5245bis >Section 7.1.1, a conforming implementation might well revoke
>consent on local candidates other than the local candidate in the
>selected pair.

Sure - the responder is not mandated to grant consent to multiple candidate= s after nomination. But, the option to do seems to be there (unless I'v= e understood the RFC wrong), and the only reason to do so would be possible= re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do nee= d to make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer





On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
Hi Bernard,
=C2=A0
Support of 5245bis is also negotiated, using the =E2=80=9Cice2=E2=80=9D ICE= option.
=C2=A0
Also, my understanding was that endpoints supporting RFC 7675 might maintai= n consent on pairs currently not used for media, in order to be able to re-= nominate in case consent for the currently nominated pair expires. However,= RFC 7675 does not explicitly say anything about that.
=C2=A0
Regards,
=C2=A0
Christer
=C2=A0
From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 20 July 2017 14:22
To: ice@ietf.org
Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis =C2=A0
During the ICE WG meeting today, there was discussion of whether RFC5245bis= should indicate that it is possible to re-nominate pairs (proposed by Pete= r), or whether it is possible to switch from one interface to another (Cull= en).=C2=A0 While these capabilities are desirable, attempting to add them to RFC 5245bis without negotiation has t= he potential to break interoperability with existing RFC 5245 implementatio= ns.
=C2=A0
In my experience, this is an area where RFC 5245 implementations have very = different interpretations. For example, some implementations (e.g. ones tha= t did not support aggressive) discard non-selected candidate pairs after no= mination. These implementations (e.g. particularly ones included in previous product releases) cannot be a= ssumed to change their behavior after RFC 5245bis is published.=C2=A0 This = raises the possibility that that interoperability could be impacted.=C2=A0<= br> =C2=A0
Since in practice the desired candidate pair switching capabilities are mos= t likely to be supported in WebRTC implementations supporting Trickle ICE, = my recommendation is to think of candidate pair switching as a Trickle ICE = capability. =C2=A0 Since Trickle-ICE support is negotiated, clarifications relating to candidate-pair switching= can be linked to that negotiation. =C2=A0
=C2=A0
This provides a potential way forward that bypasses potential interoperabil= ity issues.=C2=A0 For example, if text on candidate-pair switching is to be= added to (either to RFC 5245bis or Trickle-ICE) then the text could say th= at support for these behaviors can only be assumed if they are explicitly negotiated. The Trickle-ICE document cou= ld then create normative requirements for support of the new behaviors by s= tating that support for them is mandatory when supporting full-Trickle.=C2= =A0
=C2=A0
=C2=A0

=C2=A0

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--001a1148acb0bf20800557fa0cab-- From nobody Wed Aug 30 09:08:42 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA3A124B18 for ; Wed, 30 Aug 2017 09:08:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 EFlt8QLoz9oG for ; Wed, 30 Aug 2017 09:08:38 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 3E23E13202D for ; Wed, 30 Aug 2017 09:08:38 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id y50so20292649uay.4 for ; Wed, 30 Aug 2017 09:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6lxpKjwjK5DpBdxg0LyCL8ftjJgSBUE2NioawGVCYJ0=; b=SgFw0jTi2BHf8aFCKTuXGAu5ok/WO5nh57bH8s9CmiZiGd6M54q9d2DY236qc6RNYn wdfIWUtucyrWbhK5ErEywVAPOznewHLObQev71RLIncjFL6IfoMIZzLXITAJ1H9QqKBL my03BhTLloHXHIsF9ZQTS2PHsT0EuLuYVJxlGuL0LBDr6EJYZ+7JLCbPavc13ddJZB+d B66BsEMoTlHX1NdNbybJfUwP98Eh1RYtnYOxfTPWZL6RxBqj+E/C7k8BYcX5GD9Z2cSG QuJJElGfgO8yQfsKxOQ6STTTUpIuA4RNDFOvnNzWlAksd1+U4+ne9rMF9sQS9ALNGy2p 4ROg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6lxpKjwjK5DpBdxg0LyCL8ftjJgSBUE2NioawGVCYJ0=; b=M9pXjftZ7efU5HG7DN22DO5ltQHpbWKrQLckx3P9+sxu2mrK7B5vhHGIVjSJTQ+6Lm rorIts5qNIMyGOOB6lnTpvGXXrP8A98ix6GCoasoUnovt2klOrYTv4vv9ui8PNUzEkKg QKl+WmX3Zvh7OINu/rracRu1zuYug+qA6BWJtj0MMove0+iASn3wB3BQlGVAn96nZZwi t05x7VR4OrA26YA5Gz6M5pgKUY6EiJR9wxytVf6sKEuMaC8G25KZFjcUAFQc9BXs3z6Y 6n6wrTADpmLpQjQtKq7VlK9z/3/+jpKHxoEPPhUfB3uh4eGSS0nKLR5byzZmbCkodGKj NMhg== X-Gm-Message-State: AHYfb5ipbOwR4O2UpnhrApRG8spDdBxatBq0xHA/jvIzoVVjjVUEBcmC 0y81x/vUBI/5GHoMOtq8GJK6PW6cXSL2PBE= X-Received: by 10.176.71.235 with SMTP id w43mr1342721uac.65.1504109316864; Wed, 30 Aug 2017 09:08:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.23 with HTTP; Wed, 30 Aug 2017 09:08:16 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> From: Bernard Aboba Date: Wed, 30 Aug 2017 12:08:16 -0400 Message-ID: To: Peter Thatcher Cc: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="f4030437a2d48901020557fabd27" Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 16:08:42 -0000 --f4030437a2d48901020557fabd27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Peter said: "Your reasoning for saying that an agent can't switch candidate pairs is that it prevents the remote side from being able to release resources. But the switching side would only switch if the candidate pair recently received an ICE check response (in other words, it knows the candidate pair works), in which case it knows that resources have not been released." [BA] There is a dicotomy between the situation prior to nomination and after it that isn't explained well in RFC 5245bis. Prior to nomination, the agent can switch between validated candidate pairs, and hopefully we can make the language clear enough so that this will work well. While the same logic applies after nomination as well (e.g. it only makes sense to switch a valid pair), the text doesn't clarify the meaning of nomination with respect to resource release, nor does it talk about consent (presumably the mechanism that would be used to maintain pair validity after nomination), so that it's not clear how pair validity could be maintained. Since there is much RFC 5245 text still remaining, the overall document reads as though while it represents an update to RFC 5245 it still is based on a pre-WebRTC mindset. All this makes me wonder whether we should limit our aspirations for RFC 5245bis to clarifying things "just enough" so that it isn't a hindrance. People interested in building a modern ICE implementation for use in WebRTC will probably focus more on Trickle-ICE, where implementation of consent can be assumed, and perhaps the meaning of nomination within a WebRTC context could be better explained. On Wed, Aug 30, 2017 at 11:19 AM, Peter Thatcher wrote: > #2 and #3 are fine, but I'm not a fan of #1. > > Your reasoning for saying that an agent can't switch candidate pairs is > that it prevents the remote side from being able to release resources. B= ut > the switching side would only switch if the candidate pair recently > received an ICE check response (in other words, it knows the candidate pa= ir > works), in which case it knows that resources have not been released. > > In other words, if the remote side chose to release resources, the local > side wouldn't do the switch. So the remote side is free to release > resources; it's not prevented from doing so. If it does, then the local > side will notice and not do a switch. But if the remote side doesn't > release the resources, then the local side may switch. > > In other words, I think we can allow switching and resource release both. > > On Thu, Jul 27, 2017 at 4:01 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> Would anyone disagree with the following: >> >> >> >> 1) explicitly indicating that re-nomination is **NOT** allowed >> without ICE restart; and >> >> 2) once a pair has been selected, agents need to be able to send * >> *AND** receive media using that pair =E2=80=93 but not using any other p= air >> (read: resources associated with other pairs may be released); and >> >> 3) PRIOR to selection, agents need to be able to send **AND** >> receive media on any valid pair (RFC 7675 adds restrictions, but that=E2= =80=99s >> outside the scope of 5245bis) >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Christer >> Holmberg >> *Sent:* 25 July 2017 10:17 >> *To:* Bernard Aboba >> *Cc:* ice@ietf.org >> *Subject:* Re: [Ice] Re-nomination and candidate pair switching in RFC >> 5245bis >> >> >> >> Hi Bernard, >> >> >> >> Regarding sending media PRIOR to nomination, we have previously agreed >> that any valid pair can be used for that. Perhaps it needs more >> clarification. >> >> >> >> Regarding receiving media after nomination, it was discussed in Prague, >> as it is covered by Peter=E2=80=99s PR. I don=E2=80=99t have access to t= he PR/minutes right >> now, but I think the outcome was that an agent is only expected to recei= ve >> media on the nominated pair (otherwise it cannot free resources). >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From:* Bernard Aboba [mailto:bernard.aboba@gmail.com >> ] >> *Sent:* 25 July 2017 02:29 >> *To:* Christer Holmberg >> *Cc:* ice@ietf.org >> *Subject:* Re: [Ice] Re-nomination and candidate pair switching in RFC >> 5245bis >> >> >> >> Christer said: >> >> >> >> "The whole discussion began when I was given a comment that the text >> above should be modified, to clarify that the pair used for media can >> change after a pair has been selected. >> >> But, if the outcome is that the pair can NOT change, maybe we need to >> clarify THAT instead :)" >> >> >> >> [BA] Currently, use of the "ice2" ICE option forestalls use of aggressiv= e >> nomination (e.g. setting the nominated flag on more than one pair). Sin= ce >> only the selected pair can be used to send media, that would seem to rul= e >> out changing the pair used for media after a pair has been selected: >> >> >> >> Once a candidate pair has been selected >> >> only that candidate pair (referred to as selected pair) is used for >> >> sending media. >> >> >> >> What about changing the pair used for media prior to selection? On this >> point, the text seems less clear than it could be. >> >> >> >> Prior to nomination, the specification allows the sending of media on a >> successful pair: >> >> >> >> o Once there is at least one nominated pair in the VALID LIST for >> >> every component of at least one media stream and the state of the >> >> CHECK LIST is Running: >> >> >> >> ... >> >> >> >> * The agent MUST continue to respond to any checks it may still >> >> receive for that media stream, and MUST perform triggered >> >> checks if required by the processing of Section 6.3 . >> >> >> >> * The agent MAY begin transmitting media for this media stream as >> >> described in Section 11.1 >> . >> >> >> >> However, the specification is not clear enough about the receiving side; >> while it recommends that implementations be prepared to receive prior to >> nomination, it does not require this. From Section 11.2: >> >> >> >> ICE implementations SHOULD by default be >> >> prepared to receive media on any of the candidates provided in the >> >> most recent candidate exchange with the peer. >> >> >> >> What happens if an implementation is NOT prepared to receive media? >> >> In WebRTC, an implementation cannot send without consent, which >> >> suggests that perhaps an unwilling receiver could use consent to >> >> influence the potential sender. >> >> >> >> However, the specification does not even reference RFC 7675, >> >> so it is left unclear about how this is to be done. >> >> For example, a receiver might not reply to a consent >> >> request if the inability to receive is temporary ("I'm not ready yet"), >> >> but that might cause consent to time out prior to nomination and >> >> might even influence pair selection inappropriately. >> >> >> >> Another choice might be to revoke consent (which would >> >> invalidate the pair). But that's pretty drastic unless the >> >> pair is truly unacceptable. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected >> pair: >> > >> > Eventually, there will be only a single nominated pair in the VALID >> > LIST for each component. Once the state of the CHECK LIST is set to >> > Completed, that exact pair is selected by ICE for sending and >> > receiving media for that component. >> > >> >Based on that text, an implementation might still release resources >> (e.g. unused TURN candidates) post-nomination. Given this, the "ice2" IC= E >> option doesn't address >potential interoperability issues resulting from >> different resource release behaviors (although it does clear indicate la= ck >> of support for aggressive nomination): >> >> The whole discussion began when I was given a comment that the text abov= e >> should be modified, to clarify that the pair used for media can change >> after a pair has been selected. >> >> But, if the outcome is that the pair can NOT change, maybe we need to >> clarify THAT instead :) >> >> > NOTE: A controlling agent that does not support this specification >> > (i.e. it is implemented according to RFC 5245) might nominate more >> > than one candidate pair. This was referred to as aggressive >> > nomination in RFC 5245. The usage of the 'ice2' ice option by >> > endpoints supporting this specifcation should prevent such >> > controlling agents from using aggressive nomination. >> > >> >Christer also said: >> > >> >"Also, my understanding was that endpoints supporting RFC 7675 might >> maintain consent on pairs currently not >> >used for media, in order to be able to re-nominate in case consent for >> the currently nominated pair expires. However, >> >RFC 7675 does not explicitly say anything about that." >> > >> >[BA] RFC 7675 Section 5 says: >> > >> > Initial consent to send traffic is obtained using ICE [RFC5245]. An >> > endpoint gains consent to send on a candidate pair when the pair >> > enters the Succeeded ICE state. >> > >> >Given this, an RFC 5245bis implementation might request consent to send >> to >> >multiple remote peer candidates, so as to keep them alive. However, >> >there is nothing in RFC 7675 that requires the responder to grant >> >consent for that. For example, based on the text in RFC 5245bis >> >Section 7.1.1, a conforming implementation might well revoke >> >consent on local candidates other than the local candidate in the >> >selected pair. >> >> Sure - the responder is not mandated to grant consent to multiple >> candidates after nomination. But, the option to do seems to be there >> (unless I've understood the RFC wrong), and the only reason to do so wou= ld >> be possible re-nomination. >> >> Anyway, I don't have any strong feelings which way we go, but we do need >> to make it clear in the spec whether re-nomination is allowed or not. >> >> Regards, >> >> Christer >> >> >> >> On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >> Hi >> , >> >[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected >> pair: >> > >> > Eventually, there will be only a single nominated pair in the VALID >> > LIST for each component. Once the state of the CHECK LIST is set to >> > Completed, that exact pair is selected by ICE for sending and >> > receiving media for that component. >> > >> >Based on that text, an implementation might still release resources >> (e.g. unused TURN candidates) post-nomination. Given this, the "ice2" IC= E >> option doesn't address >potential interoperability issues resulting from >> different resource release behaviors (although it does clear indicate la= ck >> of support for aggressive nomination): >> >> The whole discussion began when I was given a comment that the text abov= e >> should be modified, to clarify that the pair used for media can change >> after a pair has been selected. >> >> But, if the outcome is that the pair can NOT change, maybe we need to >> clarify THAT instead :) >> >> > NOTE: A controlling agent that does not support this specification >> > (i.e. it is implemented according to RFC 5245) might nominate more >> > than one candidate pair. This was referred to as aggressive >> > nomination in RFC 5245. The usage of the 'ice2' ice option by >> > endpoints supporting this specifcation should prevent such >> > controlling agents from using aggressive nomination. >> > >> >Christer also said: >> > >> >"Also, my understanding was that endpoints supporting RFC 7675 might >> maintain consent on pairs currently not >> >used for media, in order to be able to re-nominate in case consent for >> the currently nominated pair expires. However, >> >RFC 7675 does not explicitly say anything about that." >> > >> >[BA] RFC 7675 Section 5 says: >> > >> > Initial consent to send traffic is obtained using ICE [RFC5245]. An >> > endpoint gains consent to send on a candidate pair when the pair >> > enters the Succeeded ICE state. >> > >> >Given this, an RFC 5245bis implementation might request consent to send >> to >> >multiple remote peer candidates, so as to keep them alive. However, >> >there is nothing in RFC 7675 that requires the responder to grant >> >consent for that. For example, based on the text in RFC 5245bis >> >Section 7.1.1, a conforming implementation might well revoke >> >consent on local candidates other than the local candidate in the >> >selected pair. >> >> Sure - the responder is not mandated to grant consent to multiple >> candidates after nomination. But, the option to do seems to be there >> (unless I've understood the RFC wrong), and the only reason to do so wou= ld >> be possible re-nomination. >> >> Anyway, I don't have any strong feelings which way we go, but we do need >> to make it clear in the spec whether re-nomination is allowed or not. >> >> Regards, >> >> Christer >> >> >> >> >> >> On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> Hi Bernard, >> >> Support of 5245bis is also negotiated, using the =E2=80=9Cice2=E2=80=9D = ICE option. >> >> Also, my understanding was that endpoints supporting RFC 7675 might >> maintain consent on pairs currently not used for media, in order to be a= ble >> to re-nominate in case consent for the currently nominated pair expires. >> However, RFC 7675 does not explicitly say anything about that. >> >> Regards, >> >> Christer >> >> From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Bernard Aboba >> Sent: 20 July 2017 14:22 >> To: ice@ietf.org >> Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis >> >> During the ICE WG meeting today, there was discussion of whether >> RFC5245bis should indicate that it is possible to re-nominate pairs >> (proposed by Peter), or whether it is possible to switch from one interf= ace >> to another (Cullen). While these capabilities are desirable, attempting= to >> add them to RFC 5245bis without negotiation has the potential to break >> interoperability with existing RFC 5245 implementations. >> >> In my experience, this is an area where RFC 5245 implementations have >> very different interpretations. For example, some implementations (e.g. >> ones that did not support aggressive) discard non-selected candidate pai= rs >> after nomination. These implementations (e.g. particularly ones included= in >> previous product releases) cannot be assumed to change their behavior af= ter >> RFC 5245bis is published. This raises the possibility that that >> interoperability could be impacted. >> >> Since in practice the desired candidate pair switching capabilities are >> most likely to be supported in WebRTC implementations supporting Trickle >> ICE, my recommendation is to think of candidate pair switching as a Tric= kle >> ICE capability. Since Trickle-ICE support is negotiated, clarification= s >> relating to candidate-pair switching can be linked to that negotiation. >> >> This provides a potential way forward that bypasses potential >> interoperability issues. For example, if text on candidate-pair switchi= ng >> is to be added to (either to RFC 5245bis or Trickle-ICE) then the text >> could say that support for these behaviors can only be assumed if they a= re >> explicitly negotiated. The Trickle-ICE document could then create normat= ive >> requirements for support of the new behaviors by stating that support fo= r >> them is mandatory when supporting full-Trickle. >> >> >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > --f4030437a2d48901020557fabd27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peter said:=C2=A0

"Your reasoning for saying that an agent can't switch = candidate pairs is that it prevents the remote side from being able to rele= ase resources.=C2=A0 But the switching side would only switch if the candid= ate pair recently received an ICE check response (in other words, it knows = the candidate pair works), in which case it knows that resources have not b= een released."

[BA] There is a dicotom= y between the situation prior to nomination and after it that isn't exp= lained well in RFC 5245bis.=C2=A0 Prior to nomination, the agent can switch= between validated candidate pairs, and hopefully we can make the language = clear enough so that this will work well.=C2=A0

Wh= ile the same logic applies after nomination as well (e.g. it only makes sen= se to switch a valid pair), the text doesn't clarify the meaning of nom= ination with respect to resource release, nor does it talk about consent (p= resumably the mechanism that would be used to maintain pair validity after = nomination), so that it's not clear how pair validity could be maintain= ed.=C2=A0 Since there is much RFC 5245 text still remaining, the overall do= cument reads as though while it represents an update to RFC 5245 it still i= s based on a pre-WebRTC mindset.=C2=A0

All thi= s makes me wonder whether we should limit our aspirations for RFC 5245bis t= o clarifying things "just enough" so that it isn't a hindranc= e.=C2=A0 People interested in building a modern ICE implementation for use = in WebRTC will probably focus more on Trickle-ICE, where implementation of = consent can be assumed, and perhaps the meaning of nomination within a WebR= TC context could be better explained.=C2=A0



On Wed,= Aug 30, 2017 at 11:19 AM, Peter Thatcher <pthatcher@google.com>= wrote:
#2 and #3= are fine, but I'm not a fan of #1.

Your reasoning f= or saying that an agent can't switch candidate pairs is that it prevent= s the remote side from being able to release resources.=C2=A0 But the switc= hing side would only switch if the candidate pair recently received an ICE = check response (in other words, it knows the candidate pair works), in whic= h case it knows that resources have not been released.

=
In other words, if the remote side chose to release resources, the loc= al side wouldn't do the switch.=C2=A0 So the remote side is free to rel= ease resources; it's not prevented from doing so.=C2=A0 If it does, the= n the local side will notice and not do a switch. =C2=A0 But if the remote = side doesn't release the resources, then the local side may switch.

In other words, I think we can allow switching and re= source release both.=C2=A0

On Thu, Jul 27, 2017 at 4:01 AM Christer H= olmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Would anyone disagree with the follow= ing:

=C2=A0

= 1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 explicitly indicating that re-no= mination is *NOT* allowed without ICE restart; and

= 2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 once a pair has been selected, a= gents need to be able to send *AND* receive media using that pair = =E2=80=93 but not using any other pair (read: resources associated with other pairs may be release= d); and

= 3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PRIOR to selection, agents need = to be able to send *AND* receive media on any valid pair (RFC 7675 a= dds restrictions, but that=E2=80=99s outside the scope of 5245bis)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Ice [mailto:ice-b= ounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 25 July 2017 10:17
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: ice@ietf.org
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC= 5245bis

=C2=A0

Hi Bernard,

=C2=A0

Regarding sending media PRIOR to nomi= nation, we have previously agreed that any valid pair can be used for that.= Perhaps it needs more clarification.

=C2=A0

Regarding receiving media after nomin= ation, it was discussed in Prague, as it is covered by Peter=E2=80=99s PR. = I don=E2=80=99t have access to the PR/minutes right now, but I think the outcome was that an agent is only ex= pected to receive media on the nominated pair (otherwise it cannot free res= ources).

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Bernard Aboba [mailto:bernard.aboba@gmail.com]
Sent: 25 July 2017 02:29
To: Christer Holmberg <christer.holmberg@ericsson= .com>
Cc: ice@ietf.org
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC= 5245bis

=C2=A0

Christer said:=C2=A0

=C2=A0

"The whole disc= ussion began when I was given a comment that the text above should be modif= ied, to clarify that the pair used for media can change after a pair has be= en selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)"=C2=A0

=C2=A0

[BA]=C2=A0Currently,= use of the "ice2" ICE option forestalls use of aggressive nomina= tion (e.g. setting the nominated flag on more than one pair).=C2=A0 Since o= nly the selected pair can be used to send media, that would seem to rule out changing the pair used for media after a pair has been se= lected:=C2=A0

=C2=A0

=C2=A0=C2=A0 Once a candidate pair has bee=
n selected
=C2=A0=C2=A0 only that candidate pair (ref=
erred to as selected pair) is used for
=C2=A0=C2=A0 sending media.<=
/span>

=C2=A0

What about changing the pair used for media prior to= selection?=C2=A0 On this point, the text seems less clear than it could be= .=C2=A0

=C2=A0

Prior to nomination,= the specification allows the sending of media on a successful pair:=

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Once there is at leas=
t one nominated pair in the VALID LIST for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 every compo=
nent of at least one media stream and the state of the=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHECK LIST =
is Running:
=C2=A0
...
=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*=C2=
=A0 The agent MUST continue to respond to any checks it may still=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 receive for that media stream, and MUST perform triggered<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 checks if required by the processing of Section 6.3.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 The=
 agent MAY begin transmitting media for this media stream as=C2=A0

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0described in Section 11= .1.

=C2=A0

However, the specifi= cation is not clear enough about the receiving side; while it recommends th= at implementations be prepared to receive prior to nomination, it does not = require this.=C2=A0From Section 11.2:=C2=A0

=C2=A0

=C2=A0=C2=A0 ICE implementations SHOULD by=
 default be
=C2=A0=C2=A0 prepared to receive media on =
any of the candidates provided in the
=C2=A0=C2=A0 most recent candidate exchang=
e with the peer.
=C2=A0
What happens if an implementation is NOT p=
repared to receive media?
In WebRTC, an implementation cannot send w=
ithout consent, which 
suggests that perhaps an unwilling receive=
r could use consent to
influence the potential sender. =

=C2=A0
However, the specification does not even r=
eference RFC 7675,
so it is left unclear about how this is to=
 be done.
For example, a receiver might not reply to=
 a consent
request if the inability to receive is tem=
porary ("I'm not ready yet"),
but that might cause consent to time out p=
rior to nomination and
might even influence pair selection inappr=
opriately.
=C2=A0
Another choice might be to revoke consent =
(which would
invalidate the pair).=C2=A0 But that's=
 pretty drastic unless the
pair is truly unacceptable. =

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

>[BA] RFC 5245bis Section= 7.1.1 continues to imply a single selected pair:=C2=A0
>
>=C2= =A0 =C2=A0Eventually, there will be only a single nominated pair in the VAL= ID
>=C2= =A0 =C2=A0LIST for each component.=C2=A0 Once the state of the CHECK LIST i= s set to
>=C2= =A0 =C2=A0Completed, that exact pair is selected by ICE for sending and
>=C2= =A0 =C2=A0receiving media for that component.
>
>Base= d on that text, an implementation might still release resources (e.g. unuse= d TURN candidates) post-nomination. Given this, the=C2=A0"ice2" I= CE option doesn't address >potential interoperability issues resulti= ng from different resource release behaviors (although it does clear indicate lack of support for agg= ressive nomination):=C2=A0

The whole discussion began when I was given a comment that the text above s= hould be modified, to clarify that the pair used for media can change after= a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)

>=C2= =A0 =C2=A0NOTE: A controlling agent that does not support this specificatio= n
>=C2= =A0 =C2=A0(i.e. it is implemented according to RFC 5245) might nominate mor= e
>=C2= =A0 =C2=A0than one candidate pair.=C2=A0 This was referred to as aggressive=
>=C2= =A0 =C2=A0nomination in RFC 5245.=C2=A0 The usage of the 'ice2' ice= option by
>=C2= =A0 =C2=A0endpoints supporting this specifcation should prevent such=
>=C2= =A0 =C2=A0controlling agents from using aggressive nomination.
>
>Chri= ster also said:=C2=A0
>
>&quo= t;Also, my understanding was that endpoints supporting RFC 7675 might maint= ain consent on pairs currently not
>used= for media, in order to be able to re-nominate in case consent for the curr= ently nominated pair expires. However,
>RFC = 7675 does not explicitly say anything about that."
>
>[BA]= RFC 7675 Section 5 says:=C2=A0
>
>=C2= =A0 =C2=A0Initial consent to send traffic is obtained using ICE [RFC5245].= =C2=A0 An
>=C2= =A0 =C2=A0endpoint gains consent to send on a candidate pair when the pair<= /span>
>=C2= =A0 =C2=A0enters the Succeeded ICE state.
>
>Give= n this, an RFC 5245bis implementation might request consent to send to
>mult= iple remote peer candidates, so as to keep them alive. However,
>ther= e is nothing in RFC 7675 that requires the responder to grant
>cons= ent for that.=C2=A0 For example, based on the text in RFC 5245bis >Sect= ion 7.1.1, a conforming implementation might well revoke
>cons= ent on local candidates other than the local candidate in the
>sele= cted pair.

Sure - the responder is not mandated to grant consent to multiple candidate= s after nomination. But, the option to do seems to be there (unless I'v= e understood the RFC wrong), and the only reason to do so would be possible= re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do nee= d to make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer

=C2=A0

On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi
,
>[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected pai= r:=C2=A0
>
>=C2=A0 =C2=A0Eventually, there will be only a single nominated pair in = the VALID
>=C2=A0 =C2=A0LIST for each component.=C2=A0 Once the state of the CHECK= LIST is set to
>=C2=A0 =C2=A0Completed, that exact pair is selected by ICE for sending = and
>=C2=A0 =C2=A0receiving media for that component.
>
>Based on that text, an implementation might still release resources (e.= g. unused TURN candidates) post-nomination. Given this, the=C2=A0"ice2= " ICE option doesn't address >potential interoperability issues= resulting from different resource release behaviors (although it does clear indicate lack of support for aggressive nomination):=C2=A0
The whole discussion began when I was given a comment that the text above s= hould be modified, to clarify that the pair used for media can change after= a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)

>=C2=A0 =C2=A0NOTE: A controlling agent that does not support this speci= fication
>=C2=A0 =C2=A0(i.e. it is implemented according to RFC 5245) might nomin= ate more
>=C2=A0 =C2=A0than one candidate pair.=C2=A0 This was referred to as agg= ressive
>=C2=A0 =C2=A0nomination in RFC 5245.=C2=A0 The usage of the 'ice2&#= 39; ice option by
>=C2=A0 =C2=A0endpoints supporting this specifcation should prevent such=
>=C2=A0 =C2=A0controlling agents from using aggressive nomination.
>
>Christer also said:=C2=A0
>
>"Also, my understanding was that endpoints supporting RFC 7675 mig= ht maintain consent on pairs currently not
>used for media, in order to be able to re-nominate in case consent for = the currently nominated pair expires. However,
>RFC 7675 does not explicitly say anything about that."
>
>[BA] RFC 7675 Section 5 says:=C2=A0
>
>=C2=A0 =C2=A0Initial consent to send traffic is obtained using ICE [RFC= 5245].=C2=A0 An
>=C2=A0 =C2=A0endpoint gains consent to send on a candidate pair when th= e pair
>=C2=A0 =C2=A0enters the Succeeded ICE state.
>
>Given this, an RFC 5245bis implementation might request consent to send= to
>multiple remote peer candidates, so as to keep them alive. However,
>there is nothing in RFC 7675 that requires the responder to grant
>consent for that.=C2=A0 For example, based on the text in RFC 5245bis >Section 7.1.1, a conforming implementation might well revoke
>consent on local candidates other than the local candidate in the
>selected pair.

Sure - the responder is not mandated to grant consent to multiple candidate= s after nomination. But, the option to do seems to be there (unless I'v= e understood the RFC wrong), and the only reason to do so would be possible= re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do nee= d to make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer





On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
Hi Bernard,
=C2=A0
Support of 5245bis is also negotiated, using the =E2=80=9Cice2=E2=80=9D ICE= option.
=C2=A0
Also, my understanding was that endpoints supporting RFC 7675 might maintai= n consent on pairs currently not used for media, in order to be able to re-= nominate in case consent for the currently nominated pair expires. However,= RFC 7675 does not explicitly say anything about that.
=C2=A0
Regards,
=C2=A0
Christer
=C2=A0
From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 20 July 2017 14:22
To: ice@ietf.org
Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis =C2=A0
During the ICE WG meeting today, there was discussion of whether RFC5245bis= should indicate that it is possible to re-nominate pairs (proposed by Pete= r), or whether it is possible to switch from one interface to another (Cull= en).=C2=A0 While these capabilities are desirable, attempting to add them to RFC 5245bis without negotiation has t= he potential to break interoperability with existing RFC 5245 implementatio= ns.
=C2=A0
In my experience, this is an area where RFC 5245 implementations have very = different interpretations. For example, some implementations (e.g. ones tha= t did not support aggressive) discard non-selected candidate pairs after no= mination. These implementations (e.g. particularly ones included in previous product releases) cannot be a= ssumed to change their behavior after RFC 5245bis is published.=C2=A0 This = raises the possibility that that interoperability could be impacted.=C2=A0<= br> =C2=A0
Since in practice the desired candidate pair switching capabilities are mos= t likely to be supported in WebRTC implementations supporting Trickle ICE, = my recommendation is to think of candidate pair switching as a Trickle ICE = capability. =C2=A0 Since Trickle-ICE support is negotiated, clarifications relating to candidate-pair switching= can be linked to that negotiation. =C2=A0
=C2=A0
This provides a potential way forward that bypasses potential interoperabil= ity issues.=C2=A0 For example, if text on candidate-pair switching is to be= added to (either to RFC 5245bis or Trickle-ICE) then the text could say th= at support for these behaviors can only be assumed if they are explicitly negotiated. The Trickle-ICE document cou= ld then create normative requirements for support of the new behaviors by s= tating that support for them is mandatory when supporting full-Trickle.=C2= =A0
=C2=A0
=C2=A0

=C2=A0

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice

--f4030437a2d48901020557fabd27-- From nobody Wed Aug 30 09:26:33 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02F813213D for ; Wed, 30 Aug 2017 09:26:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Y87DH36RoBA9 for ; Wed, 30 Aug 2017 09:26:28 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 80B671201F8 for ; Wed, 30 Aug 2017 09:26:28 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id k77so55297823oib.2 for ; Wed, 30 Aug 2017 09:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y2Wm0qQL+vC0rcAAiCyUL0EN2PNXZQjcJ9L3NAHb2wo=; b=MhYUuETPEmZrnGTv5bqIAJiXgI2Spry4LScI64gm8Rir0fJ89HYIBcbi/mF7eNbd/h qhukA0bKanx3vlFYGMm06gH5//29nr1rF5R1j/WEdtoxgxyvpiuiqDec06eWgor3SRs/ kA49ScwaN0j1SY3S/kgLRfc9OP52SUPEoyBQoaTYrgoqjPVxmdebspuEoFy5xgMVlYCE 2twDBhrzWZpW2CtfcMzocF1VAQHbDf8Duh+WTL122z0Y/OCoWjzx5sQXWwUyXc7ETl1v Drzo8sKNKzu8BMLk9TSgqALbvcLCDlaiWkk+se9i68ma9iV7C/qWj4jJ2ma04DFcEYvY 1ctw== 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=Y2Wm0qQL+vC0rcAAiCyUL0EN2PNXZQjcJ9L3NAHb2wo=; b=SiCHw+35DFuNYHo/bH4SMjVko3FoBnZSQ3XRcvXhtsxAtSgnZkc3IpzA4PuTohg3tn S32FykldfE+dH2m0pahD3uYTx+yddV/kgSEJ85O4Mx3zIhFh0NGg0+in4l/rtXq5QtL3 v4okZ05lgJ0LMjC55ozQmy5P7MTaOlvZDj89TKDaopqFrtHOsYhvt7IeBakI9EAKmWXv nJRdUqIFpy8Mq9YyLnidIqJqFc8qpK//47+jwKJKMmS7RymtHyyPIMzJbe0PDIn8jMWp 9nPWiKhh7m61kshaPZfjaVA/L0quGZolaHXHjQ6Cxxbnkw5MbtUCR3t+G4hc934Pyrzn bTcw== X-Gm-Message-State: AHYfb5hRyCgGrJQyeBOgpKg/mq5ZNmdvl4czBDvMcm/48P2Rc6hBNldQ nu+8S5MI6tPTmcCiIMCE+wq7ouC8xj4A X-Google-Smtp-Source: ADKCNb4p8lRH5NzOwZxyZLD5ESuL9nYbkA21IK4Xik/drpOczwdM9mrlcGW4MmPgQCAUG6+95ZPreBPJGG7j8EGXLjc= X-Received: by 10.202.78.78 with SMTP id c75mr2079887oib.53.1504110387354; Wed, 30 Aug 2017 09:26:27 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> In-Reply-To: From: Peter Thatcher Date: Wed, 30 Aug 2017 16:26:15 +0000 Message-ID: To: Bernard Aboba Cc: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a11c1691e5810500557fafdec" Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 16:26:33 -0000 --001a11c1691e5810500557fafdec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As far as "just enough" so that it isn't a hindrance: that's why I wanted to say that agents *may* switch. It allows a renomination in the future. Saying they MUST NOT is a hindrance. I would be fine if the *may* requires negotiation. That's what On Wed, Aug 30, 2017 at 9:08 AM Bernard Aboba wrote: > Peter said: > > "Your reasoning for saying that an agent can't switch candidate pairs is > that it prevents the remote side from being able to release resources. B= ut > the switching side would only switch if the candidate pair recently > received an ICE check response (in other words, it knows the candidate pa= ir > works), in which case it knows that resources have not been released." > > [BA] There is a dicotomy between the situation prior to nomination and > after it that isn't explained well in RFC 5245bis. Prior to nomination, > the agent can switch between validated candidate pairs, and hopefully we > can make the language clear enough so that this will work well. > > While the same logic applies after nomination as well (e.g. it only makes > sense to switch a valid pair), the text doesn't clarify the meaning of > nomination with respect to resource release, nor does it talk about conse= nt > (presumably the mechanism that would be used to maintain pair validity > after nomination), so that it's not clear how pair validity could be > maintained. Since there is much RFC 5245 text still remaining, the overa= ll > document reads as though while it represents an update to RFC 5245 it sti= ll > is based on a pre-WebRTC mindset. > > All this makes me wonder whether we should limit our aspirations for RFC > 5245bis to clarifying things "just enough" so that it isn't a hindrance. > People interested in building a modern ICE implementation for use in WebR= TC > will probably focus more on Trickle-ICE, where implementation of consent > can be assumed, and perhaps the meaning of nomination within a WebRTC > context could be better explained. > > > > On Wed, Aug 30, 2017 at 11:19 AM, Peter Thatcher > wrote: > >> #2 and #3 are fine, but I'm not a fan of #1. >> >> Your reasoning for saying that an agent can't switch candidate pairs is >> that it prevents the remote side from being able to release resources. = But >> the switching side would only switch if the candidate pair recently >> received an ICE check response (in other words, it knows the candidate p= air >> works), in which case it knows that resources have not been released. >> >> In other words, if the remote side chose to release resources, the local >> side wouldn't do the switch. So the remote side is free to release >> resources; it's not prevented from doing so. If it does, then the local >> side will notice and not do a switch. But if the remote side doesn't >> release the resources, then the local side may switch. >> >> In other words, I think we can allow switching and resource release both= . >> >> On Thu, Jul 27, 2017 at 4:01 AM Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> >>> >>> Would anyone disagree with the following: >>> >>> >>> >>> 1) explicitly indicating that re-nomination is **NOT** allowed >>> without ICE restart; and >>> >>> 2) once a pair has been selected, agents need to be able to send * >>> *AND** receive media using that pair =E2=80=93 but not using any other = pair >>> (read: resources associated with other pairs may be released); and >>> >>> 3) PRIOR to selection, agents need to be able to send **AND** >>> receive media on any valid pair (RFC 7675 adds restrictions, but that= =E2=80=99s >>> outside the scope of 5245bis) >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Christer >>> Holmberg >>> *Sent:* 25 July 2017 10:17 >>> *To:* Bernard Aboba >>> *Cc:* ice@ietf.org >>> *Subject:* Re: [Ice] Re-nomination and candidate pair switching in RFC >>> 5245bis >>> >>> >>> >>> Hi Bernard, >>> >>> >>> >>> Regarding sending media PRIOR to nomination, we have previously agreed >>> that any valid pair can be used for that. Perhaps it needs more >>> clarification. >>> >>> >>> >>> Regarding receiving media after nomination, it was discussed in Prague, >>> as it is covered by Peter=E2=80=99s PR. I don=E2=80=99t have access to = the PR/minutes right >>> now, but I think the outcome was that an agent is only expected to rece= ive >>> media on the nominated pair (otherwise it cannot free resources). >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> *From:* Bernard Aboba [mailto:bernard.aboba@gmail.com >>> ] >>> *Sent:* 25 July 2017 02:29 >>> *To:* Christer Holmberg >>> *Cc:* ice@ietf.org >>> *Subject:* Re: [Ice] Re-nomination and candidate pair switching in RFC >>> 5245bis >>> >>> >>> >>> Christer said: >>> >>> >>> >>> "The whole discussion began when I was given a comment that the text >>> above should be modified, to clarify that the pair used for media can >>> change after a pair has been selected. >>> >>> But, if the outcome is that the pair can NOT change, maybe we need to >>> clarify THAT instead :)" >>> >>> >>> >>> [BA] Currently, use of the "ice2" ICE option forestalls use of >>> aggressive nomination (e.g. setting the nominated flag on more than one >>> pair). Since only the selected pair can be used to send media, that wo= uld >>> seem to rule out changing the pair used for media after a pair has been >>> selected: >>> >>> >>> >>> Once a candidate pair has been selected >>> >>> only that candidate pair (referred to as selected pair) is used for >>> >>> sending media. >>> >>> >>> >>> What about changing the pair used for media prior to selection? On thi= s >>> point, the text seems less clear than it could be. >>> >>> >>> >>> Prior to nomination, the specification allows the sending of media on a >>> successful pair: >>> >>> >>> >>> o Once there is at least one nominated pair in the VALID LIST for >>> >>> every component of at least one media stream and the state of the >>> >>> CHECK LIST is Running: >>> >>> >>> >>> ... >>> >>> >>> >>> * The agent MUST continue to respond to any checks it may still >>> >>> receive for that media stream, and MUST perform triggered >>> >>> checks if required by the processing of Section 6.3 . >>> >>> >>> >>> * The agent MAY begin transmitting media for this media stream a= s >>> >>> described in Section 11.1 >>> = . >>> >>> >>> >>> However, the specification is not clear enough about the receiving side= ; >>> while it recommends that implementations be prepared to receive prior t= o >>> nomination, it does not require this. From Section 11.2: >>> >>> >>> >>> ICE implementations SHOULD by default be >>> >>> prepared to receive media on any of the candidates provided in the >>> >>> most recent candidate exchange with the peer. >>> >>> >>> >>> What happens if an implementation is NOT prepared to receive media? >>> >>> In WebRTC, an implementation cannot send without consent, which >>> >>> suggests that perhaps an unwilling receiver could use consent to >>> >>> influence the potential sender. >>> >>> >>> >>> However, the specification does not even reference RFC 7675, >>> >>> so it is left unclear about how this is to be done. >>> >>> For example, a receiver might not reply to a consent >>> >>> request if the inability to receive is temporary ("I'm not ready yet"), >>> >>> but that might cause consent to time out prior to nomination and >>> >>> might even influence pair selection inappropriately. >>> >>> >>> >>> Another choice might be to revoke consent (which would >>> >>> invalidate the pair). But that's pretty drastic unless the >>> >>> pair is truly unacceptable. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected >>> pair: >>> > >>> > Eventually, there will be only a single nominated pair in the VALID >>> > LIST for each component. Once the state of the CHECK LIST is set t= o >>> > Completed, that exact pair is selected by ICE for sending and >>> > receiving media for that component. >>> > >>> >Based on that text, an implementation might still release resources >>> (e.g. unused TURN candidates) post-nomination. Given this, the "ice2" I= CE >>> option doesn't address >potential interoperability issues resulting fro= m >>> different resource release behaviors (although it does clear indicate l= ack >>> of support for aggressive nomination): >>> >>> The whole discussion began when I was given a comment that the text >>> above should be modified, to clarify that the pair used for media can >>> change after a pair has been selected. >>> >>> But, if the outcome is that the pair can NOT change, maybe we need to >>> clarify THAT instead :) >>> >>> > NOTE: A controlling agent that does not support this specification >>> > (i.e. it is implemented according to RFC 5245) might nominate more >>> > than one candidate pair. This was referred to as aggressive >>> > nomination in RFC 5245. The usage of the 'ice2' ice option by >>> > endpoints supporting this specifcation should prevent such >>> > controlling agents from using aggressive nomination. >>> > >>> >Christer also said: >>> > >>> >"Also, my understanding was that endpoints supporting RFC 7675 might >>> maintain consent on pairs currently not >>> >used for media, in order to be able to re-nominate in case consent for >>> the currently nominated pair expires. However, >>> >RFC 7675 does not explicitly say anything about that." >>> > >>> >[BA] RFC 7675 Section 5 says: >>> > >>> > Initial consent to send traffic is obtained using ICE [RFC5245]. A= n >>> > endpoint gains consent to send on a candidate pair when the pair >>> > enters the Succeeded ICE state. >>> > >>> >Given this, an RFC 5245bis implementation might request consent to sen= d >>> to >>> >multiple remote peer candidates, so as to keep them alive. However, >>> >there is nothing in RFC 7675 that requires the responder to grant >>> >consent for that. For example, based on the text in RFC 5245bis >>> >Section 7.1.1, a conforming implementation might well revoke >>> >consent on local candidates other than the local candidate in the >>> >selected pair. >>> >>> Sure - the responder is not mandated to grant consent to multiple >>> candidates after nomination. But, the option to do seems to be there >>> (unless I've understood the RFC wrong), and the only reason to do so wo= uld >>> be possible re-nomination. >>> >>> Anyway, I don't have any strong feelings which way we go, but we do nee= d >>> to make it clear in the spec whether re-nomination is allowed or not. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>> Hi >>> , >>> >[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected >>> pair: >>> > >>> > Eventually, there will be only a single nominated pair in the VALID >>> > LIST for each component. Once the state of the CHECK LIST is set t= o >>> > Completed, that exact pair is selected by ICE for sending and >>> > receiving media for that component. >>> > >>> >Based on that text, an implementation might still release resources >>> (e.g. unused TURN candidates) post-nomination. Given this, the "ice2" I= CE >>> option doesn't address >potential interoperability issues resulting fro= m >>> different resource release behaviors (although it does clear indicate l= ack >>> of support for aggressive nomination): >>> >>> The whole discussion began when I was given a comment that the text >>> above should be modified, to clarify that the pair used for media can >>> change after a pair has been selected. >>> >>> But, if the outcome is that the pair can NOT change, maybe we need to >>> clarify THAT instead :) >>> >>> > NOTE: A controlling agent that does not support this specification >>> > (i.e. it is implemented according to RFC 5245) might nominate more >>> > than one candidate pair. This was referred to as aggressive >>> > nomination in RFC 5245. The usage of the 'ice2' ice option by >>> > endpoints supporting this specifcation should prevent such >>> > controlling agents from using aggressive nomination. >>> > >>> >Christer also said: >>> > >>> >"Also, my understanding was that endpoints supporting RFC 7675 might >>> maintain consent on pairs currently not >>> >used for media, in order to be able to re-nominate in case consent for >>> the currently nominated pair expires. However, >>> >RFC 7675 does not explicitly say anything about that." >>> > >>> >[BA] RFC 7675 Section 5 says: >>> > >>> > Initial consent to send traffic is obtained using ICE [RFC5245]. A= n >>> > endpoint gains consent to send on a candidate pair when the pair >>> > enters the Succeeded ICE state. >>> > >>> >Given this, an RFC 5245bis implementation might request consent to sen= d >>> to >>> >multiple remote peer candidates, so as to keep them alive. However, >>> >there is nothing in RFC 7675 that requires the responder to grant >>> >consent for that. For example, based on the text in RFC 5245bis >>> >Section 7.1.1, a conforming implementation might well revoke >>> >consent on local candidates other than the local candidate in the >>> >selected pair. >>> >>> Sure - the responder is not mandated to grant consent to multiple >>> candidates after nomination. But, the option to do seems to be there >>> (unless I've understood the RFC wrong), and the only reason to do so wo= uld >>> be possible re-nomination. >>> >>> Anyway, I don't have any strong feelings which way we go, but we do nee= d >>> to make it clear in the spec whether re-nomination is allowed or not. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> Hi Bernard, >>> >>> Support of 5245bis is also negotiated, using the =E2=80=9Cice2=E2=80=9D= ICE option. >>> >>> Also, my understanding was that endpoints supporting RFC 7675 might >>> maintain consent on pairs currently not used for media, in order to be = able >>> to re-nominate in case consent for the currently nominated pair expires= . >>> However, RFC 7675 does not explicitly say anything about that. >>> >>> Regards, >>> >>> Christer >>> >>> From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Bernard Aboba >>> Sent: 20 July 2017 14:22 >>> To: ice@ietf.org >>> Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bi= s >>> >>> During the ICE WG meeting today, there was discussion of whether >>> RFC5245bis should indicate that it is possible to re-nominate pairs >>> (proposed by Peter), or whether it is possible to switch from one inter= face >>> to another (Cullen). While these capabilities are desirable, attemptin= g to >>> add them to RFC 5245bis without negotiation has the potential to break >>> interoperability with existing RFC 5245 implementations. >>> >>> In my experience, this is an area where RFC 5245 implementations have >>> very different interpretations. For example, some implementations (e.g. >>> ones that did not support aggressive) discard non-selected candidate pa= irs >>> after nomination. These implementations (e.g. particularly ones include= d in >>> previous product releases) cannot be assumed to change their behavior a= fter >>> RFC 5245bis is published. This raises the possibility that that >>> interoperability could be impacted. >>> >>> Since in practice the desired candidate pair switching capabilities are >>> most likely to be supported in WebRTC implementations supporting Trickl= e >>> ICE, my recommendation is to think of candidate pair switching as a Tri= ckle >>> ICE capability. Since Trickle-ICE support is negotiated, clarificatio= ns >>> relating to candidate-pair switching can be linked to that negotiation. >>> >>> This provides a potential way forward that bypasses potential >>> interoperability issues. For example, if text on candidate-pair switch= ing >>> is to be added to (either to RFC 5245bis or Trickle-ICE) then the text >>> could say that support for these behaviors can only be assumed if they = are >>> explicitly negotiated. The Trickle-ICE document could then create norma= tive >>> requirements for support of the new behaviors by stating that support f= or >>> them is mandatory when supporting full-Trickle. >>> >>> >>> >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >> > --001a11c1691e5810500557fafdec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As far as "just enough" so that it isn't a h= indrance: that's why I wanted to say that agents *may* switch.=C2=A0 It= allows a renomination in the future.=C2=A0 Saying they MUST NOT is a hindr= ance.=C2=A0 I would be fine if the *may* requires negotiation.=C2=A0 That&#= 39;s what=C2=A0

On Wed= , Aug 30, 2017 at 9:08 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:
Peter said:=C2=A0

"= ;Your reasoning for saying that an agent c= an't switch candidate pairs is that it prevents the remote side from be= ing able to release resources.=C2=A0 But the switching side would only swit= ch if the candidate pair recently received an ICE check response (in other = words, it knows the candidate pair works), in which case it knows that reso= urces have not been released."

[BA] There is a dicotomy between the situation prior to nom= ination and after it that isn't explained well in RFC 5245bis.=C2=A0 Pr= ior to nomination, the agent can switch between validated candidate pairs, = and hopefully we can make the language clear enough so that this will work = well.=C2=A0

While the same logic applies after nom= ination as well (e.g. it only makes sense to switch a valid pair), the text= doesn't clarify the meaning of nomination with respect to resource rel= ease, nor does it talk about consent (presumably the mechanism that would b= e used to maintain pair validity after nomination), so that it's not cl= ear how pair validity could be maintained.=C2=A0 Since there is much RFC 52= 45 text still remaining, the overall document reads as though while it repr= esents an update to RFC 5245 it still is based on a pre-WebRTC mindset.=C2= =A0

All this makes me wonder whether we should= limit our aspirations for RFC 5245bis to clarifying things "just enou= gh" so that it isn't a hindrance.=C2=A0 People interested in build= ing a modern ICE implementation for use in WebRTC will probably focus more = on Trickle-ICE, where implementation of consent can be assumed, and perhaps= the meaning of nomination within a WebRTC context could be better explaine= d.=C2=A0



On Wed, Aug 30, 2017 at 11:19 AM, Peter Th= atcher <pthatcher@google.com> wrote:
#2 and #3 are fine, but I'm not a fan of= #1.

Your reasoning for saying that an agent can't s= witch candidate pairs is that it prevents the remote side from being able t= o release resources.=C2=A0 But the switching side would only switch if the = candidate pair recently received an ICE check response (in other words, it = knows the candidate pair works), in which case it knows that resources have= not been released.

In other words, if the remote = side chose to release resources, the local side wouldn't do the switch.= =C2=A0 So the remote side is free to release resources; it's not preven= ted from doing so.=C2=A0 If it does, then the local side will notice and no= t do a switch. =C2=A0 But if the remote side doesn't release the resour= ces, then the local side may switch.

In other word= s, I think we can allow switching and resource release both.=C2=A0

On Thu, Jul 27, 2017 at 4:01 AM Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer= .holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Would anyone disagree with the follow= ing:

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 explicitly indicating that re-no= mination is *NOT* allowed without ICE restart; and

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 once a pair has been selected, a= gents need to be able to send *AND* receive media using that pair = =E2=80=93 but not using any other pair (read: resources associated with other pairs may be release= d); and

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PRIOR to selection, agents need = to be able to send *AND* receive media on any valid pair (RFC 7675 a= dds restrictions, but that=E2=80=99s outside the scope of 5245bis)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0<= /u>

From: = Ice [mailto:ice-b= ounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 25 July 2017 10:17
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: ice@ietf.org
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC= 5245bis

=C2=A0

Hi Bernard,

=C2=A0

Regarding sending media PRIOR to nomi= nation, we have previously agreed that any valid pair can be used for that.= Perhaps it needs more clarification.

=C2=A0

Regarding receiving media after nomin= ation, it was discussed in Prague, as it is covered by Peter=E2=80=99s PR. = I don=E2=80=99t have access to the PR/minutes right now, but I think the outcome was that an agent is only ex= pected to receive media on the nominated pair (otherwise it cannot free res= ources).

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Bernard Aboba [mailto:bernard.aboba@gmail.com]
Sent: 25 July 2017 02:29
To: Christer Holmberg <christer.holmberg@ericsson= .com>
Cc: ice@ietf.org
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC= 5245bis

=C2=A0

Christer said:=C2=A0

=C2=A0

"The whole disc= ussion began when I was given a comment that the text above should be modif= ied, to clarify that the pair used for media can change after a pair has be= en selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)"=C2=A0

=C2=A0

[BA]=C2=A0Currently,= use of the "ice2" ICE option forestalls use of aggressive nomina= tion (e.g. setting the nominated flag on more than one pair).=C2=A0 Since o= nly the selected pair can be used to send media, that would seem to rule out changing the pair used for media after a pair has been se= lected:=C2=A0

=C2=A0

=C2=A0=C2=A0 Once a candidate pair has bee=
n selected
=C2=A0=C2=A0 only that candidate pair (ref=
erred to as selected pair) is used for
=C2=A0=C2=A0 sending media.<=
/span>

=C2=A0

What about changing the pair used for media prior to= selection?=C2=A0 On this point, the text seems less clear than it could be= .=C2=A0

=C2=A0

Prior to nomination,= the specification allows the sending of media on a successful pair:=

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Once there is at leas=
t one nominated pair in the VALID LIST for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 every compo=
nent of at least one media stream and the state of the=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHECK LIST =
is Running:
=C2=A0
...
=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*=C2=
=A0 The agent MUST continue to respond to any checks it may still=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 receive for that media stream, and MUST perform triggered<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 checks if required by the processing of Section 6.3.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 The=
 agent MAY begin transmitting media for this media stream as=C2=A0

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0described in Section 11= .1.

=C2=A0

However, the specifi= cation is not clear enough about the receiving side; while it recommends th= at implementations be prepared to receive prior to nomination, it does not = require this.=C2=A0From Section 11.2:=C2=A0

=C2=A0

=C2=A0=C2=A0 ICE implementations SHOULD by=
 default be
=C2=A0=C2=A0 prepared to receive media on =
any of the candidates provided in the
=C2=A0=C2=A0 most recent candidate exchang=
e with the peer.
=C2=A0
What happens if an implementation is NOT p=
repared to receive media?
In WebRTC, an implementation cannot send w=
ithout consent, which 
suggests that perhaps an unwilling receive=
r could use consent to
influence the potential sender. =

=C2=A0
However, the specification does not even r=
eference RFC 7675,
so it is left unclear about how this is to=
 be done.
For example, a receiver might not reply to=
 a consent
request if the inability to receive is tem=
porary ("I'm not ready yet"),
but that might cause consent to time out p=
rior to nomination and
might even influence pair selection inappr=
opriately.
=C2=A0
Another choice might be to revoke consent =
(which would
invalidate the pair).=C2=A0 But that's=
 pretty drastic unless the
pair is truly unacceptable. =

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

>[B= A] RFC 5245bis Section 7.1.1 continues to imply a single selected pair:=C2= =A0
>
>=C2=A0 =C2=A0Eventually, there will be only a single nomi= nated pair in the VALID
>=C2=A0 =C2=A0LIST for each component.=C2=A0 Once the stat= e of the CHECK LIST is set to
>=C2=A0 =C2=A0Completed, that exact pair is selected by IC= E for sending and
>=C2=A0 =C2=A0receiving media for that component. >
>Based on that text, an implementation might still release= resources (e.g. unused TURN candidates) post-nomination. Given this, the= =C2=A0"ice2" ICE option doesn't address >potential interop= erability issues resulting from different resource release behaviors (although it does clear indicate lack of support for agg= ressive nomination):=C2=A0

The whole discussion began when I was given a comment that the text above s= hould be modified, to clarify that the pair used for media can change after= a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)

>=C2=A0 =C2=A0NOTE: A controlling agent that does not supp= ort this specification
>=C2=A0 =C2=A0(i.e. it is implemented according to RFC 524= 5) might nominate more
>=C2=A0 =C2=A0than one candidate pair.=C2=A0 This was refe= rred to as aggressive
>=C2=A0 =C2=A0nomination in RFC 5245.=C2=A0 The usage of t= he 'ice2' ice option by
>=C2=A0 =C2=A0endpoints supporting this specifcation shoul= d prevent such
>=C2=A0 =C2=A0controlling agents from using aggressive nom= ination.
>
>Christer also said:=C2=A0
>
>"Also, my understanding was that endpoints supportin= g RFC 7675 might maintain consent on pairs currently not
>used for media, in order to be able to re-nominate in cas= e consent for the currently nominated pair expires. However,
>RFC 7675 does not explicitly say anything about that.&quo= t;
>
>[BA] RFC 7675 Section 5 says:=C2=A0
>
>=C2=A0 =C2=A0Initial consent to send traffic is obtained = using ICE [RFC5245].=C2=A0 An
>=C2=A0 =C2=A0endpoint gains consent to send on a candidat= e pair when the pair
>=C2=A0 =C2=A0enters the Succeeded ICE state.
>
>Given this, an RFC 5245bis implementation might request c= onsent to send to
>multiple remote peer candidates, so as to keep them alive= . However,
>there is nothing in RFC 7675 that requires the responder = to grant
>consent for that.=C2=A0 For example, based on the text in= RFC 5245bis
>Section 7.1.1, a conforming implementation might well rev= oke
>consent on local candidates other than the local candidat= e in the
>selected pair.

Sure - the responder is not mandated to grant consent to multiple candidate= s after nomination. But, the option to do seems to be there (unless I'v= e understood the RFC wrong), and the only reason to do so would be possible= re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do nee= d to make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer

=C2=A0

On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi
,
>[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected pai= r:=C2=A0
>
>=C2=A0 =C2=A0Eventually, there will be only a single nominated pair in = the VALID
>=C2=A0 =C2=A0LIST for each component.=C2=A0 Once the state of the CHECK= LIST is set to
>=C2=A0 =C2=A0Completed, that exact pair is selected by ICE for sending = and
>=C2=A0 =C2=A0receiving media for that component.
>
>Based on that text, an implementation might still release resources (e.= g. unused TURN candidates) post-nomination. Given this, the=C2=A0"ice2= " ICE option doesn't address >potential interoperability issues= resulting from different resource release behaviors (although it does clear indicate lack of support for aggressive nomination):=C2=A0
The whole discussion began when I was given a comment that the text above s= hould be modified, to clarify that the pair used for media can change after= a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)

>=C2=A0 =C2=A0NOTE: A controlling agent that does not support this speci= fication
>=C2=A0 =C2=A0(i.e. it is implemented according to RFC 5245) might nomin= ate more
>=C2=A0 =C2=A0than one candidate pair.=C2=A0 This was referred to as agg= ressive
>=C2=A0 =C2=A0nomination in RFC 5245.=C2=A0 The usage of the 'ice2&#= 39; ice option by
>=C2=A0 =C2=A0endpoints supporting this specifcation should prevent such=
>=C2=A0 =C2=A0controlling agents from using aggressive nomination.
>
>Christer also said:=C2=A0
>
>"Also, my understanding was that endpoints supporting RFC 7675 mig= ht maintain consent on pairs currently not
>used for media, in order to be able to re-nominate in case consent for = the currently nominated pair expires. However,
>RFC 7675 does not explicitly say anything about that."
>
>[BA] RFC 7675 Section 5 says:=C2=A0
>
>=C2=A0 =C2=A0Initial consent to send traffic is obtained using ICE [RFC= 5245].=C2=A0 An
>=C2=A0 =C2=A0endpoint gains consent to send on a candidate pair when th= e pair
>=C2=A0 =C2=A0enters the Succeeded ICE state.
>
>Given this, an RFC 5245bis implementation might request consent to send= to
>multiple remote peer candidates, so as to keep them alive. However,
>there is nothing in RFC 7675 that requires the responder to grant
>consent for that.=C2=A0 For example, based on the text in RFC 5245bis >Section 7.1.1, a conforming implementation might well revoke
>consent on local candidates other than the local candidate in the
>selected pair.

Sure - the responder is not mandated to grant consent to multiple candidate= s after nomination. But, the option to do seems to be there (unless I'v= e understood the RFC wrong), and the only reason to do so would be possible= re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do nee= d to make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer





On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
Hi Bernard,
=C2=A0
Support of 5245bis is also negotiated, using the =E2=80=9Cice2=E2=80=9D ICE= option.
=C2=A0
Also, my understanding was that endpoints supporting RFC 7675 might maintai= n consent on pairs currently not used for media, in order to be able to re-= nominate in case consent for the currently nominated pair expires. However,= RFC 7675 does not explicitly say anything about that.
=C2=A0
Regards,
=C2=A0
Christer
=C2=A0
From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 20 July 2017 14:22
To: ice@ietf.org
Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis =C2=A0
During the ICE WG meeting today, there was discussion of whether RFC5245bis= should indicate that it is possible to re-nominate pairs (proposed by Pete= r), or whether it is possible to switch from one interface to another (Cull= en).=C2=A0 While these capabilities are desirable, attempting to add them to RFC 5245bis without negotiation has t= he potential to break interoperability with existing RFC 5245 implementatio= ns.
=C2=A0
In my experience, this is an area where RFC 5245 implementations have very = different interpretations. For example, some implementations (e.g. ones tha= t did not support aggressive) discard non-selected candidate pairs after no= mination. These implementations (e.g. particularly ones included in previous product releases) cannot be a= ssumed to change their behavior after RFC 5245bis is published.=C2=A0 This = raises the possibility that that interoperability could be impacted.=C2=A0<= br> =C2=A0
Since in practice the desired candidate pair switching capabilities are mos= t likely to be supported in WebRTC implementations supporting Trickle ICE, = my recommendation is to think of candidate pair switching as a Trickle ICE = capability. =C2=A0 Since Trickle-ICE support is negotiated, clarifications relating to candidate-pair switching= can be linked to that negotiation. =C2=A0
=C2=A0
This provides a potential way forward that bypasses potential interoperabil= ity issues.=C2=A0 For example, if text on candidate-pair switching is to be= added to (either to RFC 5245bis or Trickle-ICE) then the text could say th= at support for these behaviors can only be assumed if they are explicitly negotiated. The Trickle-ICE document cou= ld then create normative requirements for support of the new behaviors by s= tating that support for them is mandatory when supporting full-Trickle.=C2= =A0
=C2=A0
=C2=A0

=C2=A0

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice

--001a11c1691e5810500557fafdec-- From nobody Wed Aug 30 09:28:29 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282CD132055 for ; Wed, 30 Aug 2017 09:28:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 IEiYjN4dk0i1 for ; Wed, 30 Aug 2017 09:28:24 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 B02FD13202D for ; Wed, 30 Aug 2017 09:28:24 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id k77so55341870oib.2 for ; Wed, 30 Aug 2017 09:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=btYBiikLAc4h3SvqxvG2MLJ5jDqj+QINIjt19zxriy0=; b=C1TfPVSp+Z+GSZ8VJX42GNDqr76wEIiSyIRMVdjo9hI3nYym86XjgndbdcMBUm7tfD ipkT2bnGlbIrXY+R7c7ldlOXTy7I4ZNVDoLs0HHMHFbGrYA3KLvD/90/heQbIj3xhrU3 0EWw2GFiooNtNJ8faNMnAwkS1+15fsS8hYueJMwPQOvdm0HUL33GTdQCA68rc01soYbP GeRNZrwpx5hOKnOC+MreUcLs2WYtBCJDg7PuBvTcjVdO43P+fFbNfnNWA3qK/H8eryVv OjcQ+RPFs9Tsw03ZwtQtoMaPlKmj7chrr6nAUg9rXWQyu1vHP2Cfb+nlNplchFp6KyKU dB/Q== 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=btYBiikLAc4h3SvqxvG2MLJ5jDqj+QINIjt19zxriy0=; b=QFKgT/P5IaIKerGx+R8NKjcjvFYUk01f5Ys4abByWeAPxYPYJVaaXj9QP28utNC/L+ B1j/li3FEWQBJYBB2opqRhp+dt5Cv6NN8Bwxc8rQY873Ky9gKKyyWx1BZlJ5pTS83w6P CS7O8CJQYPIY3sZYd5WtksOLHcCL7UDZsfg7pYYmW3CpBEKIa9OonC0MzS/NBPXZfBCj W11puap4NtO1KvSWPHjtaSMUamrZP6hHRT43PJ+FcOBm14RKm/KoakpKm3OMbQDxfH9n PxiZ++pTmybrKNfUjB/Q5sY/k/GP3VSq/xawTq6Lr9Z7pUsF5eMahePb72IjPMR+5l/5 ffLA== X-Gm-Message-State: AHYfb5hNzZqVL9GgoVomoKAV2rDKz5Q3k25qEArQ3yG6feKSxeePc55g /HL8trNm2SV91DPgIMPrsJl+XdD4xp905Fs= X-Google-Smtp-Source: ADKCNb6tY0mcwG5sdMxB5F+nv7vzG1JoF4dPxg48HwjszCP8BYB1ERMaj/BLnSFttvQs+J1qSN9f0oZnCHypfHEKZfw= X-Received: by 10.202.105.198 with SMTP id e189mr1903541oic.195.1504110503618; Wed, 30 Aug 2017 09:28:23 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> In-Reply-To: From: Peter Thatcher Date: Wed, 30 Aug 2017 16:28:12 +0000 Message-ID: To: Bernard Aboba Cc: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a1141b266461aaf0557fb047f" Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 16:28:28 -0000 --001a1141b266461aaf0557fb047f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oops, hit send too soon. That's what https://www.ietf.org/archive/id/draft-thatcher-ice-renomination-01.txt does= : it negotiates "renomination". And that's what Chrome's implementation of WebRTC does. On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher wrote= : > As far as "just enough" so that it isn't a hindrance: that's why I wanted > to say that agents *may* switch. It allows a renomination in the future. > Saying they MUST NOT is a hindrance. I would be fine if the *may* requir= es > negotiation. That's what > > On Wed, Aug 30, 2017 at 9:08 AM Bernard Aboba > wrote: > >> Peter said: >> >> "Your reasoning for saying that an agent can't switch candidate pairs is >> that it prevents the remote side from being able to release resources. = But >> the switching side would only switch if the candidate pair recently >> received an ICE check response (in other words, it knows the candidate p= air >> works), in which case it knows that resources have not been released." >> >> [BA] There is a dicotomy between the situation prior to nomination and >> after it that isn't explained well in RFC 5245bis. Prior to nomination, >> the agent can switch between validated candidate pairs, and hopefully we >> can make the language clear enough so that this will work well. >> >> While the same logic applies after nomination as well (e.g. it only make= s >> sense to switch a valid pair), the text doesn't clarify the meaning of >> nomination with respect to resource release, nor does it talk about cons= ent >> (presumably the mechanism that would be used to maintain pair validity >> after nomination), so that it's not clear how pair validity could be >> maintained. Since there is much RFC 5245 text still remaining, the over= all >> document reads as though while it represents an update to RFC 5245 it st= ill >> is based on a pre-WebRTC mindset. >> >> All this makes me wonder whether we should limit our aspirations for RFC >> 5245bis to clarifying things "just enough" so that it isn't a hindrance. >> People interested in building a modern ICE implementation for use in Web= RTC >> will probably focus more on Trickle-ICE, where implementation of consent >> can be assumed, and perhaps the meaning of nomination within a WebRTC >> context could be better explained. >> >> >> >> On Wed, Aug 30, 2017 at 11:19 AM, Peter Thatcher >> wrote: >> >>> #2 and #3 are fine, but I'm not a fan of #1. >>> >>> Your reasoning for saying that an agent can't switch candidate pairs is >>> that it prevents the remote side from being able to release resources. = But >>> the switching side would only switch if the candidate pair recently >>> received an ICE check response (in other words, it knows the candidate = pair >>> works), in which case it knows that resources have not been released. >>> >>> In other words, if the remote side chose to release resources, the loca= l >>> side wouldn't do the switch. So the remote side is free to release >>> resources; it's not prevented from doing so. If it does, then the loca= l >>> side will notice and not do a switch. But if the remote side doesn't >>> release the resources, then the local side may switch. >>> >>> In other words, I think we can allow switching and resource release >>> both. >>> >>> On Thu, Jul 27, 2017 at 4:01 AM Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> Would anyone disagree with the following: >>>> >>>> >>>> >>>> 1) explicitly indicating that re-nomination is **NOT** allowed >>>> without ICE restart; and >>>> >>>> 2) once a pair has been selected, agents need to be able to send = * >>>> *AND** receive media using that pair =E2=80=93 but not using any other= pair >>>> (read: resources associated with other pairs may be released); and >>>> >>>> 3) PRIOR to selection, agents need to be able to send **AND** >>>> receive media on any valid pair (RFC 7675 adds restrictions, but that= =E2=80=99s >>>> outside the scope of 5245bis) >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> Christer >>>> >>>> >>>> >>>> *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Christer >>>> Holmberg >>>> *Sent:* 25 July 2017 10:17 >>>> *To:* Bernard Aboba >>>> *Cc:* ice@ietf.org >>>> *Subject:* Re: [Ice] Re-nomination and candidate pair switching in RFC >>>> 5245bis >>>> >>>> >>>> >>>> Hi Bernard, >>>> >>>> >>>> >>>> Regarding sending media PRIOR to nomination, we have previously agreed >>>> that any valid pair can be used for that. Perhaps it needs more >>>> clarification. >>>> >>>> >>>> >>>> Regarding receiving media after nomination, it was discussed in Prague= , >>>> as it is covered by Peter=E2=80=99s PR. I don=E2=80=99t have access to= the PR/minutes right >>>> now, but I think the outcome was that an agent is only expected to rec= eive >>>> media on the nominated pair (otherwise it cannot free resources). >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> Christer >>>> >>>> >>>> >>>> *From:* Bernard Aboba [mailto:bernard.aboba@gmail.com >>>> ] >>>> *Sent:* 25 July 2017 02:29 >>>> *To:* Christer Holmberg >>>> *Cc:* ice@ietf.org >>>> *Subject:* Re: [Ice] Re-nomination and candidate pair switching in RFC >>>> 5245bis >>>> >>>> >>>> >>>> Christer said: >>>> >>>> >>>> >>>> "The whole discussion began when I was given a comment that the text >>>> above should be modified, to clarify that the pair used for media can >>>> change after a pair has been selected. >>>> >>>> But, if the outcome is that the pair can NOT change, maybe we need to >>>> clarify THAT instead :)" >>>> >>>> >>>> >>>> [BA] Currently, use of the "ice2" ICE option forestalls use of >>>> aggressive nomination (e.g. setting the nominated flag on more than on= e >>>> pair). Since only the selected pair can be used to send media, that w= ould >>>> seem to rule out changing the pair used for media after a pair has bee= n >>>> selected: >>>> >>>> >>>> >>>> Once a candidate pair has been selected >>>> >>>> only that candidate pair (referred to as selected pair) is used for >>>> >>>> sending media. >>>> >>>> >>>> >>>> What about changing the pair used for media prior to selection? On >>>> this point, the text seems less clear than it could be. >>>> >>>> >>>> >>>> Prior to nomination, the specification allows the sending of media on = a >>>> successful pair: >>>> >>>> >>>> >>>> o Once there is at least one nominated pair in the VALID LIST for >>>> >>>> every component of at least one media stream and the state of th= e >>>> >>>> CHECK LIST is Running: >>>> >>>> >>>> >>>> ... >>>> >>>> >>>> >>>> * The agent MUST continue to respond to any checks it may still >>>> >>>> receive for that media stream, and MUST perform triggered >>>> >>>> checks if required by the processing of Section 6.3 . >>>> >>>> >>>> >>>> * The agent MAY begin transmitting media for this media stream = as >>>> >>>> described in Section 11.1 >>>> >>>> . >>>> >>>> >>>> >>>> However, the specification is not clear enough about the receiving >>>> side; while it recommends that implementations be prepared to receive = prior >>>> to nomination, it does not require this. From Section 11.2: >>>> >>>> >>>> >>>> ICE implementations SHOULD by default be >>>> >>>> prepared to receive media on any of the candidates provided in the >>>> >>>> most recent candidate exchange with the peer. >>>> >>>> >>>> >>>> What happens if an implementation is NOT prepared to receive media? >>>> >>>> In WebRTC, an implementation cannot send without consent, which >>>> >>>> suggests that perhaps an unwilling receiver could use consent to >>>> >>>> influence the potential sender. >>>> >>>> >>>> >>>> However, the specification does not even reference RFC 7675, >>>> >>>> so it is left unclear about how this is to be done. >>>> >>>> For example, a receiver might not reply to a consent >>>> >>>> request if the inability to receive is temporary ("I'm not ready yet")= , >>>> >>>> but that might cause consent to time out prior to nomination and >>>> >>>> might even influence pair selection inappropriately. >>>> >>>> >>>> >>>> Another choice might be to revoke consent (which would >>>> >>>> invalidate the pair). But that's pretty drastic unless the >>>> >>>> pair is truly unacceptable. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected >>>> pair: >>>> > >>>> > Eventually, there will be only a single nominated pair in the VALI= D >>>> > LIST for each component. Once the state of the CHECK LIST is set = to >>>> > Completed, that exact pair is selected by ICE for sending and >>>> > receiving media for that component. >>>> > >>>> >Based on that text, an implementation might still release resources >>>> (e.g. unused TURN candidates) post-nomination. Given this, the "ice2" = ICE >>>> option doesn't address >potential interoperability issues resulting fr= om >>>> different resource release behaviors (although it does clear indicate = lack >>>> of support for aggressive nomination): >>>> >>>> The whole discussion began when I was given a comment that the text >>>> above should be modified, to clarify that the pair used for media can >>>> change after a pair has been selected. >>>> >>>> But, if the outcome is that the pair can NOT change, maybe we need to >>>> clarify THAT instead :) >>>> >>>> > NOTE: A controlling agent that does not support this specification >>>> > (i.e. it is implemented according to RFC 5245) might nominate more >>>> > than one candidate pair. This was referred to as aggressive >>>> > nomination in RFC 5245. The usage of the 'ice2' ice option by >>>> > endpoints supporting this specifcation should prevent such >>>> > controlling agents from using aggressive nomination. >>>> > >>>> >Christer also said: >>>> > >>>> >"Also, my understanding was that endpoints supporting RFC 7675 might >>>> maintain consent on pairs currently not >>>> >used for media, in order to be able to re-nominate in case consent fo= r >>>> the currently nominated pair expires. However, >>>> >RFC 7675 does not explicitly say anything about that." >>>> > >>>> >[BA] RFC 7675 Section 5 says: >>>> > >>>> > Initial consent to send traffic is obtained using ICE [RFC5245]. = An >>>> > endpoint gains consent to send on a candidate pair when the pair >>>> > enters the Succeeded ICE state. >>>> > >>>> >Given this, an RFC 5245bis implementation might request consent to >>>> send to >>>> >multiple remote peer candidates, so as to keep them alive. However, >>>> >there is nothing in RFC 7675 that requires the responder to grant >>>> >consent for that. For example, based on the text in RFC 5245bis >>>> >Section 7.1.1, a conforming implementation might well revoke >>>> >consent on local candidates other than the local candidate in the >>>> >selected pair. >>>> >>>> Sure - the responder is not mandated to grant consent to multiple >>>> candidates after nomination. But, the option to do seems to be there >>>> (unless I've understood the RFC wrong), and the only reason to do so w= ould >>>> be possible re-nomination. >>>> >>>> Anyway, I don't have any strong feelings which way we go, but we do >>>> need to make it clear in the spec whether re-nomination is allowed or = not. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg < >>>> christer.holmberg@ericsson.com> wrote: >>>> >>>> Hi >>>> , >>>> >[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected >>>> pair: >>>> > >>>> > Eventually, there will be only a single nominated pair in the VALI= D >>>> > LIST for each component. Once the state of the CHECK LIST is set = to >>>> > Completed, that exact pair is selected by ICE for sending and >>>> > receiving media for that component. >>>> > >>>> >Based on that text, an implementation might still release resources >>>> (e.g. unused TURN candidates) post-nomination. Given this, the "ice2" = ICE >>>> option doesn't address >potential interoperability issues resulting fr= om >>>> different resource release behaviors (although it does clear indicate = lack >>>> of support for aggressive nomination): >>>> >>>> The whole discussion began when I was given a comment that the text >>>> above should be modified, to clarify that the pair used for media can >>>> change after a pair has been selected. >>>> >>>> But, if the outcome is that the pair can NOT change, maybe we need to >>>> clarify THAT instead :) >>>> >>>> > NOTE: A controlling agent that does not support this specification >>>> > (i.e. it is implemented according to RFC 5245) might nominate more >>>> > than one candidate pair. This was referred to as aggressive >>>> > nomination in RFC 5245. The usage of the 'ice2' ice option by >>>> > endpoints supporting this specifcation should prevent such >>>> > controlling agents from using aggressive nomination. >>>> > >>>> >Christer also said: >>>> > >>>> >"Also, my understanding was that endpoints supporting RFC 7675 might >>>> maintain consent on pairs currently not >>>> >used for media, in order to be able to re-nominate in case consent fo= r >>>> the currently nominated pair expires. However, >>>> >RFC 7675 does not explicitly say anything about that." >>>> > >>>> >[BA] RFC 7675 Section 5 says: >>>> > >>>> > Initial consent to send traffic is obtained using ICE [RFC5245]. = An >>>> > endpoint gains consent to send on a candidate pair when the pair >>>> > enters the Succeeded ICE state. >>>> > >>>> >Given this, an RFC 5245bis implementation might request consent to >>>> send to >>>> >multiple remote peer candidates, so as to keep them alive. However, >>>> >there is nothing in RFC 7675 that requires the responder to grant >>>> >consent for that. For example, based on the text in RFC 5245bis >>>> >Section 7.1.1, a conforming implementation might well revoke >>>> >consent on local candidates other than the local candidate in the >>>> >selected pair. >>>> >>>> Sure - the responder is not mandated to grant consent to multiple >>>> candidates after nomination. But, the option to do seems to be there >>>> (unless I've understood the RFC wrong), and the only reason to do so w= ould >>>> be possible re-nomination. >>>> >>>> Anyway, I don't have any strong feelings which way we go, but we do >>>> need to make it clear in the spec whether re-nomination is allowed or = not. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg < >>>> christer.holmberg@ericsson.com> wrote: >>>> Hi Bernard, >>>> >>>> Support of 5245bis is also negotiated, using the =E2=80=9Cice2=E2=80= =9D ICE option. >>>> >>>> Also, my understanding was that endpoints supporting RFC 7675 might >>>> maintain consent on pairs currently not used for media, in order to be= able >>>> to re-nominate in case consent for the currently nominated pair expire= s. >>>> However, RFC 7675 does not explicitly say anything about that. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Bernard Aboba >>>> Sent: 20 July 2017 14:22 >>>> To: ice@ietf.org >>>> Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245b= is >>>> >>>> During the ICE WG meeting today, there was discussion of whether >>>> RFC5245bis should indicate that it is possible to re-nominate pairs >>>> (proposed by Peter), or whether it is possible to switch from one inte= rface >>>> to another (Cullen). While these capabilities are desirable, attempti= ng to >>>> add them to RFC 5245bis without negotiation has the potential to break >>>> interoperability with existing RFC 5245 implementations. >>>> >>>> In my experience, this is an area where RFC 5245 implementations have >>>> very different interpretations. For example, some implementations (e.g= . >>>> ones that did not support aggressive) discard non-selected candidate p= airs >>>> after nomination. These implementations (e.g. particularly ones includ= ed in >>>> previous product releases) cannot be assumed to change their behavior = after >>>> RFC 5245bis is published. This raises the possibility that that >>>> interoperability could be impacted. >>>> >>>> Since in practice the desired candidate pair switching capabilities ar= e >>>> most likely to be supported in WebRTC implementations supporting Trick= le >>>> ICE, my recommendation is to think of candidate pair switching as a Tr= ickle >>>> ICE capability. Since Trickle-ICE support is negotiated, clarificati= ons >>>> relating to candidate-pair switching can be linked to that negotiation= . >>>> >>>> This provides a potential way forward that bypasses potential >>>> interoperability issues. For example, if text on candidate-pair switc= hing >>>> is to be added to (either to RFC 5245bis or Trickle-ICE) then the text >>>> could say that support for these behaviors can only be assumed if they= are >>>> explicitly negotiated. The Trickle-ICE document could then create norm= ative >>>> requirements for support of the new behaviors by stating that support = for >>>> them is mandatory when supporting full-Trickle. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ice mailing list >>>> Ice@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ice >>>> >>> >> --001a1141b266461aaf0557fb047f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oops, hit send too soon.

That's wha= t=C2=A0https://www.ietf.org/archive/id/draft-thatcher-ice-renominat= ion-01.txt=C2=A0does: it negotiates "renomination".=C2=A0 And= that's what Chrome's implementation of WebRTC does.=C2=A0

On Wed, Aug 30, 2017 at = 9:26 AM Peter Thatcher <pthatche= r@google.com> wrote:
As far as "just enough" so that it isn't a hindranc= e: that's why I wanted to say that agents *may* switch.=C2=A0 It allows= a renomination in the future.=C2=A0 Saying they MUST NOT is a hindrance.= =C2=A0 I would be fine if the *may* requires negotiation.=C2=A0 That's = what=C2=A0

On Wed, Aug= 30, 2017 at 9:08 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:
Peter said:=C2=A0

"Your reasoning for saying th= at an agent can't switch candidate pairs is that it prevents the remote= side from being able to release resources.=C2=A0 But the switching side wo= uld only switch if the candidate pair recently received an ICE check respon= se (in other words, it knows the candidate pair works), in which case it kn= ows that resources have not been released."

[BA] There is a dicotomy between the situation= prior to nomination and after it that isn't explained well in RFC 5245= bis.=C2=A0 Prior to nomination, the agent can switch between validated cand= idate pairs, and hopefully we can make the language clear enough so that th= is will work well.=C2=A0

While the same logic appl= ies after nomination as well (e.g. it only makes sense to switch a valid pa= ir), the text doesn't clarify the meaning of nomination with respect to= resource release, nor does it talk about consent (presumably the mechanism= that would be used to maintain pair validity after nomination), so that it= 's not clear how pair validity could be maintained.=C2=A0 Since there i= s much RFC 5245 text still remaining, the overall document reads as though = while it represents an update to RFC 5245 it still is based on a pre-WebRTC= mindset.=C2=A0

All this makes me wonder wheth= er we should limit our aspirations for RFC 5245bis to clarifying things &qu= ot;just enough" so that it isn't a hindrance.=C2=A0 People interes= ted in building a modern ICE implementation for use in WebRTC will probably= focus more on Trickle-ICE, where implementation of consent can be assumed,= and perhaps the meaning of nomination within a WebRTC context could be bet= ter explained.=C2=A0



On Wed, Aug 30, 2017 at 11:19 = AM, Peter Thatcher <pthatcher@google.com> wrote:
#2 and #3 are fine, but I'm = not a fan of #1.

Your reasoning for saying that an agent= can't switch candidate pairs is that it prevents the remote side from = being able to release resources.=C2=A0 But the switching side would only sw= itch if the candidate pair recently received an ICE check response (in othe= r words, it knows the candidate pair works), in which case it knows that re= sources have not been released.

In other words, if= the remote side chose to release resources, the local side wouldn't do= the switch.=C2=A0 So the remote side is free to release resources; it'= s not prevented from doing so.=C2=A0 If it does, then the local side will n= otice and not do a switch. =C2=A0 But if the remote side doesn't releas= e the resources, then the local side may switch.

I= n other words, I think we can allow switching and resource release both.=C2= =A0

On Thu, Jul 27, 2017 a= t 4:01 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
<= /div>

Hi,

=C2=A0

Would anyone disagree with the follow= ing:

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 explicitly indicating that re-no= mination is *NOT* allowed without ICE restart; and

2)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 once a pair has been selected, a= gents need to be able to send *AND* receive media using that pair = =E2=80=93 but not using any other pair (read: resources associated with other pairs may be release= d); and

3)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 PRIOR to selection, agents need = to be able to send *AND* receive media on any valid pair (RFC 7675 a= dds restrictions, but that=E2=80=99s outside the scope of 5245bis)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Ice [mailto:ice-b= ounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 25 July 2017 10:17
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: ice@ietf.org
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC= 5245bis

=C2=A0

Hi Bernard,

=C2=A0

Regarding sending media PRIOR to nomi= nation, we have previously agreed that any valid pair can be used for that.= Perhaps it needs more clarification.

=C2=A0

Regarding receiving media after nomin= ation, it was discussed in Prague, as it is covered by Peter=E2=80=99s PR. = I don=E2=80=99t have access to the PR/minutes right now, but I think the outcome was that an agent is only ex= pected to receive media on the nominated pair (otherwise it cannot free res= ources).

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Bernard Aboba [mailto:bernard.aboba@gmail.com]
Sent: 25 July 2017 02:29
To: Christer Holmberg <christer.holmberg@ericsson= .com>
Cc: ice@ietf.org
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC= 5245bis

=C2=A0

Christer said:=C2=A0

=C2=A0

"The whole disc= ussion began when I was given a comment that the text above should be modif= ied, to clarify that the pair used for media can change after a pair has be= en selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)"=C2=A0

=C2=A0

[BA]=C2=A0Currently,= use of the "ice2" ICE option forestalls use of aggressive nomina= tion (e.g. setting the nominated flag on more than one pair).=C2=A0 Since o= nly the selected pair can be used to send media, that would seem to rule out changing the pair used for media after a pair has been se= lected:=C2=A0

=C2=A0

=C2=A0=C2=A0 Once a candidate pair has bee=
n selected
=C2=A0=C2=A0 only that candidate pair (ref=
erred to as selected pair) is used for
=C2=A0=C2=A0 sending media.<=
/span>

=C2=A0

What about changing the pair used for media prior to= selection?=C2=A0 On this point, the text seems less clear than it could be= .=C2=A0

=C2=A0

Prior to nomination,= the specification allows the sending of media on a successful pair:=

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Once there is at leas=
t one nominated pair in the VALID LIST for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 every compo=
nent of at least one media stream and the state of the=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHECK LIST =
is Running:
=C2=A0
...
=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*=C2=
=A0 The agent MUST continue to respond to any checks it may still=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 receive for that media stream, and MUST perform triggered<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 checks if required by the processing of Section 6.3.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 The=
 agent MAY begin transmitting media for this media stream as=C2=A0

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0described in Section 11= .1.

=C2=A0

However, the specifi= cation is not clear enough about the receiving side; while it recommends th= at implementations be prepared to receive prior to nomination, it does not = require this.=C2=A0From Section 11.2:=C2=A0

=C2=A0

=C2=A0=C2=A0 ICE implementations SHOULD by=
 default be
=C2=A0=C2=A0 prepared to receive media on =
any of the candidates provided in the
=C2=A0=C2=A0 most recent candidate exchang=
e with the peer.
=C2=A0
What happens if an implementation is NOT p=
repared to receive media?
In WebRTC, an implementation cannot send w=
ithout consent, which 
suggests that perhaps an unwilling receive=
r could use consent to
influence the potential sender. =

=C2=A0
However, the specification does not even r=
eference RFC 7675,
so it is left unclear about how this is to=
 be done.
For example, a receiver might not reply to=
 a consent
request if the inability to receive is tem=
porary ("I'm not ready yet"),
but that might cause consent to time out p=
rior to nomination and
might even influence pair selection inappr=
opriately.
=C2=A0
Another choice might be to revoke consent =
(which would
invalidate the pair).=C2=A0 But that's=
 pretty drastic unless the
pair is truly unacceptable. =

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

>[BA] RFC 5245bis Section 7.1.1 continues to imply a sing= le selected pair:=C2=A0
>
>=C2=A0 =C2=A0Eventually, there will = be only a single nominated pair in the VALID
>=C2=A0 =C2=A0LIST for each component= .=C2=A0 Once the state of the CHECK LIST is set to
>=C2=A0 =C2=A0Completed, that exact p= air is selected by ICE for sending and
>=C2=A0 =C2=A0receiving media for tha= t component.
>
>Based on that text, an implementatio= n might still release resources (e.g. unused TURN candidates) post-nominati= on. Given this, the=C2=A0"ice2" ICE option doesn't address &g= t;potential interoperability issues resulting from different resource release behaviors (although it does clear indicate lack of support for agg= ressive nomination):=C2=A0

The whole discussion began when I was given a comment that the text above s= hould be modified, to clarify that the pair used for media can change after= a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)

>=C2=A0 =C2=A0NOTE: A controlling age= nt that does not support this specification
>=C2=A0 =C2=A0(i.e. it is implemented= according to RFC 5245) might nominate more
>=C2=A0 =C2=A0than one candidate pair= .=C2=A0 This was referred to as aggressive
>=C2=A0 =C2=A0nomination in RFC 5245.= =C2=A0 The usage of the 'ice2' ice option by
>=C2=A0 =C2=A0endpoints supporting th= is specifcation should prevent such
>=C2=A0 =C2=A0controlling agents from= using aggressive nomination.
>
>Christer also said:=C2=A0
>
>"Also, my understanding was tha= t endpoints supporting RFC 7675 might maintain consent on pairs currently n= ot
>used for media, in order to be able = to re-nominate in case consent for the currently nominated pair expires. Ho= wever,
>RFC 7675 does not explicitly say any= thing about that."
>
>[BA] RFC 7675 Section 5 says:=C2=A0<= /span>
>
>=C2=A0 =C2=A0Initial consent to send= traffic is obtained using ICE [RFC5245].=C2=A0 An
>=C2=A0 =C2=A0endpoint gains consent = to send on a candidate pair when the pair
>=C2=A0 =C2=A0enters the Succeeded IC= E state.
>
>Given this, an RFC 5245bis implement= ation might request consent to send to
>multiple remote peer candidates, so = as to keep them alive. However,
>there is nothing in RFC 7675 that re= quires the responder to grant
>consent for that.=C2=A0 For example,= based on the text in RFC 5245bis
>Section 7.1.1, a conforming implemen= tation might well revoke
>consent on local candidates other th= an the local candidate in the
>selected pair.

Sure - the responder is not mandated to grant consent to multiple candidate= s after nomination. But, the option to do seems to be there (unless I'v= e understood the RFC wrong), and the only reason to do so would be possible= re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do nee= d to make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer

=C2=A0

On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi
,
>[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected pai= r:=C2=A0
>
>=C2=A0 =C2=A0Eventually, there will be only a single nominated pair in = the VALID
>=C2=A0 =C2=A0LIST for each component.=C2=A0 Once the state of the CHECK= LIST is set to
>=C2=A0 =C2=A0Completed, that exact pair is selected by ICE for sending = and
>=C2=A0 =C2=A0receiving media for that component.
>
>Based on that text, an implementation might still release resources (e.= g. unused TURN candidates) post-nomination. Given this, the=C2=A0"ice2= " ICE option doesn't address >potential interoperability issues= resulting from different resource release behaviors (although it does clear indicate lack of support for aggressive nomination):=C2=A0
The whole discussion began when I was given a comment that the text above s= hould be modified, to clarify that the pair used for media can change after= a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clari= fy THAT instead :)

>=C2=A0 =C2=A0NOTE: A controlling agent that does not support this speci= fication
>=C2=A0 =C2=A0(i.e. it is implemented according to RFC 5245) might nomin= ate more
>=C2=A0 =C2=A0than one candidate pair.=C2=A0 This was referred to as agg= ressive
>=C2=A0 =C2=A0nomination in RFC 5245.=C2=A0 The usage of the 'ice2&#= 39; ice option by
>=C2=A0 =C2=A0endpoints supporting this specifcation should prevent such=
>=C2=A0 =C2=A0controlling agents from using aggressive nomination.
>
>Christer also said:=C2=A0
>
>"Also, my understanding was that endpoints supporting RFC 7675 mig= ht maintain consent on pairs currently not
>used for media, in order to be able to re-nominate in case consent for = the currently nominated pair expires. However,
>RFC 7675 does not explicitly say anything about that."
>
>[BA] RFC 7675 Section 5 says:=C2=A0
>
>=C2=A0 =C2=A0Initial consent to send traffic is obtained using ICE [RFC= 5245].=C2=A0 An
>=C2=A0 =C2=A0endpoint gains consent to send on a candidate pair when th= e pair
>=C2=A0 =C2=A0enters the Succeeded ICE state.
>
>Given this, an RFC 5245bis implementation might request consent to send= to
>multiple remote peer candidates, so as to keep them alive. However,
>there is nothing in RFC 7675 that requires the responder to grant
>consent for that.=C2=A0 For example, based on the text in RFC 5245bis >Section 7.1.1, a conforming implementation might well revoke
>consent on local candidates other than the local candidate in the
>selected pair.

Sure - the responder is not mandated to grant consent to multiple candidate= s after nomination. But, the option to do seems to be there (unless I'v= e understood the RFC wrong), and the only reason to do so would be possible= re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do nee= d to make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer





On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
Hi Bernard,
=C2=A0
Support of 5245bis is also negotiated, using the =E2=80=9Cice2=E2=80=9D ICE= option.
=C2=A0
Also, my understanding was that endpoints supporting RFC 7675 might maintai= n consent on pairs currently not used for media, in order to be able to re-= nominate in case consent for the currently nominated pair expires. However,= RFC 7675 does not explicitly say anything about that.
=C2=A0
Regards,
=C2=A0
Christer
=C2=A0
From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 20 July 2017 14:22
To: ice@ietf.org
Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis =C2=A0
During the ICE WG meeting today, there was discussion of whether RFC5245bis= should indicate that it is possible to re-nominate pairs (proposed by Pete= r), or whether it is possible to switch from one interface to another (Cull= en).=C2=A0 While these capabilities are desirable, attempting to add them to RFC 5245bis without negotiation has t= he potential to break interoperability with existing RFC 5245 implementatio= ns.
=C2=A0
In my experience, this is an area where RFC 5245 implementations have very = different interpretations. For example, some implementations (e.g. ones tha= t did not support aggressive) discard non-selected candidate pairs after no= mination. These implementations (e.g. particularly ones included in previous product releases) cannot be a= ssumed to change their behavior after RFC 5245bis is published.=C2=A0 This = raises the possibility that that interoperability could be impacted.=C2=A0<= br> =C2=A0
Since in practice the desired candidate pair switching capabilities are mos= t likely to be supported in WebRTC implementations supporting Trickle ICE, = my recommendation is to think of candidate pair switching as a Trickle ICE = capability. =C2=A0 Since Trickle-ICE support is negotiated, clarifications relating to candidate-pair switching= can be linked to that negotiation. =C2=A0
=C2=A0
This provides a potential way forward that bypasses potential interoperabil= ity issues.=C2=A0 For example, if text on candidate-pair switching is to be= added to (either to RFC 5245bis or Trickle-ICE) then the text could say th= at support for these behaviors can only be assumed if they are explicitly negotiated. The Trickle-ICE document cou= ld then create normative requirements for support of the new behaviors by s= tating that support for them is mandatory when supporting full-Trickle.=C2= =A0
=C2=A0
=C2=A0

=C2=A0

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice

--001a1141b266461aaf0557fb047f-- From nobody Wed Aug 30 11:24:00 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220A6132944 for ; Wed, 30 Aug 2017 11:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 l_oy4D7OPfC0 for ; Wed, 30 Aug 2017 11:23:44 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 D33ED132710 for ; Wed, 30 Aug 2017 11:23:43 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t188so35267557ywb.1 for ; Wed, 30 Aug 2017 11:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JJ/JV8NtaO1WnBcz/CITcxhmEAKB5LKFPU7UyRPIRTg=; b=hSeiV40rVzVFVkp5ergBvjH0di33Doh/I1SmQPcKl9Fysy4yIwLOjXGEV14ksZfS1o Z/Qs/qYpIHu6cGB5gN7hy055UwnOE8olGUf6PlFDAJvNCGGPBl1lLxfIecT0bRzz+gij 0LkPHHcgX+Uw4oVCo8Tcd3d9EtoYaqJghOFeIK58CMIPbZAzwcLb+YJUkyoOXRPQE55H fBiIGT9xbJrGGLcwN+u6JDlN74Pj7VwJF85sM+UQUPPpzXSVQCnBzZhhAG++YnPu6RBQ gkT871P4YpoaiydnB1adQLanZn50pUFvFASmM2Yp4Fq7gDbHRHkwwfmOIxggGEryA3HD PUWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JJ/JV8NtaO1WnBcz/CITcxhmEAKB5LKFPU7UyRPIRTg=; b=GCBDEZWq9tBK6/jO6mqRATgJp5bD9gdD3FJOIrwU8SAHSrcMBUETG8pN1u9kx/3vQa puJEuvWkFs5FS+qObhXIYAcEu0BrTHxvStLw+mIN4bGyoDQNjKpEtZ1eU9rXghIZbwE7 zk1h5Q5bLy5mFqOP+rskGwnKRhNzfsYzHTfnepBuIaa4OLJW0/13cWShI5Ri5/zMK7M/ BVx/0vadrPrYvh3J90YjeKKs1O5QC38/96adX+5snsEvLoiYB0ed5V5ofW9EtX11D9s7 not1fOU/t0i+1dv270xsKnC2WpzShDM2d6LKcRL3BrWEkGy8nCbYh49x9mH1zgUFt/lj r2kg== X-Gm-Message-State: AHYfb5iXfafx0oYquR6VBfk8A0CCFJaKRhGj1xV2oR/pPxFnNAGKmDgd nr7Ccl7RgI2jsW+X+8k= X-Received: by 10.13.219.70 with SMTP id d67mr2179301ywe.212.1504117422971; Wed, 30 Aug 2017 11:23:42 -0700 (PDT) Received: from [10.46.243.58] (mobile-166-172-187-56.mycingular.net. [166.172.187.56]) by smtp.gmail.com with ESMTPSA id z14sm2282049ywd.103.2017.08.30.11.23.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 11:23:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-EC08551B-3777-4414-9ECF-28A4CB2EA1A1 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 30 Aug 2017 14:23:41 -0400 Cc: Christer Holmberg , "ice@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> To: Peter Thatcher Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 18:23:46 -0000 --Apple-Mail-EC08551B-3777-4414-9ECF-28A4CB2EA1A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Aug 30, 2017, at 12:28 PM, Peter Thatcher wrote: >=20 >> On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher wro= te: >> As far as "just enough" so that it isn't a hindrance: that's why I wanted= to say that agents *may* switch. It allows a renomination in the future. S= aying they MUST NOT is a hindrance. I would be fine if the *may* requires n= egotiation. That's what https://www.ietf.org/archive/id/draft-thatcher-ice-= renomination-01.txt does: it negotiates "renomination". And that's what Chr= ome's implementation of WebRTC does.=20 [BA] It seems like the document would at least need to talk about consent to= include a "may". As it is, negotiating "ice2" only means that you're talkin= g to a slightly refurbished RFC 5245 implementation. That's like the differe= nce between a new car with driver assist (a modern WebRTC ICE implementation= with Trickle) and an Edsel that's been waxed and given an oil change.=20= --Apple-Mail-EC08551B-3777-4414-9ECF-28A4CB2EA1A1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Aug 30, 2017, at 12:28 P= M, Peter Thatcher <pthatcher@goog= le.com> wrote:

On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher <= pthatcher@google.com> wrote:<= br>
As far as "just enou= gh" so that it isn't a hindrance: that's why I wanted to say that agents *ma= y* switch.  It allows a renomination in the future.  Saying they M= UST NOT is a hindrance.  I would be fine if the *may* requires negotiat= ion.  That's w= hat h= ttps://www.ietf.org/archive/id/draft-thatcher-ice-renomination-01.txt does: it negoti= ates "renomination".  And that's what Chrome's implementation of WebRTC= does. 

[BA] It se= ems like the document would at least need to talk about consent to include a= "may". As it is, negotiating "ice2" only means that you're talking to a sli= ghtly refurbished RFC 5245 implementation. That's like the difference betwee= n a new car with driver assist (a modern WebRTC ICE implementation with Tric= kle) and an Edsel that's been waxed and given an oil change. 
= --Apple-Mail-EC08551B-3777-4414-9ECF-28A4CB2EA1A1-- From nobody Wed Aug 30 13:55:52 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE491321F1 for ; Wed, 30 Aug 2017 13:55:51 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 3F72UKO7agt7 for ; Wed, 30 Aug 2017 13:55:49 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 F14AC1321D8 for ; Wed, 30 Aug 2017 13:55:48 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id l65so33208816qkc.0 for ; Wed, 30 Aug 2017 13:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ij1NjzMMwBB7BQQ02bUUir4o7K0fb7DYbB0g5m4lg8=; b=Hr0WurddoT6FU1WDpqigHJzRfJuYD5GAWXJlILBqnAT2IBk633E6422/Ywj2W8k0vj FCoR8eFn1vLGe3b2wYALSIRvvwAW6UJUH81HoSwxEek5MqpctDhMEIDohGaI2EJDIjKB 6xfKOHpQFKAo/ap4i+R1VbtYoBmGz+AHPg5+J4TAxNWmKPnr9PVsZzx6thRu5CWY5srO irOTbBlBLkY+Ti0igT44tKXQ0S7OZZGD4dgo/e8CmuDyVO1A+MMCyACyvtFSSgYm8lWG kOtr2oGGIxyPodC1PpYPneYhloSx153X1uTA4heZD8vK6aPRcgq8ST2U79hIVi8i3J4x 12ow== 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=5ij1NjzMMwBB7BQQ02bUUir4o7K0fb7DYbB0g5m4lg8=; b=sQeANhkYgYYaNT1DBtJl4Pet8VfJr95iDHDC2wLVgetZCZ2EsXPpAPusCQEPZTm3rD JVK4JcETcIyeeyB31Ta6pqAZgprENh+ty44UPlxCKLC4UVRbELHw6DTpC5ufJLwM8FLU MUNWOQj0U/3dLVR5iLBZahfwcfIO5vBvv7wmmB8hjp6BQGnwePzw1GjPLm458rZuftEr E8Tw4A/mO8EwbxgmMSJHTa9qwX+v/Q0ZezKgHAk1BET6b75oDUbIS0MKif7PPrUwkFQP wAxtSzyiY6ULmc4v7Xk1nITvwm8uiXC9UaYXrKBoxIipWq0vQwGN6ysyRGdHCxUTAuJf YZZg== X-Gm-Message-State: AHPjjUhL8qYrGiQbC1KlI6lsu0ikVI23B3xadUO2ICrfaQE7EXdD+94W tIy4JPdtc5v6yfRsQGfPiPLh4Cn/bfj6 X-Google-Smtp-Source: ADKCNb4Yu+EAvcWiIIvmHPnslCs2aAykRwh+iAv4vv6y+7uOmw7pPmqVVBt+xO6rO5l4z0jJMJYyWmmW0/yjy8RJDSU= X-Received: by 10.55.127.68 with SMTP id a65mr844818qkd.94.1504126547906; Wed, 30 Aug 2017 13:55:47 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> In-Reply-To: <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> From: Peter Thatcher Date: Wed, 30 Aug 2017 20:55:37 +0000 Message-ID: To: Bernard Aboba Cc: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c06220896c6310557fec021" Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:55:51 -0000 --94eb2c06220896c6310557fec021 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba wrote: > On Aug 30, 2017, at 12:28 PM, Peter Thatcher wrote: > > On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher > wrote: > > As far as "just enough" so that it isn't a hindrance: that's why I wanted >> to say that agents *may* switch. It allows a renomination in the future. >> Saying they MUST NOT is a hindrance. I would be fine if the *may* requires >> negotiation. That's what >> https://www.ietf.org/archive/id/draft-thatcher-ice-renomination-01.txt does: >> it negotiates "renomination". And that's what Chrome's implementation of >> WebRTC does. >> > > [BA] It seems like the document would at least need to talk about consent > to include a "may". As it is, negotiating "ice2" only means that you're > talking to a slightly refurbished RFC 5245 implementation. That's like the > difference between a new car with driver assist (a modern WebRTC ICE > implementation with Trickle) and an Edsel that's been waxed and given an > oil change. > You always need to have consent to use a candidate pair. I guess the question you're asking is how recent does the consent need to be. But I'm not sure we need to standardize that. If an implementation chooses to be too aggressive about switching, it will send a path that doesn't work. In your analogy, you're worried about the driver assist doing something dumb and crashing into the Edsel. Well, don't ship a car that crashes. Do we need to standardize "don't switch to a candidate pair that doesn't work" (AKA don't crash)? --94eb2c06220896c6310557fec021 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Aug 30, 2017 at 11:23 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:
On Aug 30, 2017, at 12:2= 8 PM, Peter Thatcher <pthatcher@google.com> wrote:
On Wed,= Aug 30, 2017 at 9:26 AM Peter Thatcher <pthatcher@google.com> wrote:
As far as= "just enough" so that it isn't a hindrance: that's why I= wanted to say that agents *may* switch.=C2=A0 It allows a renomination in = the future.=C2=A0 Saying they MUST NOT is a hindrance.=C2=A0 I would be fin= e if the *may* requires negotiation.=C2=A0 That's what=C2=A0https://www.ietf.org/archive= /id/draft-thatcher-ice-renomination-01.txt=C2=A0does: it negotiates "renomination".= =C2=A0 And that's what Chrome's implementation of WebRTC does.=C2= =A0

[BA] It seems like= the document would at least need to talk about consent to include a "= may". As it is, negotiating "ice2" only means that you'r= e talking to a slightly refurbished RFC 5245 implementation. That's lik= e the difference between a new car with driver assist (a modern WebRTC ICE = implementation with Trickle) and an Edsel that's been waxed and given a= n oil change.=C2=A0

You always = need to have consent to use a candidate pair.=C2=A0 I guess the question yo= u're asking is how recent does the consent need to be.=C2=A0 But I'= m not sure we need to standardize that.=C2=A0 If an implementation chooses = to be too aggressive about switching, it will send a path that doesn't = work.=C2=A0 In your analogy, you're worried about the driver assist doi= ng something dumb and crashing into the Edsel.=C2=A0 Well, don't ship a= car that crashes.=C2=A0 Do we need to standardize "don't switch t= o a candidate pair that doesn't work" (AKA don't crash)?=C2=A0=
--94eb2c06220896c6310557fec021-- From nobody Wed Aug 30 14:30:28 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E217313247A for ; Wed, 30 Aug 2017 14:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 9FJAX5T1IdtY for ; Wed, 30 Aug 2017 14:30:24 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 83293120721 for ; Wed, 30 Aug 2017 14:30:24 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id s187so37369957ywf.2 for ; Wed, 30 Aug 2017 14:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=etCqFygXqlzJ0Fs2l2cUAtbz8Ue+tnT3jagGMJC4HzM=; b=BWx4urucGKChL1dald0CWlITZK9Bs3sNSvsER/UKIGxbi/wj8cYpKlxEl1NfIe/qlA jSorTPhoICcOryH4GtiGrsdWrKkOMBi+8KKGcVQ2vuZNVrRYuMOYv3wktX8EQAvKCqot sQ19d72ty2kRNZ6WgyeD9auHi2vwQqrsKxW4RlAEbgZFsQ0Nq0WkCwMu5P6JWeM6diYW TTAMEnI4EUVDk9tuwsBqGDJtLouLWydJwT2Px9yPMswsxfU2G+h5ybGcpHGANcESLCaW CygkPakgORw5iT5mu/oFkZdeGM9yr9qbtUHbkPpw1YPSobgyuT1w9orh31IaofzpOVbX 5NPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=etCqFygXqlzJ0Fs2l2cUAtbz8Ue+tnT3jagGMJC4HzM=; b=j3+HWPM13uUry8IB79aX+jRntJ37ZNa00KSRICKLoNiMhAf76s20rbpsd3Fe+0ya42 Pr7njKmtBWkFg/Dzdfp+I1jfmXae0a9Sl58iyV0X9CZbiYTjnMR4O29kR5D6KU+p1V+J lYcrg9RY0xjl9p7KbV4ULSxt0pmsuxVgOP8vYmtp5rqERfoPQcrbtZWcOpdLL8K+T+Vt mpTAfa77mkNvurjA9OMm+A6AkQlkKnL/irzSzrPDQ6jnSPhJHgIR01AiEvD1ul+lKmgo 4cZvA0X+u5A/4Q2Wv8jPq3ZhgTCMr0AhY8UNnc3LyyLZkOzoFtZBCaifIOTnorD9pa/0 mniw== X-Gm-Message-State: AHYfb5g9GkkOWfL5aE0HLRgnuxObH4UFVlLk/TKL5sQD1bTOoJFfuWMG 0LSGxX3vaLfU9cbsuhQ= X-Received: by 10.129.109.11 with SMTP id i11mr2611716ywc.449.1504128623535; Wed, 30 Aug 2017 14:30:23 -0700 (PDT) Received: from [10.46.243.58] (mobile-166-172-187-56.mycingular.net. [166.172.187.56]) by smtp.gmail.com with ESMTPSA id o9sm2343060ywb.110.2017.08.30.14.30.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 14:30:23 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-081EE8BE-99D0-412E-BE0D-C155E45F3EB0 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 30 Aug 2017 17:30:22 -0400 Cc: Christer Holmberg , "ice@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <90DEFADE-5113-488A-9C0F-2073681D94B1@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> To: Peter Thatcher Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 21:30:27 -0000 --Apple-Mail-081EE8BE-99D0-412E-BE0D-C155E45F3EB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The problem as I understand it is that RFC 5245bis is intended to be usable b= y non-WebRTC implementations, so it cannot mandate (or even mention??) conse= nt.=20 If this seems silly to you (it does to me) maybe it would make more sense to= assume RFC 5245bis is for use in a modern ICE implementation usable with We= bRTC, because after all, isn't that what ICE developers should be working on= ??? That would make it possible for consent to be referenced and then the idea o= f keeping consent for non-nominated pairs after nomination could be introduc= ed. Just a thought. > On Aug 30, 2017, at 4:55 PM, Peter Thatcher wrote: >=20 >=20 >=20 >> On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba w= rote: >>> On Aug 30, 2017, at 12:28 PM, Peter Thatcher wrot= e: >>=20 >>>> On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher w= rote: >>=20 >>>> As far as "just enough" so that it isn't a hindrance: that's why I want= ed to say that agents *may* switch. It allows a renomination in the future.= Saying they MUST NOT is a hindrance. I would be fine if the *may* require= s negotiation. That's what https://www.ietf.org/archive/id/draft-thatcher-i= ce-renomination-01.txt does: it negotiates "renomination". And that's what C= hrome's implementation of WebRTC does.=20 >>=20 >> [BA] It seems like the document would at least need to talk about consent= to include a "may". As it is, negotiating "ice2" only means that you're tal= king to a slightly refurbished RFC 5245 implementation. That's like the diff= erence between a new car with driver assist (a modern WebRTC ICE implementat= ion with Trickle) and an Edsel that's been waxed and given an oil change.=20= >=20 > You always need to have consent to use a candidate pair. I guess the ques= tion you're asking is how recent does the consent need to be. But I'm not s= ure we need to standardize that. If an implementation chooses to be too agg= ressive about switching, it will send a path that doesn't work. In your ana= logy, you're worried about the driver assist doing something dumb and crashi= ng into the Edsel. Well, don't ship a car that crashes. Do we need to stan= dardize "don't switch to a candidate pair that doesn't work" (AKA don't cras= h)?=20 --Apple-Mail-081EE8BE-99D0-412E-BE0D-C155E45F3EB0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The problem as I understand= it is that RFC 5245bis is intended to be usable by non-WebRTC implementatio= ns, so it cannot mandate (or even mention??) consent. 

If this seems silly to you (it does to me) maybe it would make more= sense to assume RFC 5245bis is for use in a modern ICE implementation usabl= e with WebRTC, because after all, isn't that what ICE developers should be w= orking on???

That would make it possible for consen= t to be referenced and then the idea of keeping consent for non-nominated pa= irs after nomination could be introduced.

Just a th= ought.

On Aug 30, 2017, at 4:55 PM, Peter Thatcher <pthatcher@google.com> wrote:

=


On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba= <bernard.aboba@gmail.com&= gt; wrote:
<= /div>

[BA] It seems like the document would at least ne= ed to talk about consent to include a "may". As it is, negotiating "ice2" on= ly means that you're talking to a slightly refurbished RFC 5245 implementati= on. That's like the difference between a new car with driver assist (a moder= n WebRTC ICE implementation with Trickle) and an Edsel that's been waxed and= given an oil change. 

You a= lways need to have consent to use a candidate pair.  I guess the questi= on you're asking is how recent does the consent need to be.  But I'm no= t sure we need to standardize that.  If an implementation chooses to be= too aggressive about switching, it will send a path that doesn't work. = ; In your analogy, you're worried about the driver assist doing something du= mb and crashing into the Edsel.  Well, don't ship a car that crashes.&n= bsp; Do we need to standardize "don't switch to a candidate pair that doesn'= t work" (AKA don't crash)? 
= --Apple-Mail-081EE8BE-99D0-412E-BE0D-C155E45F3EB0-- From nobody Wed Aug 30 23:53:21 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85D913201E for ; Wed, 30 Aug 2017 23:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 j9QwsGPhF1JQ for ; Wed, 30 Aug 2017 23:53:16 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E2CAA1321EC for ; Wed, 30 Aug 2017 23:53:15 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-05-59a7b25adde7 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 94.B0.21299.A52B7A95; Thu, 31 Aug 2017 08:53:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 08:53:13 +0200 From: Christer Holmberg To: Bernard Aboba , Peter Thatcher CC: "ice@ietf.org" Thread-Topic: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL Thread-Index: AdMGx5vayPULxOekRUuarjHzPdbbFQayu7YAAAG4ewAAAKDJgAAAEW8AAAQIgIAABU5kgAABNrAAABoZ1YA= Date: Thu, 31 Aug 2017 06:53:12 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <90DEFADE-5113-488A-9C0F-2073681D94B1@gmail.com> In-Reply-To: <90DEFADE-5113-488A-9C0F-2073681D94B1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D5CD8D5A20C78christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2K7sW7UpuWRBh+O8Fts2Pef2eLbhVqL a8tfszowe+ycdZfdY8GmUo8lS34yBTBHcdmkpOZklqUW6dslcGXs+2xR0GVXcWzhZ/YGxrkm XYycHBICJhKP5x5m6WLk4hASOMIocf7eQXYIZwmjxM4Fv5i7GDk42AQsJLr/aYM0iAiESLyb fogVJMwsoCjxcq8aSFhYIFLi4/yHYGERgSiJt5syIaqTJD5vm8cCYrMIqEqceNgFNpBXwFqi o9sSYtE0Fonpe8+ygMQ5BWwljl5NAClnFBCT+H5qDROIzSwgLnHryXwmiIsFJJbsOc8MYYtK vHz8D2yrqICexLv9nhBhRYmdZ9uZIVoTJJa3zwezeQUEJU7OfMIygVF0FpKps5CUzUJSBhE3 kHh/DiLOLKAtsWzhayhbX2Ljl7OMELa1xIdj+1DULGDkWMUoWpxanJSbbmSsl1qUmVxcnJ+n l5dasokRGI0Ht/xW3cF4+Y3jIUYBDkYlHt5Vi5ZHCrEmlhVX5h5ilOBgVhLh3bQOKMSbklhZ lVqUH19UmpNafIhRmoNFSZzXcd+FCCGB9MSS1OzU1ILUIpgsEwenVANjppcT05rglgz3DP33 q9df3PC4W7ogh3Uro9sk6T1GU98FbXE6+jyj+z/TpKktSdYS/3Wf/Gd8nvH6Q81ts76Q53o3 Px7S5yuwfL/yl1b5Yl2HFEH28DYtWfuF2406d24o19ITYpl043/1ZqWnPpk3PHONpr+b5rSy psDnfEfme0f7zXu3vZ2txFKckWioxVxUnAgApRDmQcICAAA= Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 06:53:18 -0000 --_000_D5CD8D5A20C78christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >The problem as I understand it is that RFC 5245bis is intended to be usabl= e by non-WebRTC implementations, so it cannot mandate (or even mention??) c= onsent. Correct. However, one option would be to require consent in order to do switching. T= hen, before the switching takes place, an endpoint would have to get consen= t. And, if the remote peer has released the candidate the consent would fai= l, and the switch can=92t be done. >If this seems silly to you (it does to me) maybe it would make more sense = to assume RFC 5245bis is for use in a modern ICE implementation usable with= WebRTC, because after all, isn't that what ICE developers should be workin= g on??? I think we also want =93legacy=94 implementations, that previously used non= -ICE mechanisms, to migrate to ICE. Regards, Christer On Aug 30, 2017, at 4:55 PM, Peter Thatcher > wrote: On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba > wrote: On Aug 30, 2017, at 12:28 PM, Peter Thatcher > wrote: On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher > wrote: As far as "just enough" so that it isn't a hindrance: that's why I wanted t= o say that agents *may* switch. It allows a renomination in the future. S= aying they MUST NOT is a hindrance. I would be fine if the *may* requires = negotiation. That's what https://www.ietf.org/archive/id/draft-thatcher-ic= e-renomination-01.txt does: it negotiates "renomination". And that's what = Chrome's implementation of WebRTC does. [BA] It seems like the document would at least need to talk about consent t= o include a "may". As it is, negotiating "ice2" only means that you're talk= ing to a slightly refurbished RFC 5245 implementation. That's like the diff= erence between a new car with driver assist (a modern WebRTC ICE implementa= tion with Trickle) and an Edsel that's been waxed and given an oil change. You always need to have consent to use a candidate pair. I guess the quest= ion you're asking is how recent does the consent need to be. But I'm not s= ure we need to standardize that. If an implementation chooses to be too ag= gressive about switching, it will send a path that doesn't work. In your a= nalogy, you're worried about the driver assist doing something dumb and cra= shing into the Edsel. Well, don't ship a car that crashes. Do we need to = standardize "don't switch to a candidate pair that doesn't work" (AKA don't= crash)? --_000_D5CD8D5A20C78christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <08644DCDAF350342BD5531C9136EDC0A@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>The problem as I understand it is that RFC 5245bis is intended to = be usable by non-WebRTC implementations, so it cannot mandate (or even ment= ion??) consent. 

Correct.

However, one option would be to require consent in order to do switchi= ng. Then, before the switching takes place, an endpoint would have to get c= onsent. And, if the remote peer has released the candidate the consent woul= d fail, and the switch can=92t be done.

>If this seems silly to you (it does to me) maybe it would make mor= e sense to assume RFC 5245bis is for use in a modern ICE implementation usa= ble with WebRTC, because after all, isn't that what ICE developers should b= e working on???

I think we also want =93legacy=94 implementations, that previously use= d non-ICE mechanisms, to migrate to ICE.

Regards,

Christer



On Aug 30, 2017, at 4:55 PM, Peter Thatcher <pthatcher@google.com> wrote:



On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:<= br>
On Aug 30, 2017, at 12:28 PM, Peter Thatcher <pthatcher@google.com> wrote:
On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher <pthatcher@google.com= > wrote:
As far as "just enough" so that it isn't a hindr= ance: that's why I wanted to say that agents *may* switch.  It allows = a renomination in the future.  Saying they MUST NOT is a hindrance.&nb= sp; I would be fine if the *may* requires negotiation.  That's what = https://www.ietf.org/archive/id/draft-thatcher-ice-renomination-01.txt<= span style=3D"background-color:rgba(255,255,255,0)"> does: it negotiates "renomination".  And that's what Chrome's imp= lementation of WebRTC does. 

[BA] It seems like the document would at least need to talk about cons= ent to include a "may". As it is, negotiating "ice2" on= ly means that you're talking to a slightly refurbished RFC 5245 implementat= ion. That's like the difference between a new car with driver assist (a modern WebRTC ICE implementation with Trickle) and an Eds= el that's been waxed and given an oil change. 

You always need to have consent to use a candidate pair.  I guess= the question you're asking is how recent does the consent need to be. = ; But I'm not sure we need to standardize that.  If an implementation = chooses to be too aggressive about switching, it will send a path that doesn't work.  In your analogy, you're worried = about the driver assist doing something dumb and crashing into the Edsel.&n= bsp; Well, don't ship a car that crashes.  Do we need to standardize &= quot;don't switch to a candidate pair that doesn't work" (AKA don't crash)? 
 --_000_D5CD8D5A20C78christerholmbergericssoncom_-- From nobody Thu Aug 31 04:37:35 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E039A1321A5 for ; Thu, 31 Aug 2017 04:37:32 -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 kvA4bfiMDiOx for ; Thu, 31 Aug 2017 04:37:29 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 BC2DE132D56 for ; Thu, 31 Aug 2017 04:37:28 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 105so1104508uad.3 for ; Thu, 31 Aug 2017 04:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=83rPBYW3OhMbZEHV9bjJnuzGfAM0KxGoQ8IEZVAQlIk=; b=Bt2iOcnrYkusiRxg4YFfTNICqlmr2f5hOtdzsGGMIdPFRfPqlkJvmo7mOBmE5+k0mq mpxa58V3Ej5O0vvcTy/TRk2sZ0Khp2BiLcNY52gY5WgYlXNQXkFEGP2AlhqxEWMVC37b yCQlXwS0j7F7wnZz1+z9O/F7wkrGaktCq0w+f7jN3OLIsYGMZMWYQ/Ipl57AK7G4Oxha /KPYvMf7vk1c39c2wwzAso0CkMqh/cl3i9+vLdud3lVzZtkj1Qu2Qq2H5awfIiKIaaYX uE14AHtRk8xHqMOiKR7hX7jhAseAaF8QR7zBJ206+4C3qCZRoGvnk3+xEMf8n9TbDFV2 8VFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=83rPBYW3OhMbZEHV9bjJnuzGfAM0KxGoQ8IEZVAQlIk=; b=GstxXa8GzQTzmUJbYSN8gRei5G8mOD49/OZqY5HmTGekylP0bmUu3gr+HRFp2b4XKN p1/40ClDwMRsiD2A6gkTm5idL+1BL4nxG0ySVM3OkaGGezKQOyf7/Bsd2dRc6orF1DtV B85jellMhmj6wd07am1hoyVauBBG11ZBS5ZI+VE5/Da6IAMk4tZsKRwzqt9u7gwFdpT4 QucM9h75WycUKCHqKc6QLWxgQTw+iuY5CCN9BnG1X38CpLfX/5TSjh5iOGmeoPsY8miw ODUvUyJP+qSgrLqBe8iU8xrQXWveTjDbErXGjADnDMsZfJDyQEZ3wJc9bcCHcK1pPIJ2 Qkig== X-Gm-Message-State: AHYfb5iOTaDshjsK50PHy8jrcsu6dumHgUAQncem6aCNDZj1cDgG92mN KOUe1zrJpKhpLxCJ5MxD9KI0IhNPBA== X-Google-Smtp-Source: ADKCNb4c+96TGSU2wnJqQf+m6P0SkuX+qDyYAEoYifMddgJ4127u4DCaZ6lG+IdVOB01B1GKH7d6CEtztWl34nYG7RY= X-Received: by 10.176.64.234 with SMTP id i97mr2682656uad.52.1504179447541; Thu, 31 Aug 2017 04:37:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.23 with HTTP; Thu, 31 Aug 2017 04:37:07 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <90DEFADE-5113-488A-9C0F-2073681D94B1@gmail.com> From: Bernard Aboba Date: Thu, 31 Aug 2017 07:37:07 -0400 Message-ID: To: Christer Holmberg Cc: Peter Thatcher , "ice@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c123566a6495105580b11da" Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:37:33 -0000 --94eb2c123566a6495105580b11da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Christer said: "However, one option would be to require consent in order to do switching. Then, before the switching takes place, an endpoint would have to get consent. And, if the remote peer has released the candidate the consent would fail, and the switch can=E2=80=99t be done." [BA] That makes sense. Question: Is the list of post-nomination validated pairs solely chosen by the controlling side maintaining consent on them? Or can the controlled side indicate an interest in retaining a validated pair by maintaining consent on it as well? If so, would this imply that controlling and controlled sides could send on different pairs? On Thu, Aug 31, 2017 at 2:53 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >The problem as I understand it is that RFC 5245bis is intended to be > usable by non-WebRTC implementations, so it cannot mandate (or even > mention??) consent. > > Correct. > > However, one option would be to require consent in order to do switching. > Then, before the switching takes place, an endpoint would have to get > consent. And, if the remote peer has released the candidate the consent > would fail, and the switch can=E2=80=99t be done. > > >If this seems silly to you (it does to me) maybe it would make more sens= e > to assume RFC 5245bis is for use in a modern ICE implementation usable wi= th > WebRTC, because after all, isn't that what ICE developers should be worki= ng > on??? > > I think we also want =E2=80=9Clegacy=E2=80=9D implementations, that previ= ously used > non-ICE mechanisms, to migrate to ICE. > > Regards, > > Christer > > > > On Aug 30, 2017, at 4:55 PM, Peter Thatcher wrote: > > > > On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba > wrote: > >> On Aug 30, 2017, at 12:28 PM, Peter Thatcher >> wrote: >> >> On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher >> wrote: >> >> As far as "just enough" so that it isn't a hindrance: that's why I wante= d >>> to say that agents *may* switch. It allows a renomination in the futur= e. >>> Saying they MUST NOT is a hindrance. I would be fine if the *may* requ= ires >>> negotiation. That's what https://www.ietf.org/ >>> archive/id/draft-thatcher-ice-renomination-01.txt does: it negotiates >>> "renomination". And that's what Chrome's implementation of WebRTC does= . >>> >> >> [BA] It seems like the document would at least need to talk about consen= t >> to include a "may". As it is, negotiating "ice2" only means that you're >> talking to a slightly refurbished RFC 5245 implementation. That's like t= he >> difference between a new car with driver assist (a modern WebRTC ICE >> implementation with Trickle) and an Edsel that's been waxed and given an >> oil change. >> > > You always need to have consent to use a candidate pair. I guess the > question you're asking is how recent does the consent need to be. But I'= m > not sure we need to standardize that. If an implementation chooses to be > too aggressive about switching, it will send a path that doesn't work. I= n > your analogy, you're worried about the driver assist doing something dumb > and crashing into the Edsel. Well, don't ship a car that crashes. Do we > need to standardize "don't switch to a candidate pair that doesn't work" > (AKA don't crash)? > > --94eb2c123566a6495105580b11da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Christer said:=C2=A0

"However= , one option would be to require consent in order to do switching. Then, be= fore the switching takes place, an endpoint would have to get consent. And,= if the remote peer has released the candidate the consent would fail, and = the switch can=E2=80=99t be done."

[BA] That makes sense.=C2=A0

Question: =C2=A0Is the list of post-nomination validated pairs= solely chosen by the controlling side maintaining consent on them?=C2=A0 O= r can the controlled side indicate an interest in retaining a validated pai= r by maintaining consent on it as well? If so, would this imply that contro= lling and controlled sides could send on different pairs?=C2=A0



On Thu, Aug 31, 2017 at 2:53 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

>The problem as I understand it is that RFC 5245bis is intended to = be usable by non-WebRTC implementations, so it cannot mandate (or even ment= ion??) consent.=C2=A0

Correct.

However, one option would be to require consent in order to do switchi= ng. Then, before the switching takes place, an endpoint would have to get c= onsent. And, if the remote peer has released the candidate the consent woul= d fail, and the switch can=E2=80=99t be done.

>If this seems silly to you (it does to me) maybe it would make mor= e sense to assume RFC 5245bis is for use in a modern ICE implementation usa= ble with WebRTC, because after all, isn't that what ICE developers shou= ld be working on???

I think we also want =E2=80=9Clegacy=E2=80=9D implementations, = that previously used non-ICE mechanisms, to migrate to ICE.

Regards,

Christer



On Aug 30, 2017, at 4:55 PM, Peter Thatcher <pthatcher@google.com> wrote:



On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba <bernard.aboba@gmail.c= om> wrote:
On Aug 30, 2017, at 12:28 PM, Peter Thatcher <pthatcher@google.com> wrote:
On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher <pthatcher@google.com= > wrote:
As far as "just enough" so that it isn't a h= indrance: that's why I wanted to say that agents *may* switch.=C2=A0 It= allows a renomination in the future.=C2=A0 Saying they MUST NOT is a hindr= ance.=C2=A0 I would be fine if the *may* requires negotiation.=C2=A0 That's what=C2=A0<= /span>https://www.ietf.org/archive/id/draft-thatcher-ice-renominati= on-01.txt=C2=A0doe= s: it negotiates "renomination".=C2=A0 And that's what Chrome&#= 39;s implementation of WebRTC does.=C2=A0

[BA] It seems like the document would at least need to talk about cons= ent to include a "may". As it is, negotiating "ice2" on= ly means that you're talking to a slightly refurbished RFC 5245 impleme= ntation. That's like the difference between a new car with driver assist (a modern WebRTC ICE implementation with Trickle) and an Eds= el that's been waxed and given an oil change.=C2=A0

You always need to have consent to use a candidate pair.=C2=A0 I guess= the question you're asking is how recent does the consent need to be.= =C2=A0 But I'm not sure we need to standardize that.=C2=A0 If an implem= entation chooses to be too aggressive about switching, it will send a path that doesn't work.=C2=A0 In your analogy, you're = worried about the driver assist doing something dumb and crashing into the = Edsel.=C2=A0 Well, don't ship a car that crashes.=C2=A0 Do we need to s= tandardize "don't switch to a candidate pair that doesn't work= " (AKA don't crash)?=C2=A0

--94eb2c123566a6495105580b11da-- From nobody Thu Aug 31 04:49:06 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4CC132D56 for ; Thu, 31 Aug 2017 04:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 lbvsewHfWkaE for ; Thu, 31 Aug 2017 04:49:02 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 3005F1321A5 for ; Thu, 31 Aug 2017 04:49:01 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-07-59a7f7ab0d67 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.29.22436.BA7F7A95; Thu, 31 Aug 2017 13:49:00 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 13:48:59 +0200 From: Christer Holmberg To: Bernard Aboba CC: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL Thread-Index: AdMGx5vayPULxOekRUuarjHzPdbbFQayu7YAAAG4ewAAAKDJgAAAEW8AAAQIgIAABU5kgAABNrAAABoZ1YAAA3i0gAAG26iA Date: Thu, 31 Aug 2017 11:48:59 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <90DEFADE-5113-488A-9C0F-2073681D94B1@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D5CDD2DB20D69christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7n+6a78sjDY784LLYsO8/s8W3C7UW 15a/ZnVg9tg56y67x4JNpR5LlvxkCmCO4rJJSc3JLEst0rdL4MrYtWEWY8GFuIpJrbPZGhj/ +XcxcnJICJhIrPk2j6WLkYtDSOAIo8TOzktsEM4SRok5F2+wdjFycLAJWEh0/9MGaRAR0Jbo +7aPCcRmFvCQ+LKlkR3EFhaIlPg4/yFYuYhAlMTbTZkQ5XkSPfvOMoLYLAKqEjcezWMGsXkF rCVWnPrDDLGqn1Xi+P1zLCAJToFAifaFO9hAbEYBMYnvp9ZA7RKXuPVkPhPE0QISS/acZ4aw RSVePv4HtldUQE/i3X5PEFNCQFFieb8cRGeCxLyueawQawUlTs58wjKBUXQWkqGzkJTNQlIG ETeQeH9uPjOErS2xbOFrKFtfYuOXs4wQNtA3d/6wIqtZwMixilG0OLW4ODfdyFgvtSgzubg4 P08vL7VkEyMwJg9u+a27g3H1a8dDjAIcjEo8vD23lkcKsSaWFVfmHmKU4GBWEuFd8AEoxJuS WFmVWpQfX1Sak1p8iFGag0VJnNdh34UIIYH0xJLU7NTUgtQimCwTB6dUA6MOV+jzNya3DZfE xyZxvJQM+3VNqzjBv/bcG/4tJ268+qb/QMJuSlKyoa3Ov/YJ39/tzbc9u9rW5Nv6r+sTvj2d X8omJ29VfG/DZO/jJwOO7J7y+o1DTXzd4lohztpKMXFxkc0qNpXqs1av+WphuMX6oqb8+6Jt m45O3BBxR1fIt3eSoJj4bBYlluKMREMt5qLiRAAHzXWSxQIAAA== Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:49:05 -0000 --_000_D5CDD2DB20D69christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >Christer said: > >"However, one option would be to require consent in order to do switching.= Then, before the switching takes place, an endpoint would have to get cons= ent. And, if the remote peer has released the candidate the consent would f= ail, and the switch can=92t be done." > >[BA] That makes sense. > >Question: Is the list of post-nomination validated pairs solely chosen by= the controlling side maintaining consent on them? Or can the controlled s= ide indicate an interest in retaining a validated pair by maintaining conse= nt on it as well? If so, would this imply that controlling and controlled s= ides could send on different pairs? I guess the first question is: do you need to maintain consent? Or, is it e= nough to simply send keep-alive STUNs on the pairs that you=92d like to mai= ntain, and request consent when you are actually going to switch? Also, are both endpoints allowed to switch? Or, do we consider a switch a r= e-nomination, in which case I assume only the controlling agent is allowed = to do it? Regards, Christer On Thu, Aug 31, 2017 at 2:53 AM, Christer Holmberg > wrote: Hi, >The problem as I understand it is that RFC 5245bis is intended to be usabl= e by non-WebRTC implementations, so it cannot mandate (or even mention??) c= onsent. Correct. However, one option would be to require consent in order to do switching. T= hen, before the switching takes place, an endpoint would have to get consen= t. And, if the remote peer has released the candidate the consent would fai= l, and the switch can=92t be done. >If this seems silly to you (it does to me) maybe it would make more sense = to assume RFC 5245bis is for use in a modern ICE implementation usable with= WebRTC, because after all, isn't that what ICE developers should be workin= g on??? I think we also want =93legacy=94 implementations, that previously used non= -ICE mechanisms, to migrate to ICE. Regards, Christer On Aug 30, 2017, at 4:55 PM, Peter Thatcher > wrote: On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba > wrote: On Aug 30, 2017, at 12:28 PM, Peter Thatcher > wrote: On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher > wrote: As far as "just enough" so that it isn't a hindrance: that's why I wanted t= o say that agents *may* switch. It allows a renomination in the future. S= aying they MUST NOT is a hindrance. I would be fine if the *may* requires = negotiation. That's what https://www.ietf.org/archive/id/draft-thatcher-ic= e-renomination-01.txt does: it negotiates "renomination". And that's what = Chrome's implementation of WebRTC does. [BA] It seems like the document would at least need to talk about consent t= o include a "may". As it is, negotiating "ice2" only means that you're talk= ing to a slightly refurbished RFC 5245 implementation. That's like the diff= erence between a new car with driver assist (a modern WebRTC ICE implementa= tion with Trickle) and an Edsel that's been waxed and given an oil change. You always need to have consent to use a candidate pair. I guess the quest= ion you're asking is how recent does the consent need to be. But I'm not s= ure we need to standardize that. If an implementation chooses to be too ag= gressive about switching, it will send a path that doesn't work. In your a= nalogy, you're worried about the driver assist doing something dumb and cra= shing into the Edsel. Well, don't ship a car that crashes. Do we need to = standardize "don't switch to a candidate pair that doesn't work" (AKA don't= crash)? --_000_D5CDD2DB20D69christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5D01CF48D296934F8781A8C174087997@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>Christer said: 
>
>"However, one option would be to require consent in order= to do switching. Then, before the switching takes place, an endpoint would= have to get consent. And, if the remote peer has released the candidate the consent would fail, and the switch can=92t = be done."
>
>[BA] That makes sense. 
>
>Question:  Is the list of post-nomination validated pairs= solely chosen by the controlling side maintaining consent on them?  O= r can the controlled side indicate an interest in retaining a validated pair by maintaining consent on it as well? If so,= would this imply that controlling and controlled sides could send on diffe= rent pairs? 

I guess the first question is: do you need to maintain consent? Or, is= it enough to simply send keep-alive STUNs on the pairs that you=92d like t= o maintain, and request consent when you are actually going to switch?

Also, are both endpoints allowed to switch? Or, do we consider a switc= h a re-nomination, in which case I assume only the controlling agent is all= owed to do it?

Regards,

Christer



On Thu, Aug 31, 2017 at 2:53 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>The problem as I understand it is that RFC 5245bis is intended to = be usable by non-WebRTC implementations, so it cannot mandate (or even ment= ion??) consent. 

Correct.

However, one option would be to require consent in order to do switchi= ng. Then, before the switching takes place, an endpoint would have to get c= onsent. And, if the remote peer has released the candidate the consent woul= d fail, and the switch can=92t be done.

>If this seems silly to you (it does to me) maybe it would make mor= e sense to assume RFC 5245bis is for use in a modern ICE implementation usa= ble with WebRTC, because after all, isn't that what ICE developers should b= e working on???

I think we also want =93legacy=94 implementations, that previously use= d non-ICE mechanisms, to migrate to ICE.

Regards,

Christer



On Aug 30, 2017, at 4:55 PM, Peter Thatcher <pthatcher@google.com> wrote:



On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba <bernard.aboba@gmail.c= om> wrote:
On Aug 30, 2017, at 12:28 PM, Peter Thatcher <pthatcher@google.com> wrote:
On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher <pthatcher@google.com= > wrote:
As far as "just enough" so that it isn't a hindr= ance: that's why I wanted to say that agents *may* switch.  It allows = a renomination in the future.  Saying they MUST NOT is a hindrance.&nb= sp; I would be fine if the *may* requires negotiation.  That's what = https://www.ietf.org/archive/id/draft-thatcher-ice-renomination-0= 1.txt does: it negotiates "renomination".  And that's what Chrome's imp= lementation of WebRTC does. 

[BA] It seems like the document would at least need to talk about cons= ent to include a "may". As it is, negotiating "ice2" on= ly means that you're talking to a slightly refurbished RFC 5245 implementat= ion. That's like the difference between a new car with driver assist (a modern WebRTC ICE implementation with Trickle) and an Eds= el that's been waxed and given an oil change. 

You always need to have consent to use a candidate pair.  I guess= the question you're asking is how recent does the consent need to be. = ; But I'm not sure we need to standardize that.  If an implementation = chooses to be too aggressive about switching, it will send a path that doesn't work.  In your analogy, you're worried = about the driver assist doing something dumb and crashing into the Edsel.&n= bsp; Well, don't ship a car that crashes.  Do we need to standardize &= quot;don't switch to a candidate pair that doesn't work" (AKA don't crash)? 

 --_000_D5CDD2DB20D69christerholmbergericssoncom_--