From ietf-secretariat-reply@ietf.org Thu Aug 1 06:57:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63C211E80C5 for ; Thu, 1 Aug 2013 06:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRvGln5ld6DA for ; Thu, 1 Aug 2013 06:57:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 836C621E8093 for ; Thu, 1 Aug 2013 06:57:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130801135737.8188.90631.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2013 06:57:37 -0700 From: IETF Secretariat Subject: [manet] Milestones changed for manet WG X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:57:43 -0000 Changed milestone "Submit DSR specification to IESG for publication as Experimental RFC", set due date to March 2003 from March 2003. Changed milestone "Submit OLSR specification to IESG for publication as Experimental RFC", set due date to March 2003 from March 2003. Changed milestone "Develop a further focused problem statement and address an approach for a common engineering work effort", set due date to July 2003 from July 2003. Changed milestone "Submit initial ID of RMP for WG review", set due date to March 2005 from March 2005. Changed milestone "Submit initial ID of PMP for WG review", set due date to March 2005 from March 2005. Changed milestone "Submit inital ID of generalized MANET flooding approach", set due date to March 2005 from March 2005. Changed milestone "Submit PacketBB to IESG", set due date to December 2006 from December 2006. Changed milestone "Submit initial WG ID on MIB for NHDP, DYMO, OLSRv2", set due date to December 2006 from December 2006. Changed milestone "Submit Jitter Considerations Document to IESG", set due date to July 2012 from July 2012. Changed milestone "Submit Time TLV Document to IESG", set due date to July 2012 from July 2012. Changed milestone "Submit IANA Allocations Document to IESG", set due date to July 2012 from July 2012. Changed milestone "Submit packetBB Security Document to IESG", set due date to July 2012 from July 2012. Changed milestone "Submit OLSRv2 to IESG", set due date to July 2012 from July 2012, resolved as "Done". Changed milestone "Submit NHDP MIB to IESG", set due date to July 2012 from July 2012, resolved as "Done". Changed milestone "Submit OLSRv2 MIB to IESG", resolved as "Done". Changed milestone "Submit SMF MIB to IESG", resolved as "Done". Added milestone "Submit OLSRv2-metrics-rationale to IESG", due July 2013. Added milestone "Submit RFC6622-bis to IESG", due July 2013. Added milestone "Submit NHDP-OLSRv2-sec to IESG", due July 2013. Changed milestone "Submit REPORT MIB to IESG", set due date to November 2013 from March 2013. Changed milestone "Submit DLEP to IESG", set due date to March 2014 from March 2013. Added milestone "Submit AODVv2 to IESG", due August 2014. URL: http://datatracker.ietf.org/wg/manet/charter/ From prvs=1926358137=veytser@ll.mit.edu Fri Aug 2 13:00:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8634A11E8113 for ; Fri, 2 Aug 2013 13:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kahBA8iWrZ-x for ; Fri, 2 Aug 2013 13:00:46 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 3B14C11E80D7 for ; Fri, 2 Aug 2013 13:00:45 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r72K0hZ3028989 for ; Fri, 2 Aug 2013 16:00:43 -0400 From: "Veytser, Leonid - 0665 - MITLL" To: "manet@ietf.org" Date: Fri, 2 Aug 2013 15:59:13 -0400 Thread-Topic: OLSR [RFC 3626] Routing Table Calculation Clarification Thread-Index: Ac6Puvgma8DTDmoHQrm3lSidtEh/7w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_DCD459E2-8B17-4D42-8C65-B213573D4B40"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-02_08:2013-08-02, 2013-08-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308020182 Subject: [manet] OLSR [RFC 3626] Routing Table Calculation Clarification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 20:00:51 -0000 --Apple-Mail=_DCD459E2-8B17-4D42-8C65-B213573D4B40 Content-Type: multipart/alternative; boundary="Apple-Mail=_5263D970-BCB2-4150-82BB-FB0A7EE9F6DD" --Apple-Mail=_5263D970-BCB2-4150-82BB-FB0A7EE9F6DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I am seeking clarification of Section 3.2 of the OLSR RFC 3626 that = describes the tie breaking rules, when performing routing table = calculation, for picking the next hop when more than one are available: 3.2 Several topology entries may be used to select a next hop R_next_addr for reaching the node R_dest_addr. When h=3D1,= ties should be broken such that nodes with highest willingness and MPR selectors are preferred as next hop. Did the authors mean using MPRs as tie breakers as preferred next hop? = If not, and MPR selectors is what should be used to break the ties what = is the rationale? I can understand preferring MPRs as next hop since = OLSR tries to route through the MPRs but don't understand why an MPR = selector would be a preferred next hop? Thanks in advance, Lenny --------------------------------------------------------------- Leonid Veytser MIT Lincoln Laboratory Advanced Networking and Applications Group (781)981-1395 --Apple-Mail=_5263D970-BCB2-4150-82BB-FB0A7EE9F6DD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello,

I am seeking clarification of Section 3.2 of the OLSR RFC 3626 that describes the tie breaking rules, when performing routing table calculation, for picking the next hop when more than one are available:

          3.2  Several topology entries may be used to select a next hop
               R_next_addr for reaching the node R_dest_addr.  When h=1,
               ties should be broken such that nodes with highest
               willingness and MPR selectors are preferred as next hop.

Did the authors mean using MPRs as tie breakers as preferred next hop? If not, and MPR selectors is what should be used to break the ties what is the rationale? I can understand preferring MPRs as next hop since OLSR tries to route through the MPRs but don't understand why an MPR selector would be a preferred next hop?

Thanks in advance,

Lenny

---------------------------------------------------------------
Leonid Veytser
MIT Lincoln Laboratory
Advanced Networking and Applications Group
(781)981-1395



--Apple-Mail=_5263D970-BCB2-4150-82BB-FB0A7EE9F6DD-- --Apple-Mail=_DCD459E2-8B17-4D42-8C65-B213573D4B40 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITHzCCBLcw ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTIw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7DegMwcFYWZM6OknYzRgEO5g NgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDKIp5UX5N2BCzwu7BJJMwUJHFa S4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2QhPlNmk4ONpL/80Kx9wKKhV/NThe 54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0zXPQ70LYwOWXLlpxAolKcgwRVsS6/cse8 YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yKsORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1R NLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGI NFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwYQYIKwYBBQUHAQEEVTBTMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0G CyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJ MA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIB AwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8Q XAqkzSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD2o67 Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AUmeFH7xl0 E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWBsnsX3nVTRdHC Vi+Cf3Cx4YDWMIIEtzCCA5+gAwIBAgIBFDANBgkqhkiG9w0BAQsFADBUMQswCQYDVQQGEwJVUzEf MB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1N SVRMTCBSb290IENBMB4XDTA5MTIxNDEyMDAwMFoXDTE1MTIzMTIzNTk1OVowUTELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UE AxMKTUlUTEwgQ0EtMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKcEyyNhSIfsN6Az BwVhZkzo6SdjNGAQ7mA2A8T0kmdCB8MH6jWjVVMwFZwlg9cgjgLKEuEO9KN8K9M8jgeZEMoinlRf k3YELPC7sEkkzBQkcVpLhEwALue9iHowgSLGmXZpYKmRhfvhvYJ4MNCuIaWpcK/GaDZCE+U2aTg4 2kv/zQrH3AoqFX81OF7niwXNnanP1hQRfkMTRrnaEW8DX0TMaG/t9Ry5xSMrLTNc9DvQtjA5ZcuW nECiUpyDBFWxLr9yx7xgf1/LwgCxcoBeKSBBoWzkQmKAsgMo9Mq1Fp/nnIqw5FKmgOs7Vy+6e0Dk +cgf+oAV8AK8ZFMQrVE0uH0CAwEAAaOCAZUwggGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFI5KfYmhYxccgYg0VzcmRV4Zin4kMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0p MA4GA1UdDwEB/wQEAwIBhjBhBggrBgEFBQcBAQRVMFMwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwu bGwubWl0LmVkdS9nZXR0bz9MTFJDQTAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AubGwubWl0LmVk dTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGS BgNVHSAEgYowgYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcw DQYLKoZIhvcSAgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgED AQ4wDQYLKoZIhvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQELBQADggEBAIh3BqHQ /XH8C6DCL+eEGroOzxBcCqTNItmsv4MANaOTodgU2jrjHcGjXlzqhpb8ZxOlkAK3dK09rc6+yACc oK2TzVtDRZXYxov/SqZRjI3dufU2JatAPxosCyy/1otjl1TKUY47Wvft31vdf5i0XK2DQVEJ+Xlq tgBiFTVIMIfBJwPajrsiz+pgFEYwhhwJxvs8flSi0FLCE77VYLEioP5hxG6zIPeQRxzh1bogbfph WHHtoiTDkBSZ4UfvGXQTVf7QjhD5yYw10yICtjHmtgbfgBkH5/vvR92NY9RSlNPzZqmGKIia61bJ CmagRYGyexfedVNF0cJWL4J/cLHhgNYwggTPMIIDt6ADAgECAgo4c7d0AAAAAGcSMA0GCSqGSIb3 DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTIwHhcNMTMwNDIyMTgxODA2WhcNMTQwNDIy MTgxODA2WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEP MA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdWZXl0c2VyLkxlb25pZC41MDAwNzQxNTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALRAT8DkAboAZdHPFu7XluonBlh3bx73I2D7ZJAz8sZc kSpYP4GbiUBFkY7ZUKdjajpKBzCnCdKMObSL6mYjT/ibHCTpLQbHM4d0boQul4dmVcJX92oTqFna B0luEt7lX24rG+s+Ok+eHBP/uFMVYlieRuI1RhMoqwi0sV92SnQBzTtsFuoD/HihYE6vI8A4/cnC nUY9VsLtDRX75JoP/UOSNHWRX6CJdXZeutX4tf48e8fOKWNYaetYexmF62CarLiednEvwnSpMfhW sQX23ypfFAWrZOaEVsukTZ8TT2pakBT6m8snZFt/Se2HXILcQzSQh5ZK5mV7OE8piYp6cxcCAwEA AaOCAZcwggGTMB0GA1UdDgQWBBRhnkNeHfJxqqacmUjC/UozieTvRzAOBgNVHQ8BAf8EBAMCBsAw HwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDov L2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcBAQRWMFQwLQYIKwYBBQUHMAKG IWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAjBggrBgEFBQcwAYYXaHR0cDovL29j c3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcD BAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMB0GA1UdEQQWMBSBEnZleXRz ZXJAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAKPio9keWykTZ3cm5PhNlrWNsZUCQ48JU 3UFYfJQUuBIO3DDb1FbYXJBdKywxA8ckPFsTZ30s+tU80gR/HF7f5nODqlqgZkFyP0/j6lkL9u1K rX0W0IxmbdBXqVOXkMcS1MypwoHvmfRunLwRUGKoH8vL0V6uavdNkZTljc8h3kd+o4Kn+giyOUnk PYO835jJ+C62VbBPn9G/aVsm33/6RzRa1ZoS4tgUyE6n09vHIIbUa+ZfJW8E8Dw3WsHXpBvBe0zn RW0hjwpdp72WKcABevM7xRopngVSw6HKBPx7Lr054Owou0+udSFTyCSK1MIAocBofkf001C7H9pv VGGwIzCCBNIwggO6oAMCAQICCiNoc3QAAAAAWhAwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UE AxMKTUlUTEwgQ0EtMjAeFw0xMjEyMTgxOTAyNTBaFw0xMzEyMTgxOTAyNTBaMGExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIDAe BgNVBAMTF1ZleXRzZXIuTGVvbmlkLjUwMDA3NDE1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA0HyIRLLFoEllwbpQ+3c5+ebw68rspj8N8IsVDudRUwmhASQ63z5oQ6v9dnXPg/TQan33 6dCdugSXeGbE7vZ7XprjXrc7JzepqalaJfaN3MYZ0rL17Bf917Ja4m88jy/3oHHUiw2FMj9eyyES 9ykhsq4bqCzyRIZaI1fXoMLWGL1S2OQBrCvJzI53WObZdAQTgu2UnvZIgaCaeKazXDG05zAfvTqh ymp0AUvezKA6RAQie/FwOqB9aY+1skkYxlHqEPXo9tQR9XEY+epD2GLGY/NHyBx/ujU1XhOdU59e AKEWED0yEublw1i0AR2aUulYsbb+yK+yMPizjSI/WA+xzwIDAQABo4IBmjCCAZYwHQYDVR0OBBYE FBe+yVP3jzv/ItoIeyS+8t0QC3gJMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBSOSn2JoWMX HIGINFc3JkVeGYp+JDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 Y3JsL0xMQ0EyMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQu ZWR1L2dldHRvL0xMQ0EyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNV HRMBAf8EAjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEf HYXr0HCD6+0gAgFkAgEEMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgG A1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESdmV5dHNlckBsbC5taXQuZWR1MA0G CSqGSIb3DQEBCwUAA4IBAQBBPLeADnSA2dj1eMHYoIplzJDRPRFOo4Dw+Ct0mNk3MIXpEon8xrzs gDcIemLoEdzNWxQcAKoMvxlQF/8vF0N46qX5jXSC76C0HpTGeiInXP/q7XhjN4rVqpdR2HQkE1xc fWRBDNWx9TnZM5fKE2Ve9pGytHZDa3+lWISP4JmdzAdw6Max379VLNtu0vXNA84CzvNYqxip458G lFaJXjHmHmUN9fq6/O34jSDieOyivh3qbKCZIGY6RvMDKQta8HaztyUKo8EBNQp6CupFi9rEQzbp Of0dWBaSugV0jp4itjlS1s83eGxUrlp7N8GwyJ02FnL+8kc6930oZXhgPkwBMYICyTCCAsUCAQEw XzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UE CxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yAgo4c7d0AAAAAGcSMAkGBSsOAwIaBQCgggE/MBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgwMjE5NTkxNFowIwYJ KoZIhvcNAQkEMRYEFA8uj6k3rDkIqC2C2eNLXQROKyvwMG4GCSsGAQQBgjcQBDFhMF8wUTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMgIKI2hzdAAAAABaEDBwBgsqhkiG9w0BCRACCzFhoF8wUTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMgIKI2hzdAAAAABaEDANBgkqhkiG9w0BAQEFAASCAQCiHtK+9/I/ K9iuyXABUMf4qrw9av7SVvIRk42EipX0u4OIvPe5fsJsFoeLkb7hEOpCtZdA/mztFUj84xnKqgAw 9Znv780S3U/1pELfxQysIBIV2gi6FCVRLBLwXhtEu+cjz9F4rTkrNQV92b6zwt+TBNsPsplG2YXB f5xwV2y7MVlZ6d8DaJ+RNh8g/18aS+ghedgHshaMpn8GwJL5w9KLRmZj0+uxtln6d4wIh3elHnuG 2M0w0r6+8kZqabjrfNTI42LNxQHny3rdc9o4zQJG9Nyy764U0Id8AzgGRtzOeX1Dtc+56YNwJgqE zW1cAdPoAgeeWLQGkoplKK38NUA5AAAAAAAA --Apple-Mail=_DCD459E2-8B17-4D42-8C65-B213573D4B40-- From sratliff@cisco.com Tue Aug 6 07:01:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A70621F9E44 for ; Tue, 6 Aug 2013 07:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC06Jnw92YmW for ; Tue, 6 Aug 2013 07:01:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF6521F9E5C for ; Tue, 6 Aug 2013 07:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4731; q=dns/txt; s=iport; t=1375797665; x=1377007265; h=from:to:subject:date:message-id:mime-version; bh=iQeWZiQatfQed0aDRaKZUJ93vnF5xvtuM8G8gQ4U90c=; b=Qv1CJxCREdIjGBsVdbvMMSzbK85Jhops9JLpDMsZ1W3s7amlApY2EStM k0b5tZ+tfyrwTNHZv1VigjcIfPgfLdVohqADmOQ1fILfGzJSUJ4zyNdvX sIK2EYVsqYnTM0up3YL7r57Csw9YOJvJV1KfqJV974S1QHWpEOJ+z1+rf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALYAAVKtJXG8/2dsb2JhbABbgwY1UL59gR0WdIImAQRuHQEMHgMaORQTBBMIAYgHDJYFoFuOVIEVg1J0A6kvgxeBcTk X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208,217";a="244072387" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 06 Aug 2013 14:01:04 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r76E14YJ001254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 Aug 2013 14:01:04 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 09:01:04 -0500 From: "Stan Ratliff (sratliff)" To: "manet@ietf.org List" Thread-Topic: DLEP Design Team Thread-Index: AQHOkq1jZ+92y+3O3UuxGDWwHEAmaA== Date: Tue, 6 Aug 2013 14:01:03 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101E70DF@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C101E70DFxmbalnx03ciscoc_" MIME-Version: 1.0 Subject: [manet] DLEP Design Team X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 14:01:21 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C101E70DFxmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Formation of a Design Team to investigate common metrics that are applicabl= e to a number of RF devices. This is to announce the formation of a Design Team according to RFC 2418 se= ction 6.5 and the IESG statement at http://www.ietf.org/iesg/statement/design-team.html The design team will investigate common metrics that are applicable to a nu= mber of RF devices, with the goal being the inclusion of these metrics as standa= rd (or mandatory) metrics for DLEP implementations. Further, the design team w= ill discuss and recommend a strategy for dealing with radio devices capable of committing bandwidth to a specific traffic class (e.g., available bandwidth= is allocated based on DSCP traffic markings). The team is intended to provide input to the working group for open discuss= ion on the working group mailing list and is scheduled to report back to the wo= rking group by 9/15. The team members are - Teco Boot - Henning Rogge - John Dowdell - Rick Taylor - Ulrich Herberg - Stan Ratliff - Joe Macker Internally, the team will adopt the following milestones: - Teco Boot : Investigate 3G/4G/BGAN Satellite modems and report on usable metrics by 8/16. - Henning Rogge: Investigate Software Defined Radios (SDR) and WiFi metrics and report by 8/16 - Rick Taylor: Investigate Legacy Military Radios (e.g. EPLRS) with regard to metrics and report by 8/23 - John Dowdell: Investigate multihop Layer 2 mesh networks (e.g. the "Wave Relay" radio device from Persistent Systems) and report on viable metrics by 8/23. An email list will be made for discussions between the DT members. The list= will be closed to posting from and subscription by other people, but the archive= will be open. Provisionally, this list will be called manet-dlep-rg@ietf.org. --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C101E70DFxmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Formation of a Design Team to investigate common metrics that are applicabl= e to
a number of RF devices.

This is to announce the formation of a Design Team according to RFC 2418 se= ction
6.5 and the IESG statement at
http://www.= ietf.org/iesg/statement/design-team.html

The design team will investigate common metrics that are applicable to a nu= mber
of RF devices, with the goal being the inclusion of these metrics as standa= rd
(or mandatory) metrics for DLEP implementations. Further, the design team w= ill
discuss and recommend a strategy for dealing with radio devices capable of<= br> committing bandwidth to a specific traffic class (e.g., available bandwidth= is
allocated based on DSCP traffic markings).

The team is intended to provide input to the working group for open discuss= ion
on the working group mailing list and is scheduled to report back to the wo= rking
group by 9/15.

The team members are
- Teco Boot
- Henning Rogge
- John Dowdell
- Rick Taylor
- Ulrich Herberg
- Stan Ratliff
- Joe Macker

Internally, the team will adopt the following milestones:

- Teco Boot : Investigate 3G/4G/BGAN Satellite modems and report
  on usable metrics by 8/16.
- Henning Rogge: Investigate Software Defined Radios (SDR) and
  WiFi metrics and report by 8/16
- Rick Taylor: Investigate Legacy Military Radios (e.g. EPLRS) with
 regard to metrics and report by 8/23
- John Dowdell: Investigate multihop Layer 2 mesh networks
  (e.g. the "Wave Relay" radio device from Persistent S= ystems)
  and report on viable metrics by 8/23.

An email list will be made for discussions between the DT members. The list= will
be closed to posting from and subscription by other people, but the archive= will
be open. Provisionally, this list will be called manet-dlep-rg@ietf.org.
--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C101E70DFxmbalnx03ciscoc_-- From jch@pps.univ-paris-diderot.fr Wed Aug 7 05:13:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5D811E812D for ; Wed, 7 Aug 2013 05:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noLjDMewY+09 for ; Wed, 7 Aug 2013 05:13:29 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCDD11E811E for ; Wed, 7 Aug 2013 05:13:25 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r77CDOCH031949 for ; Wed, 7 Aug 2013 14:13:24 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D0C5156B36 for ; Wed, 7 Aug 2013 14:13:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id YCJf8OvQ3ftD for ; Wed, 7 Aug 2013 14:13:23 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-31-175-167-223.play-internet.pl [31.175.167.223]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 07A5756B31 for ; Wed, 7 Aug 2013 14:13:22 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V72cK-0001fn-Tv for manet@ietf.org; Wed, 07 Aug 2013 14:13:28 +0200 Date: Wed, 07 Aug 2013 14:13:28 +0200 Message-ID: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: manet@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 07 Aug 2013 14:13:24 +0200 (CEST) X-Miltered: at korolev with ID 520239E4.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 520239E4.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 520239E4.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 12:13:35 -0000 Dear list, Henning Rogge has asked me to repeat and clarify the comments that I made about draft-rogge-baccelli-olsrv2-ett-metric-02 in Berlin. So here it goes. 0. I'm delighted to see this draft. It has been known for almost a decade that hop-count is not a good choice for mesh networks, where it tends to prefer marginal links to solid links (some people like to speak of "worst path routing"). If OLSRv2 is to be relevant to real deployments, this draft or something very much like this is essential. 1. This is not ETT. This is a unidirectional link rate/packet loss metric very much unlike ETT. It MUST NOT be called ETT, or anything that might cause confusion with ETT. Suppose, for example, that Henning's metric doesn't work out. Then whenever we suggest using ETT, people will tell us "I thought that ETT didn't work", and we'll have a lot of explaining to do. Note that I don't care what you call it, as long as confusion is avoided. For example, one of the metrics used by Babel is called "Z3", and our users are quite happy to speak of the "Z3 metric", although they have no idea what the Z and the 3 stand for. (It was the third metric inspired by an IRC chat I had with somebody whose nick starts with a Z.) 2. This is not ETT. Unlike ETX/ETT, which have been extensively studied in the peer-reviewed litterature, I know of no publications about a unidirectional packet loss metric combined with link rate. While I'm pretty sure it will work out fine, I'd like to see hard data showing that this metric does in fact work. Alternatively, and preferably, I think that Henning should switch to pure ETT, so that he can draw on the wealth of previous experience with that particular metric. 3. Unfortunately, there is no place in the OLSRv2 packet format to carry the inverse packet loss needed to compute full ETX/ETT. I believe that such a standardised place should be provided, and suggested that Henning should define that. Stan indicated that Chris might be a better choice. Chris shrugged. Regards, -- Juliusz From jch@pps.univ-paris-diderot.fr Wed Aug 7 06:04:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B06A21E811C for ; Wed, 7 Aug 2013 06:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utmDU9MrgyOP for ; Wed, 7 Aug 2013 06:04:07 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 84AD121E8117 for ; Wed, 7 Aug 2013 06:04:07 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r77D42Af014272 for ; Wed, 7 Aug 2013 15:04:05 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E0AF356B38 for ; Wed, 7 Aug 2013 15:04:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id BSNMs-LrZ4BO for ; Wed, 7 Aug 2013 15:03:57 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-164-127-60-251.play-internet.pl [164.127.60.251]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7BCFD56B31 for ; Wed, 7 Aug 2013 15:03:56 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V73PC-0001z6-Dr for manet@ietf.org; Wed, 07 Aug 2013 15:03:58 +0200 Date: Wed, 07 Aug 2013 15:03:58 +0200 Message-ID: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: manet@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 07 Aug 2013 15:04:05 +0200 (CEST) X-Miltered: at korolev with ID 520245C2.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 520245C2.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 520245C2.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:04:13 -0000 Dear list, At the Berlin meeting, we were informed that DLEP is going to switch to using TCP as transport. Using TCP for transporting what is real-time data is a little bit suprising to me. Could I most humbly request the rationale for switching DLEP to TCP? -- Juliusz From henning.rogge@fkie.fraunhofer.de Wed Aug 7 06:09:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9205B21F871B for ; Wed, 7 Aug 2013 06:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdkcBj+wQAKL for ; Wed, 7 Aug 2013 06:09:50 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id AC77921F862B for ; Wed, 7 Aug 2013 06:09:49 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V73Uq-0001TS-IM for manet@ietf.org; Wed, 07 Aug 2013 15:09:48 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V73Uq-0003xO-Fk for manet@ietf.org; Wed, 07 Aug 2013 15:09:48 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 7 Aug 2013 15:09:48 +0200 Message-ID: <52024712.8090907@fkie.fraunhofer.de> Date: Wed, 7 Aug 2013 15:09:38 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020001050604040204000607" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17638/Wed Aug 7 13:56:17 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4c0df1132e657673ab78dbdd5ac9f7d6 Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:09:57 -0000 --------------ms020001050604040204000607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: > Dear list, > > At the Berlin meeting, we were informed that DLEP is going to switch > to using TCP as transport. Using TCP for transporting what is > real-time data is a little bit suprising to me. > > Could I most humbly request the rationale for switching DLEP to TCP? Part of the rationale was that DLEP is transporting only database=20 changes between radio and router. If any of this changes has been lost,=20 the database of the router might stay inconsistent for quite some time. The current DLEP draft has the concept of acknowledgements between radio = and router to make sure that this doesn't happen, but acknowledgements=20 present us with a new problem. Either we create a "stop and wait" style protocol which waits for each=20 acknowledgement before sending the next data packet, or we need to add=20 sequence numbers to data and acknowledgement. Because DLEP updates might not make sense in the wrong order, we would=20 have to start reproducing parts of TCP with buffering, windows and acks. Switching to a reliable transport protocol solves most of this problems. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020001050604040204000607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MDcxMzA5NDdaMCMGCSqGSIb3DQEJBDEWBBQQ5akhovCPDyAQ2cAhfYMzDuEq3zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAfEDN4abkMb2FWOJOeIaQJY4C+MeIGN0h4fLDpgt1F1sS ie9gisz34ggNki6duUJTcMff0HgGOJnreffG0j6SEski+CblNsW1dq+UfBz98yvMVHwJbbqX Udr8ZYYbEdKbxLKdPSLft3a5qmXHLtaeefrE5ULOkGa0DWa0s3QP8+4I91wKBUhNSUJ0KXrU Lf1giMS3W8Y4wKDweh6YdfavH/DpMImv8a4CPq4CtfH0c1DRoQOQTZ55CyJZ4811bcLWeXpA uX7/2mGwLhSqDC+4hyTsoQsAwkljkfgmaOX+fwLORIVeEC0UimMIrRK3Mx8yoZhv9kjOb13v utqvCBxrqgAAAAAAAA== --------------ms020001050604040204000607-- From chris.dearlove@baesystems.com Wed Aug 7 07:21:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45AC21E812D for ; Wed, 7 Aug 2013 07:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.546 X-Spam-Level: X-Spam-Status: No, score=-9.546 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESwJojP3axqS for ; Wed, 7 Aug 2013 07:21:09 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2F721F8CDD for ; Wed, 7 Aug 2013 07:21:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,833,1367967600"; d="scan'208";a="305172466" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 07 Aug 2013 15:21:04 +0100 X-IronPort-AV: E=Sophos;i="4.89,833,1367967600"; d="scan'208";a="24638846" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 07 Aug 2013 15:21:04 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.90]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 15:21:04 +0100 From: "Dearlove, Christopher (UK)" To: Juliusz Chroboczek , "manet@ietf.org" Thread-Topic: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 Thread-Index: AQHOk2eUwRww7Jk9E0e8cj+lD3bcH5mJxfbw Date: Wed, 7 Aug 2013 14:21:04 +0000 Message-ID: References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:21:13 -0000 I don't believe "Chris shrugged" is an accurate representation. There are multiple levels at which you have to consider addition of the sor= t of information you suggest: - Is there a possible place in the packet or message structure (I'll come b= ack to which in a later point) to add the information? There we have a flex= ible format that could certainly include anything you want. - Is there a specification of a format in which to carry the information? N= o, not at present, but TLVs can, and have been, defined as needed. (So whether your "Unfortunately, there is no place" is correct depends on w= hether you meant, no place defined, or no place definable. As it could mean= the latter, which is not so, I think it's unfortunately phrased. Actually = even if you meant the former, I don't find it unfortunate at all, I find it= good design to not specify things unnecessarily when you still don't know = what you want, as you are just likely to get it wrong. And "standardised pl= ace" is also not quite right, it's not in a fixed place - beyond which TLV = block it belongs in - but a defined means of attaching the information.) - This appears to need a protocol to handle that information. Where does th= at protocol live? Here you have to be very careful. (We've already discusse= d that Henning's metric needs some consideration here,) The formal position= is that we have what we usually call the 5444 multiplexer/demultiplexer. I= t owns packets, and additions to the packet header, such as packet TLVs. If= you want to consider all packets on an interface then you are interacting = with this process. If you want to report this at all times, you need to do = this in the packet header, as there may not be any relevant messages. (Alte= rnative, create what is also a new protocol with a new message type. This w= ould appear to be a bad idea, for a number of reasons, at least without a g= ood reason why.) Or if measuring all packets, but only reporting less often= , say in HELLO messages, then you are now creating what is also an extensio= n to NHDP. - If your protocol does work, calculates a metric, does what it has to do (= update the appropriate L_in_metric) then it's an extension to NHDP (that ow= ns the Link Set being updated) and OLSRv2 (which added that element to a Li= nk Tuple). - While you can start by considering what is sent to whom without getting i= nto these details, before you finish you'll need to have those points (rela= tionship to 5444, NHDP and OLSRv2, exacty TLV specifications) pinned down, = or you won't get through the IESG. (You shouldn't get through the WG before= that.) - And there are some things to get right - such as needing an L_in_metric a= s soon as a neighbour is heard. You might have to make that "maximum until = know better", but as currently defined, I don't think you can make unknown = pending information. So in summary, all is possible, but the devil is in the details, which need= to be got right. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of J= uliusz Chroboczek Sent: 07 August 2013 13:13 To: manet@ietf.org Subject: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Dear list, Henning Rogge has asked me to repeat and clarify the comments that I made about draft-rogge-baccelli-olsrv2-ett-metric-02 in Berlin. So here it goes. 0. I'm delighted to see this draft. It has been known for almost a decade that hop-count is not a good choice for mesh networks, where it tends to prefer marginal links to solid links (some people like to speak of "worst path routing"). If OLSRv2 is to be relevant to real deployments, this draft or something very much like this is essential. 1. This is not ETT. This is a unidirectional link rate/packet loss metric very much unlike ETT. It MUST NOT be called ETT, or anything that might cause confusion with ETT. Suppose, for example, that Henning's metric doesn't work out. Then whenever we suggest using ETT, people will tell us "I thought that ETT didn't work", and we'll have a lot of explaining to do. Note that I don't care what you call it, as long as confusion is avoided. For example, one of the metrics used by Babel is called "Z3", and our users are quite happy to speak of the "Z3 metric", although they have no idea what the Z and the 3 stand for. (It was the third metric inspired by an IRC chat I had with somebody whose nick starts with a Z.) 2. This is not ETT. Unlike ETX/ETT, which have been extensively studied in the peer-reviewed litterature, I know of no publications about a unidirectional packet loss metric combined with link rate. While I'm pretty sure it will work out fine, I'd like to see hard data showing that this metric does in fact work. Alternatively, and preferably, I think that Henning should switch to pure ETT, so that he can draw on the wealth of previous experience with that particular metric. 3. Unfortunately, there is no place in the OLSRv2 packet format to carry the inverse packet loss needed to compute full ETX/ETT. I believe that such a standardised place should be provided, and suggested that Henning should define that. Stan indicated that Chris might be a better choice. Chris shrugged. Regards, -- Juliusz _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Wed Aug 7 07:24:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A575521F8E2A for ; Wed, 7 Aug 2013 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH7sMi-vQwXg for ; Wed, 7 Aug 2013 07:24:48 -0700 (PDT) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by ietfa.amsl.com (Postfix) with ESMTP id E675611E8124 for ; Wed, 7 Aug 2013 07:24:44 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id mx10so278451bkb.24 for ; Wed, 07 Aug 2013 07:24:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=YSm1mAE8UdAFdJvbTYYxeRLhLmFHaUHkmCIYA559p48=; b=GHY5UFN8laIa7bkw4BJgJizDlzxljiikxTuuy+DqTfW89C3M42nyxrhTxh/9/ClmYE U9VJZyWAbjmop6TS9PoGQB+tbhd+cyzpYp+IIlh2v3cYqyD3oiaXN9rUVTsOjMqfbrNi 7dKLfg2c3uzrkut6g4WaUihxMZ6IAlhT2te6rgNLiBMbRLnv3KpZXDnOqsXnwxBU91kI rKmab6Hi5k1/UmxAZ+CK459/oMNO9dvKUASqKUHCEHIqK/LDkP1GbcIiQr5IE1cqwNNM kuFVCn2c/qav6UDtKMWjFe9Wxx8NQT66+kOoCbnnCBWyCfykzWGVDAs10F6X7vV+qOVU G37w== X-Gm-Message-State: ALoCoQkxvYRTBG18O+Z5iPDEAEQQl9iekAOrTbZEn5uJrch8Fu2I0/yahgxxjiK7Sx8x5rmxePWs X-Received: by 10.205.86.193 with SMTP id at1mr592949bkc.150.1375885483885; Wed, 07 Aug 2013 07:24:43 -0700 (PDT) Received: from [10.87.47.107] ([88.128.80.4]) by mx.google.com with ESMTPSA id et15sm1819397bkc.0.2013.08.07.07.24.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 07:24:42 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <52024712.8090907@fkie.fraunhofer.de> Date: Wed, 7 Aug 2013 16:24:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> To: "manet@ietf.org List" X-Mailer: Apple Mail (2.1508) Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:24:54 -0000 To add a few other mentioned arguments: - link between peers is a high speed link, there shouldn't be much = difference in delay - many radio's have already a TCP stack (e.g. web server for = management) - shortening the DLEP draft by reusing what is already available makes = a lot of sense - where DLEP is used on non-IP links (e.g. within a chassis), there has = to be a reliable transport protocol. standardization of such is not a = task for IETF. the draft will say: if there is an IP link, TCP is used = for reliable transport with peer. Of course peer discovery is not TCP. =20 Teco Op 7 aug. 2013, om 15:09 heeft Henning Rogge = het volgende geschreven: > On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: >> Dear list, >>=20 >> At the Berlin meeting, we were informed that DLEP is going to switch >> to using TCP as transport. Using TCP for transporting what is >> real-time data is a little bit suprising to me. >>=20 >> Could I most humbly request the rationale for switching DLEP to TCP? >=20 > Part of the rationale was that DLEP is transporting only database = changes between radio and router. If any of this changes has been lost, = the database of the router might stay inconsistent for quite some time. >=20 > The current DLEP draft has the concept of acknowledgements between = radio and router to make sure that this doesn't happen, but = acknowledgements present us with a new problem. >=20 > Either we create a "stop and wait" style protocol which waits for each = acknowledgement before sending the next data packet, or we need to add = sequence numbers to data and acknowledgement. >=20 > Because DLEP updates might not make sense in the wrong order, we would = have to start reproducing parts of TCP with buffering, windows and acks. >=20 > Switching to a reliable transport protocol solves most of this = problems. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Wed Aug 7 07:45:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174C221E8117 for ; Wed, 7 Aug 2013 07:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoTfeR9KZFVZ for ; Wed, 7 Aug 2013 07:45:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E00A21F9703 for ; Wed, 7 Aug 2013 07:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3279; q=dns/txt; s=iport; t=1375886752; x=1377096352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2H+xmmGts4rTVH7DtO5BNHSIgOFNtJ0BG8Gms/++yGg=; b=KDc++bNER5Ym6AJQ+WuFn0QlEEccQy6Pt9/+QoDFO0zBTthPqSPtlfXE +6SR6eeoCQ9bAs/OsvyF2GE6M0JOKemkzx72diiEPhcPFDT5MTFsEFurr 3rK64Utqlw8hONKQONsIg8YtD1xqi1tYkOI1SVXC61ltyx73zt/3PRzMp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAAJdAlKtJXG//2dsb2JhbABbgwY1UL5GgRwWdIIkAQEBAwEBAQFrCwULAgEIGAodBycLFBECBA4FCIgCBgy4O49nAjEHgxp0A4hzixeVJoMXgio X-IronPort-AV: E=Sophos;i="4.89,833,1367971200"; d="scan'208";a="241576727" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 07 Aug 2013 14:45:51 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r77EjpBL018496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 14:45:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 09:45:50 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26ihqeH9HMbGU+WXMCShCPLOJmKC7EAgAAU9ICAAAXyAA== Date: Wed, 7 Aug 2013 14:45:50 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> In-Reply-To: <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7C4A1444A252454BBAB38BEE01E11C7F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:45:57 -0000 Completely agree with what Henning and Teco have said. I'd like to elaborat= e just a tad on one of Teco's points:=20 On Aug 7, 2013, at 10:24 AM, Teco Boot wrote: > To add a few other mentioned arguments: > - link between peers is a high speed link, there shouldn't be much differ= ence in delay DLEP runs *only* on the local radio-to-router link. It is *not* specified t= o run over the RF. At least in the networks I've deployed, the local radio= -to-router link is typically a FastEthernet. Secondly, we're only talking a= bout the DLEP control traffic itself - there's no impact to data traffic ov= er the RF. Given all of that, plus picking up the guaranteed delivery, movi= ng to TCP doesn't seem onerous. Regards, Stan > - many radio's have already a TCP stack (e.g. web server for management) > - shortening the DLEP draft by reusing what is already available makes a = lot of sense > - where DLEP is used on non-IP links (e.g. within a chassis), there has t= o be a reliable transport protocol. standardization of such is not a task f= or IETF. the draft will say: if there is an IP link, TCP is used for reliab= le transport with peer. >=20 > Of course peer discovery is not TCP. >=20 > Teco >=20 > Op 7 aug. 2013, om 15:09 heeft Henning Rogge het volgende geschreven: >=20 >> On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: >>> Dear list, >>>=20 >>> At the Berlin meeting, we were informed that DLEP is going to switch >>> to using TCP as transport. Using TCP for transporting what is >>> real-time data is a little bit suprising to me. >>>=20 >>> Could I most humbly request the rationale for switching DLEP to TCP? >>=20 >> Part of the rationale was that DLEP is transporting only database change= s between radio and router. If any of this changes has been lost, the datab= ase of the router might stay inconsistent for quite some time. >>=20 >> The current DLEP draft has the concept of acknowledgements between radio= and router to make sure that this doesn't happen, but acknowledgements pre= sent us with a new problem. >>=20 >> Either we create a "stop and wait" style protocol which waits for each a= cknowledgement before sending the next data packet, or we need to add seque= nce numbers to data and acknowledgement. >>=20 >> Because DLEP updates might not make sense in the wrong order, we would h= ave to start reproducing parts of TCP with buffering, windows and acks. >>=20 >> Switching to a reliable transport protocol solves most of this problems. >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jpmacker@gmail.com Wed Aug 7 11:31:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9711E8168 for ; Wed, 7 Aug 2013 11:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MOPZkuRCPwx for ; Wed, 7 Aug 2013 11:31:11 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C13FF11E8159 for ; Wed, 7 Aug 2013 11:31:09 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id i72so797917yha.18 for ; Wed, 07 Aug 2013 11:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=tOkX6nyt1OC0EaRSKgwe4NrPVIGT6X7toTnF9EWGjuE=; b=GQ7FFZSMKqSOUoeleAu2TL/qH7hQ9h4IX8LEwXPrLPUU1oEkXpSQ3KV9puHlprHqfE GdIJluDttGQx8V2q7jzoapixWP3BMoqj2F5jnow4HTsq6hetOsiXPg/wz+QA+93AsqlO 6F48x3EjtiqKi1zCCDpeUXBvhj+uSmkJ2zto2U/g2mQ/Df+eXpXt+nAYSDClWGNh9ob9 B0vtoOwjJ0AoS/VFv8uvbg1SiLTqYwHqwZk4m4DssEeRQPbSv3VKj77xQjkFKmdw5wuC 0fDCpu49vF5IY4J9soVnCfgbkfx7OtfNF+pSoCSjt1vaOeoHu0afiEcrO3vBpL9zww59 +Hmw== X-Received: by 10.236.73.4 with SMTP id u4mr2584885yhd.220.1375900269140; Wed, 07 Aug 2013 11:31:09 -0700 (PDT) Received: from [10.118.28.232] ([107.228.139.125]) by mx.google.com with ESMTPSA id g39sm11238665yhb.13.2013.08.07.11.31.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 11:31:08 -0700 (PDT) References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> Mime-Version: 1.0 (1.0) In-Reply-To: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Joe Macker Date: Wed, 7 Aug 2013 14:31:02 -0400 To: Juliusz Chroboczek Cc: "manet@ietf.org" Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:31:18 -0000 Sent from my iPhone On Aug 7, 2013, at 8:13 AM, Juliusz Chroboczek wrote: > Dear list, >=20 > Henning Rogge has asked me to repeat and clarify the comments that > I made about draft-rogge-baccelli-olsrv2-ett-metric-02 in Berlin. So > here it goes. >=20 >=20 > 0. I'm delighted to see this draft. It has been known for almost > a decade that hop-count is not a good choice for mesh networks, where > it tends to prefer marginal links to solid links (some people like to > speak of "worst path routing"). If OLSRv2 is to be relevant to real > deployments, this draft or something very much like this is essential. >=20 >=20 > 1. This is not ETT. This is a unidirectional link rate/packet loss > metric very much unlike ETT. It MUST NOT be called ETT, or anything > that might cause confusion with ETT. >=20 > Suppose, for example, that Henning's metric doesn't work out. Then > whenever we suggest using ETT, people will tell us "I thought that ETT > didn't work", and we'll have a lot of explaining to do. >=20 > Note that I don't care what you call it, as long as confusion is > avoided. For example, one of the metrics used by Babel is called > "Z3", and our users are quite happy to speak of the "Z3 metric", > although they have no idea what the Z and the 3 stand for. (It was > the third metric inspired by an IRC chat I had with somebody whose > nick starts with a Z.) >=20 >=20 > 2. This is not ETT. Unlike ETX/ETT, which have been extensively > studied in the peer-reviewed litterature, I know of no publications > about a unidirectional packet loss metric combined with link rate. > While I'm pretty sure it will work out fine, I'd like to see hard data > showing that this metric does in fact work. i agree this is not ETT and should be called something else >=20 > Alternatively, and preferably, I think that Henning should switch to > pure ETT, so that he can draw on the wealth of previous experience > with that particular metric. >=20 good topic for further discussion >=20 > 3. Unfortunately, there is no place in the OLSRv2 packet format to > carry the inverse packet loss needed to compute full ETX/ETT. > I believe that such a standardised place should be provided, and > suggested that Henning should define that. Stan indicated that Chris > might be a better choice. Chris shrugged. i think an extension in nhdp aignaling is the better place to get the initia= l ETT metric. could then be consumed by and carried in metric packets of rou= ting such as LS updates >=20 >=20 > Regards, >=20 > -- Juliusz > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Aug 7 11:40:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EDA21F9C4F for ; Wed, 7 Aug 2013 11:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gim9QiS0Dojz for ; Wed, 7 Aug 2013 11:40:40 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 01B4521F9A2A for ; Wed, 7 Aug 2013 11:40:38 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id m15so1110279qcq.28 for ; Wed, 07 Aug 2013 11:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0NUwLkd7rIxjikV9JjnihfdV7qvmeUKoWHc+uVgptt4=; b=e7FPzxYmCGmnJfmho8KTZAdMxH6Wn7yRFRAqSS34rQstV9mWDUQA1DeC1ABruqS/8L TDnhFikMYUzLYe+n+97WSnmXgkjV0Bn7DilTcpc5wcoP6KBdHwaiX7kS8ZT/TXEOAKWd DHQk9PbiNSq5RtL4019c7cBE5wvlRaecnB+csc0liObaHTX/ggpssIIaqiorZKeinmp5 mImkXWMcTiNp5kXuUYuTiMnLGm/ckQLQh7ttYtt/sKcTLm1R3Ks6Ycoz+fLvZeyQWAoB q4P2l8uBrNbw9nkBQ6AlpsjBq8FXb60F09kt83OwOYc1TcP/Jt7vJAM9yf/4tEiJ4QDB O4cQ== X-Received: by 10.224.162.210 with SMTP id w18mr2162741qax.56.1375900838184; Wed, 07 Aug 2013 11:40:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.164.198 with HTTP; Wed, 7 Aug 2013 11:40:18 -0700 (PDT) In-Reply-To: References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Wed, 7 Aug 2013 20:40:18 +0200 Message-ID: To: Joe Macker Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , Juliusz Chroboczek Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:40:41 -0000 On Wed, Aug 7, 2013 at 8:31 PM, Joe Macker wrote: > On Aug 7, 2013, at 8:13 AM, Juliusz Chroboczek wrote: >> 3. Unfortunately, there is no place in the OLSRv2 packet format to >> carry the inverse packet loss needed to compute full ETX/ETT. >> I believe that such a standardised place should be provided, and >> suggested that Henning should define that. Stan indicated that Chris >> might be a better choice. Chris shrugged. > > i think an extension in nhdp aignaling is the better place to get the initial ETT metric. could then be consumed by and carried in metric packets of routing such as LS updates I think the easiest way to allow this signaling is to request an additional message-type specific address-tlv for NHDP Hello messages. Every link metric can use this TLV with the same extension type to transport any kind of data to the other side of the link to be received and processed there. It wouldn't be necessary for a directional metric, but might be necessary for a 'symmetrical' metric. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From teco@inf-net.nl Wed Aug 7 12:44:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8191821E80A8 for ; Wed, 7 Aug 2013 12:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8myVIBz5x-p for ; Wed, 7 Aug 2013 12:44:23 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id D3C2F21E8095 for ; Wed, 7 Aug 2013 12:44:21 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d17so1075059eek.14 for ; Wed, 07 Aug 2013 12:44:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=UMSL5ml7NeLl9fhFCCpSXTK6n1IoTnD5mF6KfkoJaA8=; b=giJ6WqYGrvXa1f5T0N6Ea0gOaU10bEhqEKdneEYDess59fB4yt0eRwOXBS5yTa80x7 fGZQVXNCKbwSCOnnG9TTxEAWqzSLwgdsf/bWvr8XbY+S1GcQFZ+yZBb0yEHBoBnEapKa 8DvZU0FFSv8XbHy7Or9gDavgDKDotG9ZBBWbD3O5p3MNkwLRVavIuDT9AXqLmKseAb4V CEJzwulZcbYhirNxGO4E3Uh0/E6LlMK/2eYbifbDPHulRLgMi8JcKSZy4XxHoISfXzMT r0Z5V1RVNvQ+8eTyE3Bgc8jcD+W2bqBmvdI2Ik12+lj0mjeQQhzC0Lt8hJXL/46ZUfd0 CU/w== X-Gm-Message-State: ALoCoQmXjx+KKHxAcyPkTJ6m0XoTdQOQlEGzrhZGkgnZibeh6nwt7865P03yKxEefSr+JMQaymc/ X-Received: by 10.14.241.74 with SMTP id f50mr4689557eer.29.1375904660839; Wed, 07 Aug 2013 12:44:20 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id a6sm422988eei.10.2013.08.07.12.44.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 12:44:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Wed, 7 Aug 2013 21:44:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29C76979-0778-4707-9133-7E000A9F6D1A@inf-net.nl> References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> To: Henning Rogge X-Mailer: Apple Mail (2.1508) Cc: "manet@ietf.org" , Juliusz Chroboczek Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 19:44:28 -0000 Op 7 aug. 2013, om 20:40 heeft Henning Rogge het = volgende geschreven: > On Wed, Aug 7, 2013 at 8:31 PM, Joe Macker wrote: >> On Aug 7, 2013, at 8:13 AM, Juliusz Chroboczek = wrote: >>> 3. Unfortunately, there is no place in the OLSRv2 packet format to >>> carry the inverse packet loss needed to compute full ETX/ETT. >>> I believe that such a standardised place should be provided, and >>> suggested that Henning should define that. Stan indicated that = Chris >>> might be a better choice. Chris shrugged. >>=20 >> i think an extension in nhdp aignaling is the better place to get the = initial ETT metric. could then be consumed by and carried in metric = packets of routing such as LS updates >=20 > I think the easiest way to allow this signaling is to request an > additional message-type specific address-tlv for NHDP Hello messages. > Every link metric can use this TLV with the same extension type to > transport any kind of data to the other side of the link to be > received and processed there. >=20 > It wouldn't be necessary for a directional metric, but might be > necessary for a 'symmetrical' metric. My experience with ETX is that in practice, links are not symmetric. Same for data rate. The Directional-ETT as proposed doesn't need signaling over the air. I suggest to keep the proposal as is and not to comply to a formal ETT = specification. Just rename will do. Teco > Henning Rogge >=20 > --=20 > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From chris.dearlove@baesystems.com Thu Aug 8 05:11:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4289B21F8FA1 for ; Thu, 8 Aug 2013 05:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR9EiRugEVHe for ; Thu, 8 Aug 2013 05:11:13 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 796EB21E8091 for ; Thu, 8 Aug 2013 05:10:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,838,1367967600"; d="scan'208";a="305407599" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 08 Aug 2013 13:10:51 +0100 X-IronPort-AV: E=Sophos;i="4.89,838,1367967600"; d="scan'208";a="24750290" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 08 Aug 2013 13:10:51 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.90]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 13:10:51 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Joe Macker Thread-Topic: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 Thread-Index: AQHOk2eUwRww7Jk9E0e8cj+lD3bcH5mKAPcAgAAClgCAATUT8A== Date: Thu, 8 Aug 2013 12:10:51 +0000 Message-ID: References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , Juliusz Chroboczek Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 12:11:20 -0000 If this is a metric for OLSRv2, ask yourself why you want a symmetric metri= c. The metric used in OLSRv2 is, by design, directional, both because links= are different in the two directions (for several reasons) and because it a= voids having to negotiate a metric. Now if you introduce a protocol to ensu= re a symmetric metric, you will then pass it to OLSRv2, which will then pro= ceed to ignore that the metric is the same in each direction. The only win = is that the metric storage in the message will be more compact, but you'll = then throw that away in the negotiation. The negotiation will also reduce r= esponsiveness to change, but that may or may not matter as you don't want t= o be too responsive. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 07 August 2013 19:40 To: Joe Macker Cc: manet@ietf.org; Juliusz Chroboczek Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-= 02 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Wed, Aug 7, 2013 at 8:31 PM, Joe Macker wrote: > On Aug 7, 2013, at 8:13 AM, Juliusz Chroboczek wrote: >> 3. Unfortunately, there is no place in the OLSRv2 packet format to >> carry the inverse packet loss needed to compute full ETX/ETT. >> I believe that such a standardised place should be provided, and >> suggested that Henning should define that. Stan indicated that Chris >> might be a better choice. Chris shrugged. > > i think an extension in nhdp aignaling is the better place to get the ini= tial ETT metric. could then be consumed by and carried in metric packets of= routing such as LS updates I think the easiest way to allow this signaling is to request an additional message-type specific address-tlv for NHDP Hello messages. Every link metric can use this TLV with the same extension type to transport any kind of data to the other side of the link to be received and processed there. It wouldn't be necessary for a directional metric, but might be necessary for a 'symmetrical' metric. Henning Rogge -- = We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Thu Aug 8 06:22:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410F421F9A14 for ; Thu, 8 Aug 2013 06:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is4se4yUq8Cw for ; Thu, 8 Aug 2013 06:22:03 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3913D11E811E for ; Thu, 8 Aug 2013 06:22:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,839,1367967600"; d="scan'208,217";a="305434470" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 08 Aug 2013 14:22:02 +0100 X-IronPort-AV: E=Sophos;i="4.89,839,1367967600"; d="scan'208,217";a="24764170" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 08 Aug 2013 14:22:02 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.90]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 14:22:02 +0100 From: "Dearlove, Christopher (UK)" To: "Veytser, Leonid - 0665 - MITLL" , "manet@ietf.org" Thread-Topic: OLSR [RFC 3626] Routing Table Calculation Clarification Thread-Index: Ac6Puvgma8DTDmoHQrm3lSidtEh/7wEfofFw Date: Thu, 8 Aug 2013 13:22:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DBC811CGLKXM0002VGREEN_" MIME-Version: 1.0 Subject: Re: [manet] OLSR [RFC 3626] Routing Table Calculation Clarification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 13:22:08 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DBC811CGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Actually, except for the first hop (and the second hop when using two hop i= nformation from HELLO messages) routes use links from MPR to MPR selector, = as advertised in TC messages. [The easiest way to see this must be so, in my experience, is to consider t= he final hop of a route, where the destination is a leaf node, reachable on= ly from one other node.] The h =3D 1 case tries to make similar behaviour a preference for the first= hop. (Flooding goes from MPR selector to MPR, however.) -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of V= eytser, Leonid - 0665 - MITLL Sent: 02 August 2013 20:59 To: manet@ietf.org Subject: [manet] OLSR [RFC 3626] Routing Table Calculation Clarification Hello, I am seeking clarification of Section 3.2 of the OLSR RFC 3626 that describ= es the tie breaking rules, when performing routing table calculation, for p= icking the next hop when more than one are available: 3.2 Several topology entries may be used to select a next hop R_next_addr for reaching the node R_dest_addr. When h=3D1, ties should be broken such that nodes with highest willingness and MPR selectors are preferred as next hop. Did the authors mean using MPRs as tie breakers as preferred next hop? If n= ot, and MPR selectors is what should be used to break the ties what is the = rationale? I can understand preferring MPRs as next hop since OLSR tries to= route through the MPRs but don't understand why an MPR selector would be a= preferred next hop? Thanks in advance, Lenny --------------------------------------------------------------- Leonid Veytser MIT Lincoln Laboratory Advanced Networking and Applications Group (781)981-1395 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DBC811CGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Actually, except for the = first hop (and the second hop when using two hop information from HELLO mes= sages) routes use links from MPR to MPR selector, as advertised in TC messages.

 <= /p>

[The easiest way to see t= his must be so, in my experience, is to consider the final hop of a route, = where the destination is a leaf node, reachable only from one other node.]

 <= /p>

The h =3D 1 case tries to= make similar behaviour a preference for the first hop.

 <= /p>

(Flooding goes from MPR s= elector to MPR, however.)

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Veytser, Leonid - 0665 - MITLL
Sent: 02 August 2013 20:59
To: manet@ietf.org
Subject: [manet] OLSR [RFC 3626] Routing Table Calculation Clarifica= tion

 

Hello,

 

I am seeking clarification of Section 3.2 of the OLS= R RFC 3626 that describes the tie breaking rules, when performing routing t= able calculation, for picking the next hop when more than one are available= :

 

&n=
bsp;         3.2  Several topo=
logy entries may be used to select a next hop
&n=
bsp;            =
;  R_next_addr for reaching the node R_dest_addr.  When h=3D1,
&n=
bsp;            =
;  ties should be broken such that nodes with highest
&n=
bsp;            =
;  willingness and MPR selectors are preferred as next hop.=

 

Did the authors mean using MPRs as tie breakers as p= referred next hop? If not, and MPR selectors is what should be used to brea= k the ties what is the rationale? I can understand preferring MPRs as next = hop since OLSR tries to route through the MPRs but don't understand why an MPR selector would be a preferred nex= t hop?

 

Thanks in advance,

 

Lenny

 

----------------------------------------------------= -----------
Leonid Veytser
MIT Lincoln Laboratory
Advanced Networking and Applications Group
(781)981-1395

 

 

 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DBC811CGLKXM0002VGREEN_-- From Martin.Duke@boeing.com Thu Aug 8 08:57:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D0F21F99ED for ; Thu, 8 Aug 2013 08:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pAwdKkAxVzx for ; Thu, 8 Aug 2013 08:57:01 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 27ACA21F8F63 for ; Thu, 8 Aug 2013 08:57:01 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r78Fv0Lb021363 for ; Thu, 8 Aug 2013 10:57:00 -0500 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r78Fuw0P020857 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 8 Aug 2013 10:56:59 -0500 Received: from XCH-BLV-303.nw.nos.boeing.com (130.247.25.215) by XCH-NWHT-05.nw.nos.boeing.com (130.247.25.109) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 8 Aug 2013 08:56:58 -0700 Received: from XCH-BLV-503.nw.nos.boeing.com ([169.254.3.226]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.177]) with mapi id 14.02.0328.011; Thu, 8 Aug 2013 08:56:57 -0700 From: "Duke, Martin" To: "sratliff@cisco.com" , "teco@inf-net.nl" Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26p/9YLRK8LOUWRHN38Psx765mKLTgAgAAU9ICAAAXtAIABLS7w Date: Thu, 8 Aug 2013 15:56:56 +0000 Message-ID: <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 15:57:14 -0000 I'm a little concerned about flow control messages working over TCP. We're = looking at an application that emphasizes low latency and are trying to ope= rate with very small queues at the radio; to do this without creating idle = time at the radio requires tight bounds on when credit grants get to the ro= uter. In general a non-greedy application (like DLEP's control plane) running TCP= over an Ethernet connection should not trigger many packet losses, but I'm= concerned about both occasional loss-related delays, and the Nagle algorit= hm raising the bound on control message delivery time. Might we separate flow control from the TCP stream, just like Peer Discover= y messages? Martin Duke Boeing Research & Technology -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff (sratliff) Sent: Wednesday, August 07, 2013 10:46 AM To: Teco Boot Cc: manet@ietf.org List Subject: Re: [manet] DLEP and TCP Completely agree with what Henning and Teco have said. I'd like to elaborat= e just a tad on one of Teco's points: On Aug 7, 2013, at 10:24 AM, Teco Boot wrote: > To add a few other mentioned arguments: > - link between peers is a high speed link, there shouldn't be much > difference in delay DLEP runs *only* on the local radio-to-router link. It is *not* specified t= o run over the RF. At least in the networks I've deployed, the local radio= -to-router link is typically a FastEthernet. Secondly, we're only talking a= bout the DLEP control traffic itself - there's no impact to data traffic ov= er the RF. Given all of that, plus picking up the guaranteed delivery, movi= ng to TCP doesn't seem onerous. Regards, Stan > - many radio's have already a TCP stack (e.g. web server for > management) > - shortening the DLEP draft by reusing what is already available makes > a lot of sense > - where DLEP is used on non-IP links (e.g. within a chassis), there has t= o be a reliable transport protocol. standardization of such is not a task f= or IETF. the draft will say: if there is an IP link, TCP is used for reliab= le transport with peer. > > Of course peer discovery is not TCP. > > Teco > > Op 7 aug. 2013, om 15:09 heeft Henning Rogge het volgende geschreven: > >> On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: >>> Dear list, >>> >>> At the Berlin meeting, we were informed that DLEP is going to switch >>> to using TCP as transport. Using TCP for transporting what is >>> real-time data is a little bit suprising to me. >>> >>> Could I most humbly request the rationale for switching DLEP to TCP? >> >> Part of the rationale was that DLEP is transporting only database change= s between radio and router. If any of this changes has been lost, the datab= ase of the router might stay inconsistent for quite some time. >> >> The current DLEP draft has the concept of acknowledgements between radio= and router to make sure that this doesn't happen, but acknowledgements pre= sent us with a new problem. >> >> Either we create a "stop and wait" style protocol which waits for each a= cknowledgement before sending the next data packet, or we need to add seque= nce numbers to data and acknowledgement. >> >> Because DLEP updates might not make sense in the wrong order, we would h= ave to start reproducing parts of TCP with buffering, windows and acks. >> >> Switching to a reliable transport protocol solves most of this problems. >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Thu Aug 8 09:44:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF2121F9F1C for ; Thu, 8 Aug 2013 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sxxqW8Dsyu4 for ; Thu, 8 Aug 2013 09:44:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4B88421F9F00 for ; Thu, 8 Aug 2013 09:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6129; q=dns/txt; s=iport; t=1375980273; x=1377189873; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9ZFKU4/noEhERvl3N17AnBUk828QkPRPzMqyvus58kk=; b=k6rBkhnngwY9RMXin+Y9HXogtiDTwC98di0zReLB2fcuFjOJie+/HROG m71G0Vo9dp7SniASjFLk/9Rjnuym+vh2WyNu/RKGje84myIsbgM9y2rFP QEp6d3nAUO+4Lto1ZSikWYcDS2EOJS+itkq+6KEyNJ4pl6sWOXUfW5/ws 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKHKA1KtJV2b/2dsb2JhbABbgwY1UL5IgRoWdIIkAQEBAwEBAQFrBAcFBwQCAQgRBAEBAQodBycLFAkIAgQOBQiIAgYMuRuPaAIGKwcGgxR0A5QKlSaDGIIq X-IronPort-AV: E=Sophos;i="4.89,840,1367971200"; d="scan'208";a="245115393" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 08 Aug 2013 16:44:28 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r78GiS9Z023027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 16:44:28 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 11:44:26 -0500 From: "Stan Ratliff (sratliff)" To: "Duke, Martin" Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26ihqeH9HMbGU+WXMCShCPLOJmKC7EAgAAU9ICAAAXyAIABpi0AgAANR4A= Date: Thu, 8 Aug 2013 16:44:27 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> In-Reply-To: <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 16:44:40 -0000 Martin,=20 On Aug 8, 2013, at 11:56 AM, "Duke, Martin" wrote: > I'm a little concerned about flow control messages working over TCP. We'r= e looking at an application that emphasizes low latency and are trying to o= perate with very small queues at the radio; to do this without creating idl= e time at the radio requires tight bounds on when credit grants get to the = router. >=20 > In general a non-greedy application (like DLEP's control plane) running T= CP over an Ethernet connection should not trigger many packet losses, but I= 'm concerned about both occasional loss-related delays, and the Nagle algor= ithm raising the bound on control message delivery time. Good point. >=20 > Might we separate flow control from the TCP stream, just like Peer Discov= ery messages? That's an alternative. What I was envisioning, though, was a fairly simple = implementation: For discovery, a radio would send a packet to a local subne= t multicast address (assigned by IANA, with both an IPv4 and a v6 assignmen= t), effectively saying "Hello! Any DLEPers out there?" The router would res= pond with a UDP packet saying "I'm here. Connect to me using address 'blah'= , port number 'foo''" (with the port number having an IANA assigned default= ). And that would be the end of the "UDP-ness"=85 ;-) Everything else could= then shift over to the TCP-based connection. Simple, straightforward, some= thing that even I could code=85 ;-)=20 What you're suggesting does increase the complexity by a bunch. Specificall= y, I worry about whether there's an *implied* sequencing of messages betwee= n the TCP and UDP-based messages in that mode. For example, let's say the r= adio sends a Neighbor Update for a link metric update, and some flow contro= l messages on the UDP socket. Is there a relationship between the two? And = would the router have to implicitly (or explicitly) figure out what the rel= ationship is?=20 Your concern is making me wonder whether moving to TCP is really a good thi= ng=85 or if we should just "bite the bullet", and fix the UDP issues. I'm s= tarting to think that a "stop and wait" type of protocol really wouldn't be= exceedingly nasty for something as light as DLEP=85 Regards, Stan >=20 > Martin Duke > Boeing Research & Technology >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Stan Ratliff (sratliff) > Sent: Wednesday, August 07, 2013 10:46 AM > To: Teco Boot > Cc: manet@ietf.org List > Subject: Re: [manet] DLEP and TCP >=20 > Completely agree with what Henning and Teco have said. I'd like to elabor= ate just a tad on one of Teco's points: >=20 > On Aug 7, 2013, at 10:24 AM, Teco Boot wrote: >=20 >> To add a few other mentioned arguments: >> - link between peers is a high speed link, there shouldn't be much >> difference in delay >=20 > DLEP runs *only* on the local radio-to-router link. It is *not* specified= to run over the RF. At least in the networks I've deployed, the local rad= io-to-router link is typically a FastEthernet. Secondly, we're only talking= about the DLEP control traffic itself - there's no impact to data traffic = over the RF. Given all of that, plus picking up the guaranteed delivery, mo= ving to TCP doesn't seem onerous. >=20 > Regards, > Stan >=20 >=20 >> - many radio's have already a TCP stack (e.g. web server for >> management) >> - shortening the DLEP draft by reusing what is already available makes >> a lot of sense >> - where DLEP is used on non-IP links (e.g. within a chassis), there has = to be a reliable transport protocol. standardization of such is not a task = for IETF. the draft will say: if there is an IP link, TCP is used for relia= ble transport with peer. >>=20 >> Of course peer discovery is not TCP. >>=20 >> Teco >>=20 >> Op 7 aug. 2013, om 15:09 heeft Henning Rogge het volgende geschreven: >>=20 >>> On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: >>>> Dear list, >>>>=20 >>>> At the Berlin meeting, we were informed that DLEP is going to switch >>>> to using TCP as transport. Using TCP for transporting what is >>>> real-time data is a little bit suprising to me. >>>>=20 >>>> Could I most humbly request the rationale for switching DLEP to TCP? >>>=20 >>> Part of the rationale was that DLEP is transporting only database chang= es between radio and router. If any of this changes has been lost, the data= base of the router might stay inconsistent for quite some time. >>>=20 >>> The current DLEP draft has the concept of acknowledgements between radi= o and router to make sure that this doesn't happen, but acknowledgements pr= esent us with a new problem. >>>=20 >>> Either we create a "stop and wait" style protocol which waits for each = acknowledgement before sending the next data packet, or we need to add sequ= ence numbers to data and acknowledgement. >>>=20 >>> Because DLEP updates might not make sense in the wrong order, we would = have to start reproducing parts of TCP with buffering, windows and acks. >>>=20 >>> Switching to a reliable transport protocol solves most of this problems= . >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, >>> Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From buddenbergr@gmail.com Thu Aug 8 09:59:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DCB11E8149 for ; Thu, 8 Aug 2013 09:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEQSgz8sGssH for ; Thu, 8 Aug 2013 09:59:48 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A949321F9FF3 for ; Thu, 8 Aug 2013 09:59:48 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so3739944pad.2 for ; Thu, 08 Aug 2013 09:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=tpgNAAt+JV4NvkBjX1cstbe9qX/8sEeskz2x2ljYujo=; b=YJpD/QGk72zYaXwqZbLwcCh7yGdt2uep69AjIO/TsVBS+lyGeJuOqvtypp1nHogm79 izRpY/Iq6M9P6owh+ZDxhTvoP2OvootZxJGq9PEgV3Z1HjAOm9a+Hcy3kB6W459iYcqZ v1A57M4FpLw9LRg7EonYbL4/svCLjWpaRnLhmj3bM7oIvjzfSeOeM2RGVOEuINvj8HRX hDomZ4MAlGe1HlH9XmX1RSQm9vYI4E/UbaUo9lCnZHgbej1pDnJIoHmAFihSI5WHkF6z VabtfpDdeSy+UjbDmj10fuBmsJ37HKU0smt9VWt8fvpTTwE8G879VlOCYvzlOlEJVzpJ LjHw== X-Received: by 10.68.245.165 with SMTP id xp5mr7169055pbc.66.1375981188358; Thu, 08 Aug 2013 09:59:48 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id eq5sm15247248pbc.15.2013.08.08.09.59.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 08 Aug 2013 09:59:47 -0700 (PDT) Message-ID: <1375981185.17678.202.camel@localhost> From: Rex Buddenberg To: "Stan Ratliff (sratliff)" Date: Thu, 08 Aug 2013 09:59:45 -0700 In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 16:59:49 -0000 Consider running the DLEP traffic over NORM??? On Thu, 2013-08-08 at 16:44 +0000, Stan Ratliff (sratliff) wrote: > Martin, > > On Aug 8, 2013, at 11:56 AM, "Duke, Martin" wrote: > > > I'm a little concerned about flow control messages working over TCP. We're looking at an application that emphasizes low latency and are trying to operate with very small queues at the radio; to do this without creating idle time at the radio requires tight bounds on when credit grants get to the router. > > > > In general a non-greedy application (like DLEP's control plane) running TCP over an Ethernet connection should not trigger many packet losses, but I'm concerned about both occasional loss-related delays, and the Nagle algorithm raising the bound on control message delivery time. > > Good point. > > > > > Might we separate flow control from the TCP stream, just like Peer Discovery messages? > > That's an alternative. What I was envisioning, though, was a fairly simple implementation: For discovery, a radio would send a packet to a local subnet multicast address (assigned by IANA, with both an IPv4 and a v6 assignment), effectively saying "Hello! Any DLEPers out there?" The router would respond with a UDP packet saying "I'm here. Connect to me using address 'blah', port number 'foo''" (with the port number having an IANA assigned default). And that would be the end of the "UDP-ness"… ;-) Everything else could then shift over to the TCP-based connection. Simple, straightforward, something that even I could code… ;-) > > What you're suggesting does increase the complexity by a bunch. Specifically, I worry about whether there's an *implied* sequencing of messages between the TCP and UDP-based messages in that mode. For example, let's say the radio sends a Neighbor Update for a link metric update, and some flow control messages on the UDP socket. Is there a relationship between the two? And would the router have to implicitly (or explicitly) figure out what the relationship is? > > Your concern is making me wonder whether moving to TCP is really a good thing… or if we should just "bite the bullet", and fix the UDP issues. I'm starting to think that a "stop and wait" type of protocol really wouldn't be exceedingly nasty for something as light as DLEP… > > Regards, > Stan > > > > > > Martin Duke > > Boeing Research & Technology > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff (sratliff) > > Sent: Wednesday, August 07, 2013 10:46 AM > > To: Teco Boot > > Cc: manet@ietf.org List > > Subject: Re: [manet] DLEP and TCP > > > > Completely agree with what Henning and Teco have said. I'd like to elaborate just a tad on one of Teco's points: > > > > On Aug 7, 2013, at 10:24 AM, Teco Boot wrote: > > > >> To add a few other mentioned arguments: > >> - link between peers is a high speed link, there shouldn't be much > >> difference in delay > > > > DLEP runs *only* on the local radio-to-router link. It is *not* specified to run over the RF. At least in the networks I've deployed, the local radio-to-router link is typically a FastEthernet. Secondly, we're only talking about the DLEP control traffic itself - there's no impact to data traffic over the RF. Given all of that, plus picking up the guaranteed delivery, moving to TCP doesn't seem onerous. > > > > Regards, > > Stan > > > > > >> - many radio's have already a TCP stack (e.g. web server for > >> management) > >> - shortening the DLEP draft by reusing what is already available makes > >> a lot of sense > >> - where DLEP is used on non-IP links (e.g. within a chassis), there has to be a reliable transport protocol. standardization of such is not a task for IETF. the draft will say: if there is an IP link, TCP is used for reliable transport with peer. > >> > >> Of course peer discovery is not TCP. > >> > >> Teco > >> > >> Op 7 aug. 2013, om 15:09 heeft Henning Rogge het volgende geschreven: > >> > >>> On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: > >>>> Dear list, > >>>> > >>>> At the Berlin meeting, we were informed that DLEP is going to switch > >>>> to using TCP as transport. Using TCP for transporting what is > >>>> real-time data is a little bit suprising to me. > >>>> > >>>> Could I most humbly request the rationale for switching DLEP to TCP? > >>> > >>> Part of the rationale was that DLEP is transporting only database changes between radio and router. If any of this changes has been lost, the database of the router might stay inconsistent for quite some time. > >>> > >>> The current DLEP draft has the concept of acknowledgements between radio and router to make sure that this doesn't happen, but acknowledgements present us with a new problem. > >>> > >>> Either we create a "stop and wait" style protocol which waits for each acknowledgement before sending the next data packet, or we need to add sequence numbers to data and acknowledgement. > >>> > >>> Because DLEP updates might not make sense in the wrong order, we would have to start reproducing parts of TCP with buffering, windows and acks. > >>> > >>> Switching to a reliable transport protocol solves most of this problems. > >>> > >>> Henning Rogge > >>> > >>> -- > >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für > >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >>> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, > >>> Germany > >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Thu Aug 8 11:16:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B0721F99D0 for ; Thu, 8 Aug 2013 11:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx6IR6-NXIiP for ; Thu, 8 Aug 2013 11:16:36 -0700 (PDT) Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id 07D0F21F9AE3 for ; Thu, 8 Aug 2013 11:16:34 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id n15so1613139ead.30 for ; Thu, 08 Aug 2013 11:16:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=8oqBhOrEp6oRqRJxj9ji3xp8SFBXDEukqDBuplfZpto=; b=fYAiiXQvqQsNGqHDrv7C4wT5LkwjX5u3OkJb+NbCRbkzgn+enskGEaDeJ5TadI1TdI sGFJUJ9Eov81hK4Nse6wt0LxwsSwldIsqDZ36SYh+1IjXyjKVdtS6omM6MK2NM3BKh8e a6zW79ib7z4DOwKw8d+i6xrULZJEeQv9tOKfIFxNwUgiqqLPVKgZ1KdjQo3+Llfv5mhz +AchPjqMOYV94iVkPgcbo+ZpePRA7GbthRJNfqCoUID2WARCXMJ0xwV/O3QiBdBJi2Gu hKSGr4z/c8lCgz5Sm5r8PxoRduQOkxKKKdveunfK/5S78h28W30yyvScwI8+ZcJZbWbs z8fg== X-Gm-Message-State: ALoCoQnplYqsmhxDGu7LflaMMrRV1ZNqZEdJHdkVPkQORogzX74c94Qq8cQuBjGLwVOSIP//+PMy X-Received: by 10.15.99.133 with SMTP id bl5mr9343187eeb.92.1375985792859; Thu, 08 Aug 2013 11:16:32 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id n48sm21293384eeg.17.2013.08.08.11.16.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 11:16:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <1375981185.17678.202.camel@localhost> Date: Thu, 8 Aug 2013 20:16:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> To: Rex Buddenberg X-Mailer: Apple Mail (2.1508) Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:16:41 -0000 Of we build flow control over UDP, how to handle loss? Why would it = perform better than TCP? Doesn't the push option enforce direct delivery? Nagle can be turned = off, I think. My personal opinion is to move flow control out of the base spec. I = would run queuing and congestion management on the bottleneck, which is = the radio. We discussed DLEP for (groups of) diffserv codepoints. Would be needed = for flow control also. Or having a queue depth on radio near to zero, = but this brings the requirement for near to zero delay flow control. Teco Op 8 aug. 2013, om 18:59 heeft Rex Buddenberg = het volgende geschreven: > Consider running the DLEP traffic over NORM??? >=20 >=20 >=20 > On Thu, 2013-08-08 at 16:44 +0000, Stan Ratliff (sratliff) wrote: >> Martin,=20 >>=20 >> On Aug 8, 2013, at 11:56 AM, "Duke, Martin" = wrote: >>=20 >>> I'm a little concerned about flow control messages working over TCP. = We're looking at an application that emphasizes low latency and are = trying to operate with very small queues at the radio; to do this = without creating idle time at the radio requires tight bounds on when = credit grants get to the router. >>>=20 >>> In general a non-greedy application (like DLEP's control plane) = running TCP over an Ethernet connection should not trigger many packet = losses, but I'm concerned about both occasional loss-related delays, and = the Nagle algorithm raising the bound on control message delivery time. >>=20 >> Good point. >>=20 >>>=20 >>> Might we separate flow control from the TCP stream, just like Peer = Discovery messages? >>=20 >> That's an alternative. What I was envisioning, though, was a fairly = simple implementation: For discovery, a radio would send a packet to a = local subnet multicast address (assigned by IANA, with both an IPv4 and = a v6 assignment), effectively saying "Hello! Any DLEPers out there?" The = router would respond with a UDP packet saying "I'm here. Connect to me = using address 'blah', port number 'foo''" (with the port number having = an IANA assigned default). And that would be the end of the "UDP-ness"=85 = ;-) Everything else could then shift over to the TCP-based connection. = Simple, straightforward, something that even I could code=85 ;-)=20 >>=20 >> What you're suggesting does increase the complexity by a bunch. = Specifically, I worry about whether there's an *implied* sequencing of = messages between the TCP and UDP-based messages in that mode. For = example, let's say the radio sends a Neighbor Update for a link metric = update, and some flow control messages on the UDP socket. Is there a = relationship between the two? And would the router have to implicitly = (or explicitly) figure out what the relationship is?=20 >>=20 >> Your concern is making me wonder whether moving to TCP is really a = good thing=85 or if we should just "bite the bullet", and fix the UDP = issues. I'm starting to think that a "stop and wait" type of protocol = really wouldn't be exceedingly nasty for something as light as DLEP=85 >>=20 >> Regards, >> Stan >>=20 >>=20 >>>=20 >>> Martin Duke >>> Boeing Research & Technology >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Stan Ratliff (sratliff) >>> Sent: Wednesday, August 07, 2013 10:46 AM >>> To: Teco Boot >>> Cc: manet@ietf.org List >>> Subject: Re: [manet] DLEP and TCP >>>=20 >>> Completely agree with what Henning and Teco have said. I'd like to = elaborate just a tad on one of Teco's points: >>>=20 >>> On Aug 7, 2013, at 10:24 AM, Teco Boot wrote: >>>=20 >>>> To add a few other mentioned arguments: >>>> - link between peers is a high speed link, there shouldn't be much >>>> difference in delay >>>=20 >>> DLEP runs *only* on the local radio-to-router link. It is *not* = specified to run over the RF. At least in the networks I've deployed, = the local radio-to-router link is typically a FastEthernet. Secondly, = we're only talking about the DLEP control traffic itself - there's no = impact to data traffic over the RF. Given all of that, plus picking up = the guaranteed delivery, moving to TCP doesn't seem onerous. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>> - many radio's have already a TCP stack (e.g. web server for >>>> management) >>>> - shortening the DLEP draft by reusing what is already available = makes >>>> a lot of sense >>>> - where DLEP is used on non-IP links (e.g. within a chassis), there = has to be a reliable transport protocol. standardization of such is not = a task for IETF. the draft will say: if there is an IP link, TCP is used = for reliable transport with peer. >>>>=20 >>>> Of course peer discovery is not TCP. >>>>=20 >>>> Teco >>>>=20 >>>> Op 7 aug. 2013, om 15:09 heeft Henning Rogge = het volgende geschreven: >>>>=20 >>>>> On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: >>>>>> Dear list, >>>>>>=20 >>>>>> At the Berlin meeting, we were informed that DLEP is going to = switch >>>>>> to using TCP as transport. Using TCP for transporting what is >>>>>> real-time data is a little bit suprising to me. >>>>>>=20 >>>>>> Could I most humbly request the rationale for switching DLEP to = TCP? >>>>>=20 >>>>> Part of the rationale was that DLEP is transporting only database = changes between radio and router. If any of this changes has been lost, = the database of the router might stay inconsistent for quite some time. >>>>>=20 >>>>> The current DLEP draft has the concept of acknowledgements between = radio and router to make sure that this doesn't happen, but = acknowledgements present us with a new problem. >>>>>=20 >>>>> Either we create a "stop and wait" style protocol which waits for = each acknowledgement before sending the next data packet, or we need to = add sequence numbers to data and acknowledgement. >>>>>=20 >>>>> Because DLEP updates might not make sense in the wrong order, we = would have to start reproducing parts of TCP with buffering, windows and = acks. >>>>>=20 >>>>> Switching to a reliable transport protocol solves most of this = problems. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> -- >>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 = Wachtberg, >>>>> Germany >>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From prvs=1932933c47=veytser@ll.mit.edu Thu Aug 8 14:10:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466E011E822C for ; Thu, 8 Aug 2013 14:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvE94hAhfreE for ; Thu, 8 Aug 2013 14:10:28 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 735EA21E805A for ; Thu, 8 Aug 2013 14:10:28 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r78LAFOK012046; Thu, 8 Aug 2013 17:10:26 -0400 From: "Veytser, Leonid - 0665 - MITLL" To: "Dearlove, Christopher (UK)" Date: Thu, 8 Aug 2013 17:06:11 -0400 Thread-Topic: OLSR [RFC 3626] Routing Table Calculation Clarification Thread-Index: Ac6Ue0VOjCIRrUlRQueXHbOyb+rNBA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_C30D6BE0-F996-4C65-9374-7E6172BD0BAD"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-08_06:2013-08-08, 2013-08-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308080197 Cc: "manet@ietf.org" Subject: Re: [manet] OLSR [RFC 3626] Routing Table Calculation Clarification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:10:33 -0000 --Apple-Mail=_C30D6BE0-F996-4C65-9374-7E6172BD0BAD Content-Type: multipart/alternative; boundary="Apple-Mail=_060DE74B-0005-4691-9066-644D718421F1" --Apple-Mail=_060DE74B-0005-4691-9066-644D718421F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Actually, except for the first hop (and the second hop when using two = hop information from HELLO messages) routes use links from MPR to MPR = selector, as advertised in TC messages. That is true, except for since only MRPs are generating the TC messages = only the MPR selectors that are also MPRs themselves will be chosen by = the routing selection in a path for destinations beyond two hops. The = destination node, of course, does not have to be an MPR but merely an = MPR selector of the previous hop. In other words, the path selected by = OLSR for destinations more than two hops away may go through non-MPR = nodes 1 and 2 hops away and the final destination node may not be an MPR = but all the intermediary nodes along the selected path will aways be = MPRs. Therefore it seems more logical to me to prefer routing through MPRs as = tie breakers in other situations as well (i.e. in Section 3.2). Lenny > =20 > [The easiest way to see this must be so, in my experience, is to = consider the final hop of a route, where the destination is a leaf node, = reachable only from one other node.] > =20 > The h =3D 1 case tries to make similar behaviour a preference for the = first hop. > =20 > (Flooding goes from MPR selector to MPR, however.) > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Veytser, Leonid - 0665 - MITLL > Sent: 02 August 2013 20:59 > To: manet@ietf.org > Subject: [manet] OLSR [RFC 3626] Routing Table Calculation = Clarification > =20 > Hello, > =20 > I am seeking clarification of Section 3.2 of the OLSR RFC 3626 that = describes the tie breaking rules, when performing routing table = calculation, for picking the next hop when more than one are available: > =20 > 3.2 Several topology entries may be used to select a next = hop > R_next_addr for reaching the node R_dest_addr. When = h=3D1, > ties should be broken such that nodes with highest > willingness and MPR selectors are preferred as next = hop. > =20 > Did the authors mean using MPRs as tie breakers as preferred next hop? = If not, and MPR selectors is what should be used to break the ties what = is the rationale? I can understand preferring MPRs as next hop since = OLSR tries to route through the MPRs but don't understand why an MPR = selector would be a preferred next hop? > =20 > Thanks in advance, > =20 > Lenny > =20 > --------------------------------------------------------------- > Leonid Veytser > MIT Lincoln Laboratory > Advanced Networking and Applications Group > (781)981-1395 > =20 > =20 > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 --Apple-Mail=_060DE74B-0005-4691-9066-644D718421F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Actually, except for the = first hop (and the second hop when using two hop information from HELLO = messages) routes use links from MPR to MPR selector, as advertised in TC = messages.
 
[The easiest way to see = this must be so, in my experience, is to consider the final hop of a = route, where the destination is a leaf node, reachable only from one = other node.]
 
The h =3D 1 case tries to make similar = behaviour a preference for the first hop.
 
(Flooding goes from MPR = selector to MPR, however.)
 
Christopher Dearlove
Senior Principal = Engineer, Communications Group
Communications, Networks and Image = Analysis Capability
BAE Systems Advanced Technology Centre
West = Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 = 1245 242194 |  Fax: +44 1245 = 242124
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf Of Veytser, Leonid - 0665 = - MITLL
Sent: 02 August 2013 = 20:59
To: manet@ietf.org
Subject: [manet] OLSR [RFC 3626] = Routing Table Calculation = Clarification
 
I am = seeking clarification of Section 3.2 of the OLSR RFC 3626 that describes = the tie breaking rules, when performing routing table calculation, for = picking the next hop when more than one are = available:
Did = the authors mean using MPRs as tie breakers as preferred next hop? If = not, and MPR selectors is what should be used to break the ties what is = the rationale? I can understand preferring MPRs as next hop since OLSR = tries to route through the MPRs but don't understand why an MPR selector = would be a preferred next hop?
 
Thanks in advance,
 
Lenny
 
 
 
X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E55E11E8247 for ; Thu, 8 Aug 2013 14:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO8aQOHmqr+H for ; Thu, 8 Aug 2013 14:53:50 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.144]) by ietfa.amsl.com (Postfix) with ESMTP id 2C07711E8245 for ; Thu, 8 Aug 2013 14:52:41 -0700 (PDT) Received: from [195.245.231.67:36557] by server-8.bemta-5.messagelabs.com id 52/A4-15847-72314025; Thu, 08 Aug 2013 21:52:39 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-3.tower-82.messagelabs.com!1375998758!31789907!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4027 invoked from network); 8 Aug 2013 21:52:38 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-3.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 8 Aug 2013 21:52:38 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Thu, 8 Aug 2013 22:52:38 +0100 From: To: , Date: Thu, 8 Aug 2013 22:52:37 +0100 Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26ihqeH9HMbGU+WXMCShCPLOJmKC7EAgAAU9ICAAAXyAIABpi0AgAANR4D///8ZgA== Message-ID: <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet@ietf.org Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:53:54 -0000 TCP's congestion control and backoff will limit transmission on a loaded li= nk - when you would need something like DLEP the most. TCP timers (delayed = acks and system timers, not just Nagle) are counterproductive here. The only thing I can think of worse than running DLEP over TCP would be som= e sort of http/xml/soap thing, with layers of unneeded cruft. Or possibly = DLEP over PPPoE. Have you considered that? Lloyd Wood http://sat-net.com/L.Wood/router-modem-integration ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Stan Rat= liff (sratliff) [sratliff@cisco.com] Sent: 08 August 2013 17:44 To: Duke, Martin Cc: manet@ietf.org Subject: Re: [manet] DLEP and TCP Martin, On Aug 8, 2013, at 11:56 AM, "Duke, Martin" wrote: > I'm a little concerned about flow control messages working over TCP. We'r= e looking at an application that emphasizes low latency and are trying to o= perate with very small queues at the radio; to do this without creating idl= e time at the radio requires tight bounds on when credit grants get to the = router. > > In general a non-greedy application (like DLEP's control plane) running T= CP over an Ethernet connection should not trigger many packet losses, but I= 'm concerned about both occasional loss-related delays, and the Nagle algor= ithm raising the bound on control message delivery time. Good point. > > Might we separate flow control from the TCP stream, just like Peer Discov= ery messages? That's an alternative. What I was envisioning, though, was a fairly simple = implementation: For discovery, a radio would send a packet to a local subne= t multicast address (assigned by IANA, with both an IPv4 and a v6 assignmen= t), effectively saying "Hello! Any DLEPers out there?" The router would res= pond with a UDP packet saying "I'm here. Connect to me using address 'blah'= , port number 'foo''" (with the port number having an IANA assigned default= ). And that would be the end of the "UDP-ness"=85 ;-) Everything else could= then shift over to the TCP-based connection. Simple, straightforward, some= thing that even I could code=85 ;-) What you're suggesting does increase the complexity by a bunch. Specificall= y, I worry about whether there's an *implied* sequencing of messages betwee= n the TCP and UDP-based messages in that mode. For example, let's say the r= adio sends a Neighbor Update for a link metric update, and some flow contro= l messages on the UDP socket. Is there a relationship between the two? And = would the router have to implicitly (or explicitly) figure out what the rel= ationship is? Your concern is making me wonder whether moving to TCP is really a good thi= ng=85 or if we should just "bite the bullet", and fix the UDP issues. I'm s= tarting to think that a "stop and wait" type of protocol really wouldn't be= exceedingly nasty for something as light as DLEP=85 Regards, Stan > > Martin Duke > Boeing Research & Technology > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Stan Ratliff (sratliff) > Sent: Wednesday, August 07, 2013 10:46 AM > To: Teco Boot > Cc: manet@ietf.org List > Subject: Re: [manet] DLEP and TCP > > Completely agree with what Henning and Teco have said. I'd like to elabor= ate just a tad on one of Teco's points: > > On Aug 7, 2013, at 10:24 AM, Teco Boot wrote: > >> To add a few other mentioned arguments: >> - link between peers is a high speed link, there shouldn't be much >> difference in delay > > DLEP runs *only* on the local radio-to-router link. It is *not* specified= to run over the RF. At least in the networks I've deployed, the local rad= io-to-router link is typically a FastEthernet. Secondly, we're only talking= about the DLEP control traffic itself - there's no impact to data traffic = over the RF. Given all of that, plus picking up the guaranteed delivery, mo= ving to TCP doesn't seem onerous. > > Regards, > Stan > > >> - many radio's have already a TCP stack (e.g. web server for >> management) >> - shortening the DLEP draft by reusing what is already available makes >> a lot of sense >> - where DLEP is used on non-IP links (e.g. within a chassis), there has = to be a reliable transport protocol. standardization of such is not a task = for IETF. the draft will say: if there is an IP link, TCP is used for relia= ble transport with peer. >> >> Of course peer discovery is not TCP. >> >> Teco >> >> Op 7 aug. 2013, om 15:09 heeft Henning Rogge het volgende geschreven: >> >>> On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: >>>> Dear list, >>>> >>>> At the Berlin meeting, we were informed that DLEP is going to switch >>>> to using TCP as transport. Using TCP for transporting what is >>>> real-time data is a little bit suprising to me. >>>> >>>> Could I most humbly request the rationale for switching DLEP to TCP? >>> >>> Part of the rationale was that DLEP is transporting only database chang= es between radio and router. If any of this changes has been lost, the data= base of the router might stay inconsistent for quite some time. >>> >>> The current DLEP draft has the concept of acknowledgements between radi= o and router to make sure that this doesn't happen, but acknowledgements pr= esent us with a new problem. >>> >>> Either we create a "stop and wait" style protocol which waits for each = acknowledgement before sending the next data packet, or we need to add sequ= ence numbers to data and acknowledgement. >>> >>> Because DLEP updates might not make sense in the wrong order, we would = have to start reproducing parts of TCP with buffering, windows and acks. >>> >>> Switching to a reliable transport protocol solves most of this problems= . >>> >>> Henning Rogge >>> >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, >>> Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From bebemaster@gmail.com Thu Aug 8 15:05:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CEA21F9B80 for ; Thu, 8 Aug 2013 15:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMpVWO5WXykA for ; Thu, 8 Aug 2013 15:05:32 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A991011E8160 for ; Thu, 8 Aug 2013 15:05:30 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id h10so3660154vbh.34 for ; Thu, 08 Aug 2013 15:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1XvSDn3lYztJeDSNXgCOedyzNH6YxTJASir4gYtYGK4=; b=SRlolCeOjC4uiagAAm6RDbLBnIkKSqLN2/6M4K4nA4WgHWI4NvpFlqwnhKKP3WOJ2n RU9ge9tyQlkyAOj96PV6nlrcgLNiR5ZupfH1Dkw+7CsllRA8fHXHlDmN4IZiuATCk5Ym xNtrnOGA94Ffns0YP7x9iUoZLfO1mIKH9TnrL9Et0ARPFPXJBPx0pA6+kUIFmAWTpcHw 5s/cdxJmP8X9QNjiz0EIdiHpyOm9M/8CUdwHuszHvx1uIiwDHSA61g9cUPjsCvY1VHQZ e/ZuUxCDQt8YkiWNusArYVjcq3pfG/XH30Jk5DfByqpjZZNukhAI/tkR5chZcu7JwdYK SCcg== X-Received: by 10.52.171.111 with SMTP id at15mr3642595vdc.79.1375999529081; Thu, 08 Aug 2013 15:05:29 -0700 (PDT) Received: from [192.168.46.87] ([50.42.34.66]) by mx.google.com with ESMTPSA id aw3sm8580361vdc.2.2013.08.08.15.05.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 15:05:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Justin Dean In-Reply-To: <1375981185.17678.202.camel@localhost> Date: Thu, 8 Aug 2013 18:05:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <68E83A7F-17BA-492A-B8C8-B127BEB9D267@gmail.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> To: Rex Buddenberg X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:05:33 -0000 If dlep is only running radio to router and not going over the air NORM = may provide more control over point to point delay and backoff delay. = Care and direction would have to be given to provide sane settings. = While I think NORM would be a better protocol fit it may needlessly = burden any actual implementation when TCP might work well enough and is = already supported. I do think it is a better fit however. Justin On Aug 8, 2013, at 12:59 PM, Rex Buddenberg wrote: > Consider running the DLEP traffic over NORM??? >=20 >=20 >=20 > On Thu, 2013-08-08 at 16:44 +0000, Stan Ratliff (sratliff) wrote: >> Martin,=20 >>=20 >> On Aug 8, 2013, at 11:56 AM, "Duke, Martin" = wrote: >>=20 >>> I'm a little concerned about flow control messages working over TCP. = We're looking at an application that emphasizes low latency and are = trying to operate with very small queues at the radio; to do this = without creating idle time at the radio requires tight bounds on when = credit grants get to the router. >>>=20 >>> In general a non-greedy application (like DLEP's control plane) = running TCP over an Ethernet connection should not trigger many packet = losses, but I'm concerned about both occasional loss-related delays, and = the Nagle algorithm raising the bound on control message delivery time. >>=20 >> Good point. >>=20 >>>=20 >>> Might we separate flow control from the TCP stream, just like Peer = Discovery messages? >>=20 >> That's an alternative. What I was envisioning, though, was a fairly = simple implementation: For discovery, a radio would send a packet to a = local subnet multicast address (assigned by IANA, with both an IPv4 and = a v6 assignment), effectively saying "Hello! Any DLEPers out there?" The = router would respond with a UDP packet saying "I'm here. Connect to me = using address 'blah', port number 'foo''" (with the port number having = an IANA assigned default). And that would be the end of the "UDP-ness"=85 = ;-) Everything else could then shift over to the TCP-based connection. = Simple, straightforward, something that even I could code=85 ;-)=20 >>=20 >> What you're suggesting does increase the complexity by a bunch. = Specifically, I worry about whether there's an *implied* sequencing of = messages between the TCP and UDP-based messages in that mode. For = example, let's say the radio sends a Neighbor Update for a link metric = update, and some flow control messages on the UDP socket. Is there a = relationship between the two? And would the router have to implicitly = (or explicitly) figure out what the relationship is?=20 >>=20 >> Your concern is making me wonder whether moving to TCP is really a = good thing=85 or if we should just "bite the bullet", and fix the UDP = issues. I'm starting to think that a "stop and wait" type of protocol = really wouldn't be exceedingly nasty for something as light as DLEP=85 >>=20 >> Regards, >> Stan >>=20 >>=20 >>>=20 >>> Martin Duke >>> Boeing Research & Technology >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Stan Ratliff (sratliff) >>> Sent: Wednesday, August 07, 2013 10:46 AM >>> To: Teco Boot >>> Cc: manet@ietf.org List >>> Subject: Re: [manet] DLEP and TCP >>>=20 >>> Completely agree with what Henning and Teco have said. I'd like to = elaborate just a tad on one of Teco's points: >>>=20 >>> On Aug 7, 2013, at 10:24 AM, Teco Boot wrote: >>>=20 >>>> To add a few other mentioned arguments: >>>> - link between peers is a high speed link, there shouldn't be much >>>> difference in delay >>>=20 >>> DLEP runs *only* on the local radio-to-router link. It is *not* = specified to run over the RF. At least in the networks I've deployed, = the local radio-to-router link is typically a FastEthernet. Secondly, = we're only talking about the DLEP control traffic itself - there's no = impact to data traffic over the RF. Given all of that, plus picking up = the guaranteed delivery, moving to TCP doesn't seem onerous. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>> - many radio's have already a TCP stack (e.g. web server for >>>> management) >>>> - shortening the DLEP draft by reusing what is already available = makes >>>> a lot of sense >>>> - where DLEP is used on non-IP links (e.g. within a chassis), there = has to be a reliable transport protocol. standardization of such is not = a task for IETF. the draft will say: if there is an IP link, TCP is used = for reliable transport with peer. >>>>=20 >>>> Of course peer discovery is not TCP. >>>>=20 >>>> Teco >>>>=20 >>>> Op 7 aug. 2013, om 15:09 heeft Henning Rogge = het volgende geschreven: >>>>=20 >>>>> On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: >>>>>> Dear list, >>>>>>=20 >>>>>> At the Berlin meeting, we were informed that DLEP is going to = switch >>>>>> to using TCP as transport. Using TCP for transporting what is >>>>>> real-time data is a little bit suprising to me. >>>>>>=20 >>>>>> Could I most humbly request the rationale for switching DLEP to = TCP? >>>>>=20 >>>>> Part of the rationale was that DLEP is transporting only database = changes between radio and router. If any of this changes has been lost, = the database of the router might stay inconsistent for quite some time. >>>>>=20 >>>>> The current DLEP draft has the concept of acknowledgements between = radio and router to make sure that this doesn't happen, but = acknowledgements present us with a new problem. >>>>>=20 >>>>> Either we create a "stop and wait" style protocol which waits for = each acknowledgement before sending the next data packet, or we need to = add sequence numbers to data and acknowledgement. >>>>>=20 >>>>> Because DLEP updates might not make sense in the wrong order, we = would have to start reproducing parts of TCP with buffering, windows and = acks. >>>>>=20 >>>>> Switching to a reliable transport protocol solves most of this = problems. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> -- >>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 = Wachtberg, >>>>> Germany >>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From housley@vigilsec.com Thu Aug 8 15:10:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE9621E80B6; Thu, 8 Aug 2013 15:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTIdJQUntgfU; Thu, 8 Aug 2013 15:10:19 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6B56F21E8095; Thu, 8 Aug 2013 15:09:46 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 21BC1F2408A; Thu, 8 Aug 2013 18:10:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id dQe-PJ+tLBiS; Thu, 8 Aug 2013 18:09:38 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 98EE8F24089; Thu, 8 Aug 2013 18:10:19 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 8 Aug 2013 18:09:43 -0400 Message-Id: <3140092F-123B-4FD3-A7DF-A61C44C76262@vigilsec.com> To: manet@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Cc: IETF Gen-ART , IESG Subject: [manet] Gen-ART Review of draft-ietf-manet-rfc6622-bis-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:10:24 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-manet-rfc6622-bis-04 Reviewer: Russ Housley Review Date: 2013-06-15 IETF LC End Date: 2013-06-27 IESG Telechat date: 2013-08-15 Summary: The document is ready for publication as a standards track RFC. I reviewed -02 during IETF Last Call, and all of my concerns have been addressed in -04. From teco@inf-net.nl Thu Aug 8 23:05:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C7021F9EA9 for ; Thu, 8 Aug 2013 23:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqBrMfk-1FAe for ; Thu, 8 Aug 2013 23:04:58 -0700 (PDT) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 22BC921F9EA7 for ; Thu, 8 Aug 2013 23:04:53 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id q16so1821616ead.7 for ; Thu, 08 Aug 2013 23:04:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=D6IXSdM15pEwe99rUqMTA4NcX9lzxOhrU3c36oIvJ3Q=; b=DGb6nK94aNSim0wwencDKnafazAIZtiBNL3ez4X/FY4JQF19WT2AL1TB9NcdCH9Wd2 RsQu5hKexzi3CalQrwG8Wck9VXQrP1bEYbSTlDKHAqXq8rkKgX7ZxZ+qZQfCvUNBG1I1 +kUS0OElrvCfc3+eySRDSeDrwx6/YoD26T23LTOcVC8Bhgtzp6zGw0BatGBV7xeI9yMx 9jaXpJDd4svXjXplm4BTrWq3b8mMDDdp7Ird9iyRgo11QB0HWIXVHx320uC2R88nbSTo //DGiTmCwWE6BYvKj1+BRF97YKMsYEoWAZ/rhP7Mj9BReg3v9/TbQLfspYxjPhj1egCJ F6Vg== X-Gm-Message-State: ALoCoQl9UwPq7jFFKeYS6ek98z5gmtxzV/RAOj798vpY89xg6sR1k+ZkFfrtzafpRiX2zm8nNavB X-Received: by 10.14.8.199 with SMTP id 47mr11679326eer.101.1376028292938; Thu, 08 Aug 2013 23:04:52 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id m54sm25688352eex.2.2013.08.08.23.04.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 23:04:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk> Date: Fri, 9 Aug 2013 08:04:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk> To: X-Mailer: Apple Mail (2.1508) Cc: manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 06:05:02 -0000 Sorry, I think your comment is not helpful. The peer link (between router and radio) must not be the bottleneck. = This need to be stated in the draft. If the link was highly loaded, I can imagine TCP works much better than = a bad designed protocol on UDP. Yes, we considered xml/json but decided to stay away from that. DLEP over a VLAN was considered some time ago, see mail archive for = details. This has to do with L2 filters on the modem, for having DLEP = multicast traffic only on the router-modem link and not on the RF link. = Outcome was to stay away from that. Maybe this need more discussions and = more text in the draft. Teco Op 8 aug. 2013, om 23:52 heeft het volgende = geschreven: > TCP's congestion control and backoff will limit transmission on a = loaded link - when you would need something like DLEP the most. TCP = timers (delayed acks and system timers, not just Nagle) are = counterproductive here. >=20 > The only thing I can think of worse than running DLEP over TCP would = be some sort of http/xml/soap thing, with layers of unneeded cruft. Or = possibly DLEP over PPPoE. Have you considered that? >=20 > Lloyd Wood > http://sat-net.com/L.Wood/router-modem-integration >=20 >=20 > ________________________________________ > From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of = Stan Ratliff (sratliff) [sratliff@cisco.com] > Sent: 08 August 2013 17:44 > To: Duke, Martin > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and TCP >=20 > Martin, >=20 > On Aug 8, 2013, at 11:56 AM, "Duke, Martin" = wrote: >=20 >> I'm a little concerned about flow control messages working over TCP. = We're looking at an application that emphasizes low latency and are = trying to operate with very small queues at the radio; to do this = without creating idle time at the radio requires tight bounds on when = credit grants get to the router. >>=20 >> In general a non-greedy application (like DLEP's control plane) = running TCP over an Ethernet connection should not trigger many packet = losses, but I'm concerned about both occasional loss-related delays, and = the Nagle algorithm raising the bound on control message delivery time. >=20 > Good point. >=20 >>=20 >> Might we separate flow control from the TCP stream, just like Peer = Discovery messages? >=20 > That's an alternative. What I was envisioning, though, was a fairly = simple implementation: For discovery, a radio would send a packet to a = local subnet multicast address (assigned by IANA, with both an IPv4 and = a v6 assignment), effectively saying "Hello! Any DLEPers out there?" The = router would respond with a UDP packet saying "I'm here. Connect to me = using address 'blah', port number 'foo''" (with the port number having = an IANA assigned default). And that would be the end of the "UDP-ness"=85 = ;-) Everything else could then shift over to the TCP-based connection. = Simple, straightforward, something that even I could code=85 ;-) >=20 > What you're suggesting does increase the complexity by a bunch. = Specifically, I worry about whether there's an *implied* sequencing of = messages between the TCP and UDP-based messages in that mode. For = example, let's say the radio sends a Neighbor Update for a link metric = update, and some flow control messages on the UDP socket. Is there a = relationship between the two? And would the router have to implicitly = (or explicitly) figure out what the relationship is? >=20 > Your concern is making me wonder whether moving to TCP is really a = good thing=85 or if we should just "bite the bullet", and fix the UDP = issues. I'm starting to think that a "stop and wait" type of protocol = really wouldn't be exceedingly nasty for something as light as DLEP=85 >=20 > Regards, > Stan >=20 >=20 >>=20 >> Martin Duke >> Boeing Research & Technology >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Stan Ratliff (sratliff) >> Sent: Wednesday, August 07, 2013 10:46 AM >> To: Teco Boot >> Cc: manet@ietf.org List >> Subject: Re: [manet] DLEP and TCP >>=20 >> Completely agree with what Henning and Teco have said. I'd like to = elaborate just a tad on one of Teco's points: >>=20 >> On Aug 7, 2013, at 10:24 AM, Teco Boot wrote: >>=20 >>> To add a few other mentioned arguments: >>> - link between peers is a high speed link, there shouldn't be much >>> difference in delay >>=20 >> DLEP runs *only* on the local radio-to-router link. It is *not* = specified to run over the RF. At least in the networks I've deployed, = the local radio-to-router link is typically a FastEthernet. Secondly, = we're only talking about the DLEP control traffic itself - there's no = impact to data traffic over the RF. Given all of that, plus picking up = the guaranteed delivery, moving to TCP doesn't seem onerous. >>=20 >> Regards, >> Stan >>=20 >>=20 >>> - many radio's have already a TCP stack (e.g. web server for >>> management) >>> - shortening the DLEP draft by reusing what is already available = makes >>> a lot of sense >>> - where DLEP is used on non-IP links (e.g. within a chassis), there = has to be a reliable transport protocol. standardization of such is not = a task for IETF. the draft will say: if there is an IP link, TCP is used = for reliable transport with peer. >>>=20 >>> Of course peer discovery is not TCP. >>>=20 >>> Teco >>>=20 >>> Op 7 aug. 2013, om 15:09 heeft Henning Rogge = het volgende geschreven: >>>=20 >>>> On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: >>>>> Dear list, >>>>>=20 >>>>> At the Berlin meeting, we were informed that DLEP is going to = switch >>>>> to using TCP as transport. Using TCP for transporting what is >>>>> real-time data is a little bit suprising to me. >>>>>=20 >>>>> Could I most humbly request the rationale for switching DLEP to = TCP? >>>>=20 >>>> Part of the rationale was that DLEP is transporting only database = changes between radio and router. If any of this changes has been lost, = the database of the router might stay inconsistent for quite some time. >>>>=20 >>>> The current DLEP draft has the concept of acknowledgements between = radio and router to make sure that this doesn't happen, but = acknowledgements present us with a new problem. >>>>=20 >>>> Either we create a "stop and wait" style protocol which waits for = each acknowledgement before sending the next data packet, or we need to = add sequence numbers to data and acknowledgement. >>>>=20 >>>> Because DLEP updates might not make sense in the wrong order, we = would have to start reproducing parts of TCP with buffering, windows and = acks. >>>>=20 >>>> Switching to a reliable transport protocol solves most of this = problems. >>>>=20 >>>> Henning Rogge >>>>=20 >>>> -- >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 = Wachtberg, >>>> Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From l.wood@surrey.ac.uk Thu Aug 8 23:18:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5985B21F9DFA for ; Thu, 8 Aug 2013 23:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWmeLTsU1dmz for ; Thu, 8 Aug 2013 23:18:06 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.144]) by ietfa.amsl.com (Postfix) with ESMTP id 80E3821F9CE2 for ; Thu, 8 Aug 2013 23:18:05 -0700 (PDT) Received: from [85.158.136.51:10765] by server-8.bemta-5.messagelabs.com id 9C/B3-15847-B9984025; Fri, 09 Aug 2013 06:18:03 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-49.messagelabs.com!1376029082!19533012!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5434 invoked from network); 9 Aug 2013 06:18:03 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-12.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 9 Aug 2013 06:18:03 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Fri, 9 Aug 2013 07:18:02 +0100 From: To: Date: Fri, 9 Aug 2013 07:16:12 +0100 Thread-Topic: [manet] DLEP and TCP Thread-Index: Ac6Uxl5vKAskKm6mS5+dYjCSQpkiwgAAZPhn Message-ID: <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 06:18:10 -0000 I think the problem here lies in not knowing how to design protocols on UDP= . Other groups - notably IRTF DTNRG - have had the effective outcome of "comm= unication design is hard, let's just use TCP". Lloyd Wood http://sat-net.com/L.Wood/router-modem-integration ________________________________________ From: Teco Boot [teco@inf-net.nl] Sent: 09 August 2013 07:04 To: Wood L Dr (Electronic Eng) Cc: sratliff@cisco.com; Martin.Duke@boeing.com; manet@ietf.org Subject: Re: [manet] DLEP and TCP Sorry, I think your comment is not helpful. The peer link (between router and radio) must not be the bottleneck. This n= eed to be stated in the draft. If the link was highly loaded, I can imagine TCP works much better than a b= ad designed protocol on UDP. Yes, we considered xml/json but decided to stay away from that. DLEP over a VLAN was considered some time ago, see mail archive for details= . This has to do with L2 filters on the modem, for having DLEP multicast tr= affic only on the router-modem link and not on the RF link. Outcome was to = stay away from that. Maybe this need more discussions and more text in the = draft. Teco Op 8 aug. 2013, om 23:52 heeft het volgende geschreve= n: > TCP's congestion control and backoff will limit transmission on a loaded = link - when you would need something like DLEP the most. TCP timers (delaye= d acks and system timers, not just Nagle) are counterproductive here. > > The only thing I can think of worse than running DLEP over TCP would be s= ome sort of http/xml/soap thing, with layers of unneeded cruft. Or possibly= DLEP over PPPoE. Have you considered that? > > Lloyd Wood > http://sat-net.com/L.Wood/router-modem-integration > > > ________________________________________ > From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Stan R= atliff (sratliff) [sratliff@cisco.com] > Sent: 08 August 2013 17:44 > To: Duke, Martin > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and TCP > > Martin, > > On Aug 8, 2013, at 11:56 AM, "Duke, Martin" wrot= e: > >> I'm a little concerned about flow control messages working over TCP. We'= re looking at an application that emphasizes low latency and are trying to = operate with very small queues at the radio; to do this without creating id= le time at the radio requires tight bounds on when credit grants get to the= router. >> >> In general a non-greedy application (like DLEP's control plane) running = TCP over an Ethernet connection should not trigger many packet losses, but = I'm concerned about both occasional loss-related delays, and the Nagle algo= rithm raising the bound on control message delivery time. > > Good point. > >> >> Might we separate flow control from the TCP stream, just like Peer Disco= very messages? > > That's an alternative. What I was envisioning, though, was a fairly simpl= e implementation: For discovery, a radio would send a packet to a local sub= net multicast address (assigned by IANA, with both an IPv4 and a v6 assignm= ent), effectively saying "Hello! Any DLEPers out there?" The router would r= espond with a UDP packet saying "I'm here. Connect to me using address 'bla= h', port number 'foo''" (with the port number having an IANA assigned defau= lt). And that would be the end of the "UDP-ness"=85 ;-) Everything else cou= ld then shift over to the TCP-based connection. Simple, straightforward, so= mething that even I could code=85 ;-) > > What you're suggesting does increase the complexity by a bunch. Specifica= lly, I worry about whether there's an *implied* sequencing of messages betw= een the TCP and UDP-based messages in that mode. For example, let's say the= radio sends a Neighbor Update for a link metric update, and some flow cont= rol messages on the UDP socket. Is there a relationship between the two? An= d would the router have to implicitly (or explicitly) figure out what the r= elationship is? > > Your concern is making me wonder whether moving to TCP is really a good t= hing=85 or if we should just "bite the bullet", and fix the UDP issues. I'm= starting to think that a "stop and wait" type of protocol really wouldn't = be exceedingly nasty for something as light as DLEP=85 > > Regards, > Stan > > >> >> Martin Duke >> Boeing Research & Technology >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Stan Ratliff (sratliff) >> Sent: Wednesday, August 07, 2013 10:46 AM >> To: Teco Boot >> Cc: manet@ietf.org List >> Subject: Re: [manet] DLEP and TCP >> >> Completely agree with what Henning and Teco have said. I'd like to elabo= rate just a tad on one of Teco's points: >> >> On Aug 7, 2013, at 10:24 AM, Teco Boot wrote: >> >>> To add a few other mentioned arguments: >>> - link between peers is a high speed link, there shouldn't be much >>> difference in delay >> >> DLEP runs *only* on the local radio-to-router link. It is *not* specifie= d to run over the RF. At least in the networks I've deployed, the local ra= dio-to-router link is typically a FastEthernet. Secondly, we're only talkin= g about the DLEP control traffic itself - there's no impact to data traffic= over the RF. Given all of that, plus picking up the guaranteed delivery, m= oving to TCP doesn't seem onerous. >> >> Regards, >> Stan >> >> >>> - many radio's have already a TCP stack (e.g. web server for >>> management) >>> - shortening the DLEP draft by reusing what is already available makes >>> a lot of sense >>> - where DLEP is used on non-IP links (e.g. within a chassis), there has= to be a reliable transport protocol. standardization of such is not a task= for IETF. the draft will say: if there is an IP link, TCP is used for reli= able transport with peer. >>> >>> Of course peer discovery is not TCP. >>> >>> Teco >>> >>> Op 7 aug. 2013, om 15:09 heeft Henning Rogge het volgende geschreven: >>> >>>> On 08/07/2013 03:03 PM, Juliusz Chroboczek wrote: >>>>> Dear list, >>>>> >>>>> At the Berlin meeting, we were informed that DLEP is going to switch >>>>> to using TCP as transport. Using TCP for transporting what is >>>>> real-time data is a little bit suprising to me. >>>>> >>>>> Could I most humbly request the rationale for switching DLEP to TCP? >>>> >>>> Part of the rationale was that DLEP is transporting only database chan= ges between radio and router. If any of this changes has been lost, the dat= abase of the router might stay inconsistent for quite some time. >>>> >>>> The current DLEP draft has the concept of acknowledgements between rad= io and router to make sure that this doesn't happen, but acknowledgements p= resent us with a new problem. >>>> >>>> Either we create a "stop and wait" style protocol which waits for each= acknowledgement before sending the next data packet, or we need to add seq= uence numbers to data and acknowledgement. >>>> >>>> Because DLEP updates might not make sense in the wrong order, we would= have to start reproducing parts of TCP with buffering, windows and acks. >>>> >>>> Switching to a reliable transport protocol solves most of this problem= s. >>>> >>>> Henning Rogge >>>> >>>> -- >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, >>>> Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Thu Aug 8 23:22:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4EE21F9BDB for ; Thu, 8 Aug 2013 23:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysHXwl6W6h9r for ; Thu, 8 Aug 2013 23:22:26 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42721F9E8B for ; Thu, 8 Aug 2013 23:22:25 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V7g5h-0003Hw-0I for manet@ietf.org; Fri, 09 Aug 2013 08:22:25 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7g5g-0000uv-Tv for manet@ietf.org; Fri, 09 Aug 2013 08:22:24 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 9 Aug 2013 08:22:24 +0200 Message-ID: <52048A9F.3000803@fkie.fraunhofer.de> Date: Fri, 9 Aug 2013 08:22:23 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020501070502090009000300" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17651/Fri Aug 9 04:39:09 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ce4bc42c0f341c6b36ab5749a0b03868 Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 06:22:31 -0000 --------------ms020501070502090009000300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 08/09/2013 08:16 AM, l.wood@surrey.ac.uk wrote: > I think the problem here lies in not knowing how to design protocols > on UDP. > > Other groups - notably IRTF DTNRG - have had the effective outcome of > "communication design is hard, let's just use TCP". The point on using something simple is that it is NOT the job of the=20 DLEP protocol to solve the transport problems. If you have a special=20 link between radio and router, just use a better transport protocol.=20 DLEP should not care as long as the transport is reliable. Building our own reliable, low-delay, thinks-about-everything (and maybe = reinvent-the wheel) style transport into DLEP doesn't sound like a good=20 idea. If we want to use UDP, going the "lets use Stop-and-wait" might be the=20 only option that does not greatly increase the complexity of the protocol= =2E Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020501070502090009000300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MDkwNjIyMjNaMCMGCSqGSIb3DQEJBDEWBBS6DP4dL49F20DhQr1Zkr4wxiifoDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAFJfFE68ne/myjC533D0yfyf2i8BGYbSAYaxclXdTWZBk 8C23yW1R0AeVKgTuJahWeJg5pF5f2bbKDGpamz0BFLg3KlkHG24+rXZhRnEfj1wRka88F4u7 dHIabJ3p5PPW83zhIlil4SZIqcz1Q2KBLNSJe/Ua6Vw1OqMcftDL9IkG0t+cYoTiMJ5+Fdde 1OveoNiGnOhhQJ3RShI6yCRDMUefLdauXcBIA3ntUOT9hYiLdouIbaL/+QMlbsf5xHJVe5vx wco82I3RLdl2BeH6I7F+OitQlbyLFXifYxNjfTjV5OIDbsvyb027i5vXVbwrytgzfaIJo5zC QcH4jJIdQQAAAAAAAA== --------------ms020501070502090009000300-- From teco@inf-net.nl Thu Aug 8 23:48:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D9A21F9E4F for ; Thu, 8 Aug 2013 23:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTmZtvZDm5ZX for ; Thu, 8 Aug 2013 23:48:54 -0700 (PDT) Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8394221F9E1D for ; Thu, 8 Aug 2013 23:48:53 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id n15so1869172ead.30 for ; Thu, 08 Aug 2013 23:48:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=GR3djx2qZNCEoONaGTuDG18A/BLU91QZYkArCYtuKA4=; b=VBwRMSfO96XKDOfCK6afBhezlJ+4q/+74E1oyuvhpLW3Ht8TxtN8nyNRLjLQKBQpSR IIL6049OuIZYbyHHOEJQsHXsks0Jxd5jFCcJG/w4zn8l53So9TaYgxKc8cKLzB0O4EEa SiQWFeSO8B1y0DDHgcv/QmFbNSz5R/7ldfjMrA2rK15yKsrGwNKDzAWt/s7Ku2zzsyCY nKLLZN2knGT9pYzBv4tUzS7ekLXySgRm8ADnmDWy6kYuYd2QUtiSTdZlCpoXxUThWQLt PQuNmVydMcHH6YGQhPS8bzJYcI0SPDjrtquOi/LP3rAtia1GTfXWx08GkTaZYrvFFDkk UhqA== X-Gm-Message-State: ALoCoQlYZ+HUkoT329pO2I4WwDntt6Hd+BzRUp+m+D6faHk+ogg5l+zcI9xrIBGyKheVM0dLVnc+ X-Received: by 10.14.22.71 with SMTP id s47mr11654595ees.95.1376030930604; Thu, 08 Aug 2013 23:48:50 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id n48sm25958638eeg.17.2013.08.08.23.48.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 23:48:49 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <52048A9F.3000803@fkie.fraunhofer.de> Date: Fri, 9 Aug 2013 08:48:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> To: "manet@ietf.org List" X-Mailer: Apple Mail (2.1508) Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 06:48:59 -0000 Op 9 aug. 2013, om 08:22 heeft Henning Rogge = het volgende geschreven: > On 08/09/2013 08:16 AM, l.wood@surrey.ac.uk wrote: >> I think the problem here lies in not knowing how to design protocols >> on UDP. >>=20 >> Other groups - notably IRTF DTNRG - have had the effective outcome of >> "communication design is hard, let's just use TCP". >=20 > The point on using something simple is that it is NOT the job of the = DLEP protocol to solve the transport problems. If you have a special = link between radio and router, just use a better transport protocol. = DLEP should not care as long as the transport is reliable. >=20 > Building our own reliable, low-delay, thinks-about-everything (and = maybe reinvent-the wheel) style transport into DLEP doesn't sound like a = good idea. Exactly. Main objective is getting a document out as fast as we can, and more = important, get the protocol running out in the wild. Simple and = straightforward is important here. We shortly discussed SCTP. Could be a better choice as it may somewhat = better support what we need. On the other hand, UDP and TCP stacks are = everywhere and these fit. >=20 > If we want to use UDP, going the "lets use Stop-and-wait" might be the = only option that does not greatly increase the complexity of the = protocol. Yes. TCP can easily beat such. Less work, better performance. That's why we = decided to go for TCP. Teco >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From christopher.dearlove@gmail.com Thu Aug 8 15:10:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC46021E80B6 for ; Thu, 8 Aug 2013 15:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAElsfhPc2PL for ; Thu, 8 Aug 2013 15:10:24 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 16A7421E8094 for ; Thu, 8 Aug 2013 15:09:48 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f14so1089155wiw.9 for ; Thu, 08 Aug 2013 15:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=2R4RtsNMTzCffIhupzcJDVxSqNhU2nVdD3BVd6H+L84=; b=WBw4usXMXh8V1BfRGKtEnuvTvmyJaPnt8ZA0UkcjFfLHN1UhpZoJQMw5SnZH8UonvZ VsHoWYsHXHZBJgZzSrrUUE1/tuEkJvRmtwcd6teHV3EEEvkFer/U3p1cmVG22m2VoSWN BWTlq7oysl7Mp+ytyLW2Vs9t7NTGD9KK0X0/qh30T6hlJ9B9BeaAikxzBM1/8EwpFbpm 06SEHbfnHe6nt42Vxvkc+eDjXKWhPm7ivKCnfKpx6Uq8cnx3Pcgz4hNg1hrshD+tuM3r 1JQkGr2FHFGziNSV46I2LZjr4Aun/aH3y6+4CLKPmW/WWmSC2x17ybhUBHeTjJwfPpoc f5Sg== X-Received: by 10.194.80.137 with SMTP id r9mr4564556wjx.88.1375999787767; Thu, 08 Aug 2013 15:09:47 -0700 (PDT) Received: from [10.37.77.84] (dab-far1-h-17-7.dab.02.net. [82.132.222.171]) by mx.google.com with ESMTPSA id mb7sm16873421wic.10.2013.08.08.15.09.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 15:09:47 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-8FC5D655-3BD3-41C5-A8D8-1AC43519A8C3 Content-Transfer-Encoding: 7bit Message-Id: <140FB187-AF57-4D22-904F-72C66C6048D5@gmail.com> X-Mailer: iPhone Mail (10B350) From: Christopher Dearlove Date: Thu, 8 Aug 2013 23:09:41 +0100 To: "Veytser, Leonid - 0665 - MITLL" X-Mailman-Approved-At: Fri, 09 Aug 2013 00:02:35 -0700 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] OLSR [RFC 3626] Routing Table Calculation Clarification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:26:37 -0000 --Apple-Mail-8FC5D655-3BD3-41C5-A8D8-1AC43519A8C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable You've missed the point that although the normal progress, beyond the first h= op (excluding HELLO-based second hops) is through MPRs, each hop is to an MP= R of the router beyond it, not to the MPR of the router from which the hop i= s made. In other words, the pattern is as I described, and proceeding to you= r own MPR is, except coincidentally, not the usual pattern. (Of course it's doesn't have to be that way, as you can advertise more than M= PR selectors. But that's another case we can ignore for now.) -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 8 Aug 2013, at 22:06, "Veytser, Leonid - 0665 - MITLL" wrote: >> Actually, except for the first hop (and the second hop when using two hop= information from HELLO messages) routes use links from MPR to MPR selector,= as advertised in TC messages. >=20 > That is true, except for since only MRPs are generating the TC messages on= ly the MPR selectors that are also MPRs themselves will be chosen by the rou= ting selection in a path for destinations beyond two hops. The destination n= ode, of course, does not have to be an MPR but merely an MPR selector of the= previous hop. In other words, the path selected by OLSR for destinations mo= re than two hops away may go through non-MPR nodes 1 and 2 hops away and the= final destination node may not be an MPR but all the intermediary nodes alo= ng the selected path will aways be MPRs. >=20 > Therefore it seems more logical to me to prefer routing through MPRs as ti= e breakers in other situations as well (i.e. in Section 3.2). >=20 > Lenny >=20 >> =20 >> [The easiest way to see this must be so, in my experience, is to consider= the final hop of a route, where the destination is a leaf node, reachable o= nly from one other node.] >> =20 >> The h =3D 1 case tries to make similar behaviour a preference for the fir= st hop. >> =20 >> (Flooding goes from MPR selector to MPR, however.) >> =20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> =20 >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Veytser, Leonid - 0665 - MITLL >> Sent: 02 August 2013 20:59 >> To: manet@ietf.org >> Subject: [manet] OLSR [RFC 3626] Routing Table Calculation Clarification >> =20 >> Hello, >> =20 >> I am seeking clarification of Section 3.2 of the OLSR RFC 3626 that descr= ibes the tie breaking rules, when performing routing table calculation, for p= icking the next hop when more than one are available: >> =20 >> 3.2 Several topology entries may be used to select a next hop >> R_next_addr for reaching the node R_dest_addr. When h=3D1= , >> ties should be broken such that nodes with highest >> willingness and MPR selectors are preferred as next hop. >> =20 >> Did the authors mean using MPRs as tie breakers as preferred next hop? If= not, and MPR selectors is what should be used to break the ties what is the= rationale? I can understand preferring MPRs as next hop since OLSR tries to= route through the MPRs but don't understand why an MPR selector would be a p= referred next hop? >> =20 >> Thanks in advance, >> =20 >> Lenny >> =20 >> --------------------------------------------------------------- >> Leonid Veytser >> MIT Lincoln Laboratory >> Advanced Networking and Applications Group >> (781)981-1395 >> =20 >> =20 >> =20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-8FC5D655-3BD3-41C5-A8D8-1AC43519A8C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You've missed the point that although t= he normal progress, beyond the first hop (excluding HELLO-based second hops)= is through MPRs, each hop is to an MPR of the router beyond it, not to the M= PR of the router from which the hop is made. In other words, the pattern is a= s I described, and proceeding to your own MPR is, except coincidentally, not= the usual pattern.

(Of course it's doesn't have to= be that way, as you can advertise more than MPR selectors. But that's anoth= er case we can ignore for now.)

--  
Christopher Dear= love

On 8= Aug 2013, at 22:06, "Veytser, Leonid - 0665 - MITLL" <veytser@ll.mit.edu> wrote:

Actually, except for the fi= rst hop (and the second hop when using two hop information from HELLO messag= es) routes use links from MPR to MPR selector, as advertised in TC messages.=

That is true, except for since only MRPs are gen= erating the TC messages only the MPR selectors that are also MPRs themselves= will be chosen by the routing selection in a path for destinations beyond t= wo hops. The destination node, of course, does not have to be an MPR but mer= ely an MPR selector of the previous hop. In other words, the path selected b= y OLSR for destinations more than two hops away may go through non-MPR n= odes 1 and 2 hops away and the final destination node may not be an MPR but a= ll the intermediary nodes along the selected path will aways be MPRs.
<= div>
Therefore it seems more logical to me to prefer routing t= hrough MPRs as tie breakers in other situations as well (i.e. in Section 3.2= ).

Lenny

 
[The easiest way to see this must be so, in my experie= nce, is to consider the final hop of a route, where the destination is a lea= f node, reachable only from one other node.]
 
The h =3D 1 case tries to make similar behaviour a preference for= the first hop.
 
(Flooding goes fr= om MPR selector to MPR, however.)
 
--
Chris= topher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks= and Image Analysis Capability
BAE Systems Advanced Technology Centre
= West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 12= 45 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com<= /span> | http://www.baesystems.c= om

BAE Systems (Operations) Limited
Re= gistered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Far= nborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 19966= 87
 = ;
From: manet-bou= nces@ietf.org [mailto:manet-bounces@= ietf.org] On Behalf= Of Veytser, Leonid - 0= 665 - MITLL
Sent: 02 August 2013 20:59
To:&n= bsp;manet@ietf.org
Subjec= t: [manet] OLSR [RFC 3= 626] Routing Table Calculation Clarification
 
Hello= ,
 
I am seeking clarification of Section 3.2 of the OL= SR RFC 3626 that describes the tie breaking rules, when performing routing t= able calculation, for picking the next hop when more than one are available:=
 
          3.2  Several=
 topology entries may be used to select a next hop
 =             &nbs= p; R_next_addr for reaching the node R_dest_addr.  When h=3D1,
           =
;    ties should be broken such that nodes with highest<=
/o:p>
          &n=
bsp;    willingness and MPR selectors are preferred as next h=
op.
 
Did the authors mean using MPRs as tie bre= akers as preferred next hop? If not, and MPR selectors is what should be use= d to break the ties what is the rationale? I can understand preferring MPRs a= s next hop since OLSR tries to route through the MPRs but don't understand w= hy an MPR selector would be a preferred next hop?
 
=  
Lenny
 
-------------------------------------------------------------= --
Leonid Veytser
MIT Lincoln Laboratory
Advanced Networking and Ap= plications Group
(781)981-1395
 
 
 

******= **************************************************************
This email= and any attachments are confidential to the intended
recipient and may a= lso be privileged. If you are not the intended
recipient please delete it= from your system and notify the sender.
You should not copy it or use it= for any purpose nor disclose or
distribute its contents to any other per= son.
********************************************************************=


_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet
= --Apple-Mail-8FC5D655-3BD3-41C5-A8D8-1AC43519A8C3-- From l.wood@surrey.ac.uk Fri Aug 9 01:52:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A9E21F9EF5 for ; Fri, 9 Aug 2013 01:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psIEqk47HrZS for ; Fri, 9 Aug 2013 01:52:48 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.148]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4FF21F9E9C for ; Fri, 9 Aug 2013 01:52:43 -0700 (PDT) Received: from [85.158.136.51:42429] by server-12.bemta-5.messagelabs.com id EA/B1-22750-9DDA4025; Fri, 09 Aug 2013 08:52:41 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-49.messagelabs.com!1376038361!27410083!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11261 invoked from network); 9 Aug 2013 08:52:41 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-10.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 9 Aug 2013 08:52:41 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 9 Aug 2013 09:52:41 +0100 From: To: , Date: Fri, 9 Aug 2013 09:52:40 +0100 Thread-Topic: [manet] DLEP and TCP Thread-Index: Ac6UzJR9tFSAb8AXT562DEO/3Tp/YwAEBtYF Message-ID: <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 08:52:52 -0000 Getting a document out fast? RFC4938 was published in June 2007. We have designed and suggested a number of different simple and straightfor= ward non-PPPoE approaches to this problem, detailed at the url below. But NOW you want a document, fast? After over six years? Lloyd Wood http://sat-net.com/L.Wood/router-modem-integration ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Teco Boo= t [teco@inf-net.nl] Sent: 09 August 2013 07:48 To: manet@ietf.org List Subject: Re: [manet] DLEP and TCP Op 9 aug. 2013, om 08:22 heeft Henning Rogge het volgende geschreven: > On 08/09/2013 08:16 AM, l.wood@surrey.ac.uk wrote: >> I think the problem here lies in not knowing how to design protocols >> on UDP. >> >> Other groups - notably IRTF DTNRG - have had the effective outcome of >> "communication design is hard, let's just use TCP". > > The point on using something simple is that it is NOT the job of the DLEP= protocol to solve the transport problems. If you have a special link betwe= en radio and router, just use a better transport protocol. DLEP should not = care as long as the transport is reliable. > > Building our own reliable, low-delay, thinks-about-everything (and maybe = reinvent-the wheel) style transport into DLEP doesn't sound like a good ide= a. Exactly. Main objective is getting a document out as fast as we can, and more import= ant, get the protocol running out in the wild. Simple and straightforward i= s important here. We shortly discussed SCTP. Could be a better choice as it may somewhat bett= er support what we need. On the other hand, UDP and TCP stacks are everywhe= re and these fit. > > If we want to use UDP, going the "lets use Stop-and-wait" might be the on= ly option that does not greatly increase the complexity of the protocol. Yes. TCP can easily beat such. Less work, better performance. That's why we deci= ded to go for TCP. Teco > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Fri Aug 9 02:04:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CC121F9DDE for ; Fri, 9 Aug 2013 02:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIuIvAgxKw6M for ; Fri, 9 Aug 2013 02:04:41 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id DA6AE21F9DD6 for ; Fri, 9 Aug 2013 02:04:40 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V7ich-00062C-Tv for manet@ietf.org; Fri, 09 Aug 2013 11:04:39 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7ich-00029D-RM for manet@ietf.org; Fri, 09 Aug 2013 11:04:39 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 9 Aug 2013 11:04:39 +0200 Message-ID: <5204B0A2.6070707@fkie.fraunhofer.de> Date: Fri, 9 Aug 2013 11:04:34 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080107010508040703000802" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17652/Fri Aug 9 08:11:42 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8a842d9e11f1c1d58316de1cda04e013 Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 09:04:46 -0000 --------------ms080107010508040703000802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 08/09/2013 10:52 AM, l.wood@surrey.ac.uk wrote: > > Getting a document out fast? > > RFC4938 was published in June 2007. So what? RFC4938 does not fit adhoc radio networks. In fact I know quite = a few organizations who got very frustrated about it. > We have designed and suggested a number of different simple and > straightforward non-PPPoE approaches to this problem, detailed at the > url below. It seems you never tried to push them towards a RFC. > But NOW you want a document, fast? After over six years? After less than 3 years... DLEP (version 00) started at the end of 2010. The work on RFC4938 started in 2004 and ended in 2007... which was=20 obsoleted by RFC5578 in 2010. Its still a tool that doesn't fit the problem we are working on in DLEP. I think parts of DLEP could be seen as "lessons learned" from RFC4938=20 and RFC5578. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080107010508040703000802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MDkwOTA0MzhaMCMGCSqGSIb3DQEJBDEWBBS6ERvis/tyTLP77JHiR3dMrs9Q9zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAX+NXqQXue/309RcS0SUwvO8lG9oXuFYo3LDtGrms7vvj YZiJAhnLNGnfeD6JjZUyeAXk7XXDrBtF8DqkYuJrfTorlr3gL7d/R/RYitr64KB1nidesUUf bNDbm1W5rDYkWKFS/t1fmySz910JI2cBR3F7c/wLfdb+UopSkbQpU+5iGckUUVD3sPgdEOpI b73Rlg03NYnn7EH6W9TMyT54IqcO36LhPFP5dTKMR3Pce/Bike8bfSFcmBWnst4BL4IZsdqg SS9DJDsRKJeg9x4VVymyoIY4tjceQU5F/AY7tRbPyE+ZwMhTucDUMSOlPEzQ5OCDENRr7IE1 EtNt48GLXAAAAAAAAA== --------------ms080107010508040703000802-- From l.wood@surrey.ac.uk Fri Aug 9 02:40:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E121F9E7E for ; Fri, 9 Aug 2013 02:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pc1e-KLnxks for ; Fri, 9 Aug 2013 02:40:18 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.171]) by ietfa.amsl.com (Postfix) with ESMTP id 846E621F9DDE for ; Fri, 9 Aug 2013 02:40:17 -0700 (PDT) Received: from [195.245.230.131:40229] by server-11.bemta-3.messagelabs.com id 75/6C-32192-FF8B4025; Fri, 09 Aug 2013 09:40:15 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-9.tower-78.messagelabs.com!1376041214!24511372!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17656 invoked from network); 9 Aug 2013 09:40:15 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-9.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 9 Aug 2013 09:40:15 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 9 Aug 2013 10:40:14 +0100 From: To: , Date: Fri, 9 Aug 2013 10:40:13 +0100 Thread-Topic: [manet] DLEP and TCP Thread-Index: Ac6U34j+s661WhNDQ8C8g6SpIv0E3QAA+10l Message-ID: <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> In-Reply-To: <5204B0A2.6070707@fkie.fraunhofer.de> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 09:40:28 -0000 That organisations became frustrated with RFC4938 does not surprise me, des= pite the political weight behind it. DLEP adapted the PPPOE mechanisms and metrics as much as possible; it is th= e heir to that, and the chosen design, again with poliical weight. If you d= on't like it, throw it out. But political weight will make DLEP the chosen = solution, whatever DLEP looks like. Feel free to suggest alternatives, and = to test that political weight. Good luck! Lloyd Wood http://sat-net.com/L.Wood/router-modem-integration ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Henning = Rogge [henning.rogge@fkie.fraunhofer.de] Sent: 09 August 2013 10:04 To: manet@ietf.org Subject: Re: [manet] DLEP and TCP On 08/09/2013 10:52 AM, l.wood@surrey.ac.uk wrote: > > Getting a document out fast? > > RFC4938 was published in June 2007. So what? RFC4938 does not fit adhoc radio networks. In fact I know quite a few organizations who got very frustrated about it. > We have designed and suggested a number of different simple and > straightforward non-PPPoE approaches to this problem, detailed at the > url below. It seems you never tried to push them towards a RFC. > But NOW you want a document, fast? After over six years? After less than 3 years... DLEP (version 00) started at the end of 2010. The work on RFC4938 started in 2004 and ended in 2007... which was obsoleted by RFC5578 in 2010. Its still a tool that doesn't fit the problem we are working on in DLEP. I think parts of DLEP could be seen as "lessons learned" from RFC4938 and RFC5578. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From henning.rogge@fkie.fraunhofer.de Fri Aug 9 03:25:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D8A21F9F34 for ; Fri, 9 Aug 2013 03:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tssFTMyDQ5HQ for ; Fri, 9 Aug 2013 03:25:48 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A2ACD21F9DD5 for ; Fri, 9 Aug 2013 03:25:47 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V7jt7-0007XX-U1 for manet@ietf.org; Fri, 09 Aug 2013 12:25:41 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7jt7-0002nZ-RS for manet@ietf.org; Fri, 09 Aug 2013 12:25:41 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 9 Aug 2013 12:25:41 +0200 Message-ID: <5204C39D.1040402@fkie.fraunhofer.de> Date: Fri, 9 Aug 2013 12:25:33 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090507060102070800050703" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17652/Fri Aug 9 08:11:42 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 00b54f98fe2f0cea78af7465bd8f318d Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 10:25:53 -0000 --------------ms090507060102070800050703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 08/09/2013 11:40 AM, l.wood@surrey.ac.uk wrote: > That organisations became frustrated with RFC4938 does not surprise > me, despite the political weight behind it. > > DLEP adapted the PPPOE mechanisms One of the best things DLEP does is to get RID OF the PPPoE mechanisms.=20 Its neither end-to-end nor point-to-point. > and metrics as much as possible; I disagree again. DLEP is similar but we spent quite a bit of discussion = and work to fix a lot of issues with the metrics of RFC4938. > it is the heir to that, and the chosen design, again with poliical > weight. If you don't like it, throw it out. But political weight will > make DLEP the chosen solution, whatever DLEP looks like. Feel free to > suggest alternatives, and to test that political weight. Good luck! I think DLEP already was pushed away from the RFC4938-like encoding and=20 protocol to a much better solution. Which is enough evidence for me that = there is quite a bit of working group input moving the protocol. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090507060102070800050703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MDkxMDI1MzdaMCMGCSqGSIb3DQEJBDEWBBQeMQZ6cWcbm5KlARyvYANqo624EzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAieUwAU3YIhRAiIQfhfVA65pFWhw8E1mZ5XrbM6payfZ/ ZoJc3UwRTZn19E2NzTK8y7+K2G1VyERTD4MVzjOHfkNOhencPVA4PjX7C9md0x2f5a6c1Ips bq+IsczMpflHiidnAnFxM1VtpjsDgtVba+CPeJfzF12xsJthrxwv1lKGj3t3UiEKyLAY2Gkn nptu0pHj5G9HBtyBVV3D1/KWqzqdraP23+FQ2fX5RTfxIxIgFujf/ADD4ykBKTP5yt1oWEBq dypsF0B8hSqyMvwXglJ9BbTPyJfpKglSuWLtNSKIh3OIEoUw83Uh9XKWTuujiEkGulJ/SEMr np4Vk38EzwAAAAAAAA== --------------ms090507060102070800050703-- From sratliff@cisco.com Fri Aug 9 07:31:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8470111E80D2 for ; Fri, 9 Aug 2013 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxN1MqXHdHmR for ; Fri, 9 Aug 2013 07:31:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B1E8521E8051 for ; Fri, 9 Aug 2013 07:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2935; q=dns/txt; s=iport; t=1376058667; x=1377268267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TAr8MdTC6rVZzGa13tuBk4ONP2/CJnnAexoZnMiHVUA=; b=JyNY1wYjJQyd4AipYW9nFZNuOUYIrdwTueQoTzSJpmWlMrGVQuUn8o3T SXhwQUnEPqRjNFy9bvUlQKZggCC753tdckE4LClk0cnbhIyL/CAs428z9 IcouP0567IhFmyOC9UsCx2JiN2NgZ0kj4fnQEcGHwumJoin0oxNE9CkGh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAEL8BFKtJXHB/2dsb2JhbABbgwY1UL5SgRkWdIIkAQEBAwEBAQFrCwULAgEIGAodBycLFBECBA4FCBOHbwYMuRSPaAIxB4MadAOIc6A9gxiCKg X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="245275166" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 09 Aug 2013 14:31:07 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r79EV6FB002438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 14:31:06 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 09:31:06 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26ihqeH9HMbGU+WXMCShCPLOJmKC7EAgAAU9ICAAAXyAIABpi0AgAANR4D///8ZgIAA4IiAgAADLACAAAG6gIAAB2IAgAAimwCAAANTAIAACfaAgAAMq4CAAESagA== Date: Fri, 9 Aug 2013 14:31:05 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> In-Reply-To: <5204C39D.1040402@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <424EE02213B3354EBC1BB11B9F0D3F5D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:31:28 -0000 OK, so we've still got Martin's concerns in front of us:=20 (Inclusion from Martin.Duke@boeing.com): I'm a little concerned about flow control messages working over TCP. We're = looking at an application that emphasizes low latency and are trying to ope= rate with very small queues at the radio; to do this without creating idle = time at the radio requires tight bounds on when credit grants get to the ro= uter. In general a non-greedy application (like DLEP's control plane) running TCP= over an Ethernet connection should not trigger many packet losses, but I'm= concerned about both occasional loss-related delays, and the Nagle algorit= hm raising the bound on control message delivery time. Might we separate flow control from the TCP stream, just like Peer Discover= y messages? (end of inclusion) As I've mentioned on several occasions, I'm adamantly opposed to removing t= he flow control from the "base" DLEP spec. Removing flow control from the b= ase spec doesn't "fix" the problem, either - at least to me, that's just "k= icking the can down the road". There's a valid concern here that TCP algori= thms, and/or congestion on the router/radio link, could really muck things = up.=20 Alternatives? Regards, Stan =20 On Aug 9, 2013, at 6:25 AM, Henning Rogge wrote: > On 08/09/2013 11:40 AM, l.wood@surrey.ac.uk wrote: >> That organisations became frustrated with RFC4938 does not surprise >> me, despite the political weight behind it. >>=20 >> DLEP adapted the PPPOE mechanisms >=20 > One of the best things DLEP does is to get RID OF the PPPoE mechanisms. I= ts neither end-to-end nor point-to-point. >=20 > > and metrics as much as possible; >=20 > I disagree again. DLEP is similar but we spent quite a bit of discussion = and work to fix a lot of issues with the metrics of RFC4938. >=20 > > it is the heir to that, and the chosen design, again with poliical >> weight. If you don't like it, throw it out. But political weight will >> make DLEP the chosen solution, whatever DLEP looks like. Feel free to >> suggest alternatives, and to test that political weight. Good luck! >=20 > I think DLEP already was pushed away from the RFC4938-like encoding and p= rotocol to a much better solution. Which is enough evidence for me that the= re is quite a bit of working group input moving the protocol. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Fri Aug 9 07:45:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BDA21E8083 for ; Fri, 9 Aug 2013 07:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM8UTlaxyste for ; Fri, 9 Aug 2013 07:45:00 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0113A21F9F3D for ; Fri, 9 Aug 2013 07:44:34 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cl20so933240qab.9 for ; Fri, 09 Aug 2013 07:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+4P/nTj76/0LRgOwmXeRNTw7PQFTgTlC9UGOIAznLtk=; b=u2YjP1CuJ9XguqR2Zjk+M59W6MOduLvCpbJ0At+QZ+pJjFddx58Md3pDxIjQcRC4TW yVxURDjrZpQtqNB98drIt/a2ZdV81xp3XdvAa4RrCWO7XBk8sP957G11ep/hEmShs5Ns ILrLXBMUWLJdFLEUx6UB2CocYNn+I5gfzcU0Je241pEi6qb0pYog3JwaI7jSsCH407tR zCiIBCKUHDTeHfYS1IvJcqEr6c4QWr6Gz5AiZ6xKJL/QKn9AZZWOYpBW9+P117MmP3nq sEhQDUoWQnot23xnYYOf4/oTUemj677t3xZCqU0ZuV9aqcTj+OllWRUyi6oVlmVz5m8f y8Tw== X-Received: by 10.224.45.69 with SMTP id d5mr11440665qaf.108.1376059474330; Fri, 09 Aug 2013 07:44:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.164.198 with HTTP; Fri, 9 Aug 2013 07:44:13 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk> <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Fri, 9 Aug 2013 16:44:13 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:45:01 -0000 On Fri, Aug 9, 2013 at 4:31 PM, Stan Ratliff (sratliff) wrote: > As I've mentioned on several occasions, I'm adamantly opposed to removing= the flow control from the "base" DLEP spec. Removing flow control from the= base spec doesn't "fix" the problem, either - at least to me, that's just = "kicking the can down the road". There's a valid concern here that TCP algo= rithms, and/or congestion on the router/radio link, could really muck thing= s up. Would DLEP flow control work on a congested router/radio link with UDP? I am not sure about this. As soon as we get a delay or even packet loss on this link, we will get very strange effects anyways. In addition to this I don't think we could get much congestion if the router is doing DLEP based flow control, as long as the router/radio link is faster than the radio. Henning Rogge --=20 We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From teco@inf-net.nl Fri Aug 9 07:47:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F3721F9BDB for ; Fri, 9 Aug 2013 07:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZTLVgT9aOWf for ; Fri, 9 Aug 2013 07:47:12 -0700 (PDT) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id C454521E8084 for ; Fri, 9 Aug 2013 07:46:12 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id m14so2063599eaj.6 for ; Fri, 09 Aug 2013 07:46:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QfnT7Yz/XXvXcuTjRFTAm0/mDeRVS25Cze3tdVr7zTE=; b=EjSvyY0v40OP0gj2HySOOVZxb/V4Ax9wpS3GX2flCnNhKA6OipFNMkKCAMqa3fV4ki zDatY7jpR+EYB+l9JUtB2Xd6xVYAGWuUxXs8HBbhzo6hOuY6WmY0ITbD5JH2UFK7wy0c /z26AoJRE/rMGTD0XFANgR/2q2xb/iBuYzhbi+MuDT6AYT2g1aYWWKh73RRroUZDu26B V933fUl+LlqvuZAZlXIImgTo2in0MQKJuPc+j2tMI4ujW2w4PmYEJCOvBWcxTgMnHOF0 HC4DbPqrGNTNDLNUMQq56hCzyWAXtseUKHlarJq2ASMS2ZLfs+Q9vVLVe4bZC3eLiMAS Qetw== X-Gm-Message-State: ALoCoQl7PH57NLmqHLiKyoODZjIM86E/fxLW1OTCdwrvAtYHe4yLFRCRnRAd+9J0ga+nTWgJ1eWK X-Received: by 10.15.83.2 with SMTP id b2mr13748182eez.28.1376059571855; Fri, 09 Aug 2013 07:46:11 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id p5sm29256147eeg.5.2013.08.09.07.46.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 07:46:11 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> Date: Fri, 9 Aug 2013 16:46:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1508) Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:47:29 -0000 Stan, How would it work better with UDP, especially in those cases where TCP = introduces some jitter? Before this is made clear, my concerns are on UDP, not TCP. Teco Op 9 aug. 2013, om 16:31 heeft Stan Ratliff (sratliff) = het volgende geschreven: > OK, so we've still got Martin's concerns in front of us:=20 >=20 > (Inclusion from Martin.Duke@boeing.com): > I'm a little concerned about flow control messages working over TCP. = We're looking at an application that emphasizes low latency and are = trying to operate with very small queues at the radio; to do this = without creating idle time at the radio requires tight bounds on when = credit grants get to the router. >=20 > In general a non-greedy application (like DLEP's control plane) = running TCP over an Ethernet connection should not trigger many packet = losses, but I'm concerned about both occasional loss-related delays, and = the Nagle algorithm raising the bound on control message delivery time. >=20 > Might we separate flow control from the TCP stream, just like Peer = Discovery messages? > (end of inclusion) >=20 > As I've mentioned on several occasions, I'm adamantly opposed to = removing the flow control from the "base" DLEP spec. Removing flow = control from the base spec doesn't "fix" the problem, either - at least = to me, that's just "kicking the can down the road". There's a valid = concern here that TCP algorithms, and/or congestion on the router/radio = link, could really muck things up.=20 >=20 > Alternatives? >=20 > Regards, > Stan >=20 > On Aug 9, 2013, at 6:25 AM, Henning Rogge = wrote: >=20 >> On 08/09/2013 11:40 AM, l.wood@surrey.ac.uk wrote: >>> That organisations became frustrated with RFC4938 does not surprise >>> me, despite the political weight behind it. >>>=20 >>> DLEP adapted the PPPOE mechanisms >>=20 >> One of the best things DLEP does is to get RID OF the PPPoE = mechanisms. Its neither end-to-end nor point-to-point. >>=20 >>> and metrics as much as possible; >>=20 >> I disagree again. DLEP is similar but we spent quite a bit of = discussion and work to fix a lot of issues with the metrics of RFC4938. >>=20 >>> it is the heir to that, and the chosen design, again with poliical >>> weight. If you don't like it, throw it out. But political weight = will >>> make DLEP the chosen solution, whatever DLEP looks like. Feel free = to >>> suggest alternatives, and to test that political weight. Good luck! >>=20 >> I think DLEP already was pushed away from the RFC4938-like encoding = and protocol to a much better solution. Which is enough evidence for me = that there is quite a bit of working group input moving the protocol. >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Fri Aug 9 08:06:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E393B21E812D for ; Fri, 9 Aug 2013 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMsi0Q-NQo0Y for ; Fri, 9 Aug 2013 08:06:20 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 246F921E80B8 for ; Fri, 9 Aug 2013 08:01:02 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e53so2188092eek.27 for ; Fri, 09 Aug 2013 08:01:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QUHInB65jY05zmXoSakDpL1SFadbwB8va6AakL6/Z3M=; b=RNlZ3eY0DMnkMHHd6jU6vt+XkELi9KCNMI6XQBVc6fXNN4C44jTdPxa3nFVkXZt2x6 toxdeIhTVZkNHDAoYWYlg2CdGRRWr71SYpy/XSF1lzvcpoM0HG9rxjEuMHWhpfQISdTs 6eXsaUkg23wbAjsQvlLmATAsyhB59ejsKTZcppraiZrOkEu/TD8sFi8aABqWKSp3K3VQ uWI9codz2RJ0HhBFP74nCTUeUYOGFvQafqEkY7qdeBy9ajelkMXdmeVGE5FMhm3oKTMp 4U3EGp3n0zMIoQD0GKZuehqRlOxMRdaE+XrdH9OKO7zH+8DNJ89uUh0DNxK+9l3t8Al8 vGFA== X-Gm-Message-State: ALoCoQkhYLHhhZizMrDIC2SFu7va9FK5BKEBnIspLlsUpYGVlOafm4jDQfDjswe5O5a2Y2NYCPXY X-Received: by 10.15.33.74 with SMTP id b50mr1121972eev.140.1376060462092; Fri, 09 Aug 2013 08:01:02 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id bp43sm29361797eeb.4.2013.08.09.08.01.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 08:01:01 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Fri, 9 Aug 2013 17:00:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <992CEFD2-08C2-4D7E-914E-59AE3E9E0737@inf-net.nl> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1508) Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:06:25 -0000 Just took few more minutes to verify what would happen with DLEP flow = control on top of UDP, with "congestion on the router/radio link" or = "occasional loss-related delays". More concerns on using UDP... Teco Op 9 aug. 2013, om 16:46 heeft Teco Boot het volgende = geschreven: > Stan, >=20 > How would it work better with UDP, especially in those cases where TCP = introduces some jitter? > Before this is made clear, my concerns are on UDP, not TCP. >=20 > Teco >=20 > Op 9 aug. 2013, om 16:31 heeft Stan Ratliff (sratliff) = het volgende geschreven: >=20 >> OK, so we've still got Martin's concerns in front of us:=20 >>=20 >> (Inclusion from Martin.Duke@boeing.com): >> I'm a little concerned about flow control messages working over TCP. = We're looking at an application that emphasizes low latency and are = trying to operate with very small queues at the radio; to do this = without creating idle time at the radio requires tight bounds on when = credit grants get to the router. >>=20 >> In general a non-greedy application (like DLEP's control plane) = running TCP over an Ethernet connection should not trigger many packet = losses, but I'm concerned about both occasional loss-related delays, and = the Nagle algorithm raising the bound on control message delivery time. >>=20 >> Might we separate flow control from the TCP stream, just like Peer = Discovery messages? >> (end of inclusion) >>=20 >> As I've mentioned on several occasions, I'm adamantly opposed to = removing the flow control from the "base" DLEP spec. Removing flow = control from the base spec doesn't "fix" the problem, either - at least = to me, that's just "kicking the can down the road". There's a valid = concern here that TCP algorithms, and/or congestion on the router/radio = link, could really muck things up.=20 >>=20 >> Alternatives? >>=20 >> Regards, >> Stan >>=20 >> On Aug 9, 2013, at 6:25 AM, Henning Rogge = wrote: >>=20 >>> On 08/09/2013 11:40 AM, l.wood@surrey.ac.uk wrote: >>>> That organisations became frustrated with RFC4938 does not surprise >>>> me, despite the political weight behind it. >>>>=20 >>>> DLEP adapted the PPPOE mechanisms >>>=20 >>> One of the best things DLEP does is to get RID OF the PPPoE = mechanisms. Its neither end-to-end nor point-to-point. >>>=20 >>>> and metrics as much as possible; >>>=20 >>> I disagree again. DLEP is similar but we spent quite a bit of = discussion and work to fix a lot of issues with the metrics of RFC4938. >>>=20 >>>> it is the heir to that, and the chosen design, again with poliical >>>> weight. If you don't like it, throw it out. But political weight = will >>>> make DLEP the chosen solution, whatever DLEP looks like. Feel free = to >>>> suggest alternatives, and to test that political weight. Good luck! >>>=20 >>> I think DLEP already was pushed away from the RFC4938-like encoding = and protocol to a much better solution. Which is enough evidence for me = that there is quite a bit of working group input moving the protocol. >>>=20 >>> Henning Rogge >>>=20 >>> --=20 >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Fri Aug 9 08:32:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7353C21F9ABB for ; Fri, 9 Aug 2013 08:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oetKe46yS5Cv for ; Fri, 9 Aug 2013 08:32:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2A68721F9DED for ; Fri, 9 Aug 2013 08:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4552; q=dns/txt; s=iport; t=1376061971; x=1377271571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y8ce37Mcww7d2UycG93wnfpud5vEbYSKCDF+eVFZjfk=; b=KXAnee6Ma9WvhndH0njj3HI6Utj39++Sn9oAa5eckHn9D6XNt8XiU+EF r/+D/PIw3uadkZkG/Id+V3m56pt67hYNCmIk7udeirhhmxhgTxTmCQRNm Ny+IeyV/LrgFIRHSQV1KagZcuiYLZUa9mArsunAHJomIetR4U/f2BqRca Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAF0JBVKtJV2Z/2dsb2JhbABbgwY1UL5TgRoWdIIkAQEBAwEBAQFrCwULAgEIGAoLBAIMBycLFBECBA4FCBOHbwYMuRePaAIxBwodAoJxdAOpMIMYgUweQA X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="245463408" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 09 Aug 2013 15:26:04 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r79FQ4vQ028799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 15:26:04 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 10:26:04 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26ihqeH9HMbGU+WXMCShCPLOJmKC7EAgAAU9ICAAAXyAIABpi0AgAANR4D///8ZgIAA4IiAgAADLACAAAG6gIAAB2IAgAAimwCAAANTAIAACfaAgAAMq4CAAESagIAABDOAgAAEJYCAAAcDgA== Date: Fri, 9 Aug 2013 15:26:03 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EF1A8@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> <992CEFD2-08C2-4D7E-914E-59AE3E9E0737@inf-net.nl> In-Reply-To: <992CEFD2-08C2-4D7E-914E-59AE3E9E0737@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4DA6E4EF88872C40B4E17D9C8923F057@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:32:59 -0000 Teco,=20 On Aug 9, 2013, at 11:00 AM, Teco Boot wrote: > Just took few more minutes to verify what would happen with DLEP flow con= trol on top of UDP, with "congestion on the router/radio link" or "occasion= al loss-related delays". > More concerns on using UDP=85 >=20 Can you elaborate? For example, what did you do to verify, and what are the= additional concerns? To be honest, I don't really understand your statemen= t "How would it work better with UDP, especially in those cases where TCP i= ntrudes some jitter?" I think TCP-induced jitter is one of the problems. Wi= th UDP, the packet goes. Maybe it gets dropped, and the protocol has to acc= ount for that, but it goes. It doesn't get buffered for some "unknown to th= e application" amount of time.=20 Regards, Stan > Teco >=20 >=20 > Op 9 aug. 2013, om 16:46 heeft Teco Boot het volgende g= eschreven: >=20 >> Stan, >>=20 >> How would it work better with UDP, especially in those cases where TCP i= ntroduces some jitter? >> Before this is made clear, my concerns are on UDP, not TCP. >>=20 >> Teco >>=20 >> Op 9 aug. 2013, om 16:31 heeft Stan Ratliff (sratliff) het volgende geschreven: >>=20 >>> OK, so we've still got Martin's concerns in front of us:=20 >>>=20 >>> (Inclusion from Martin.Duke@boeing.com): >>> I'm a little concerned about flow control messages working over TCP. We= 're looking at an application that emphasizes low latency and are trying to= operate with very small queues at the radio; to do this without creating i= dle time at the radio requires tight bounds on when credit grants get to th= e router. >>>=20 >>> In general a non-greedy application (like DLEP's control plane) running= TCP over an Ethernet connection should not trigger many packet losses, but= I'm concerned about both occasional loss-related delays, and the Nagle alg= orithm raising the bound on control message delivery time. >>>=20 >>> Might we separate flow control from the TCP stream, just like Peer Disc= overy messages? >>> (end of inclusion) >>>=20 >>> As I've mentioned on several occasions, I'm adamantly opposed to removi= ng the flow control from the "base" DLEP spec. Removing flow control from t= he base spec doesn't "fix" the problem, either - at least to me, that's jus= t "kicking the can down the road". There's a valid concern here that TCP al= gorithms, and/or congestion on the router/radio link, could really muck thi= ngs up.=20 >>>=20 >>> Alternatives? >>>=20 >>> Regards, >>> Stan >>>=20 >>> On Aug 9, 2013, at 6:25 AM, Henning Rogge wrote: >>>=20 >>>> On 08/09/2013 11:40 AM, l.wood@surrey.ac.uk wrote: >>>>> That organisations became frustrated with RFC4938 does not surprise >>>>> me, despite the political weight behind it. >>>>>=20 >>>>> DLEP adapted the PPPOE mechanisms >>>>=20 >>>> One of the best things DLEP does is to get RID OF the PPPoE mechanisms= . Its neither end-to-end nor point-to-point. >>>>=20 >>>>> and metrics as much as possible; >>>>=20 >>>> I disagree again. DLEP is similar but we spent quite a bit of discussi= on and work to fix a lot of issues with the metrics of RFC4938. >>>>=20 >>>>> it is the heir to that, and the chosen design, again with poliical >>>>> weight. If you don't like it, throw it out. But political weight will >>>>> make DLEP the chosen solution, whatever DLEP looks like. Feel free to >>>>> suggest alternatives, and to test that political weight. Good luck! >>>>=20 >>>> I think DLEP already was pushed away from the RFC4938-like encoding an= d protocol to a much better solution. Which is enough evidence for me that = there is quite a bit of working group input moving the protocol. >>>>=20 >>>> Henning Rogge >>>>=20 >>>> --=20 >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) >>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From chris.dearlove@baesystems.com Fri Aug 9 08:44:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E4C21F8438 for ; Fri, 9 Aug 2013 08:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.284 X-Spam-Level: X-Spam-Status: No, score=-9.284 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1+wRzOQvvcK for ; Fri, 9 Aug 2013 08:44:04 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3C27B21F9633 for ; Fri, 9 Aug 2013 08:36:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,846,1367967600"; d="scan'208";a="362984017" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 09 Aug 2013 16:36:30 +0100 X-IronPort-AV: E=Sophos;i="4.89,846,1367967600"; d="scan'208";a="24027615" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 09 Aug 2013 16:36:30 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.90]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 16:36:31 +0100 From: "Dearlove, Christopher (UK)" To: Teco Boot , "manet@ietf.org List" Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26tDWOpIqYY+Uy8o0+IQ/ULg5mJpxwAgAAU84CAAAXuAIABpjIAgAANR4CAAFYagIAAiYeAgAADLACAAAG6gIAAB2EAgACjGKA= Date: Fri, 9 Aug 2013 15:36:30 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:44:08 -0000 " Main objective is getting a document out as fast as we can" Don't let the IESG hear you say that, that's not the accepted main objectiv= e creating RFCs. Correctness is important (or even dominant). -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= eco Boot Sent: 09 August 2013 07:49 To: manet@ietf.org List Subject: Re: [manet] DLEP and TCP ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Op 9 aug. 2013, om 08:22 heeft Henning Rogge het volgende geschreven: > On 08/09/2013 08:16 AM, l.wood@surrey.ac.uk wrote: >> I think the problem here lies in not knowing how to design protocols >> on UDP. >> = >> Other groups - notably IRTF DTNRG - have had the effective outcome of >> "communication design is hard, let's just use TCP". > = > The point on using something simple is that it is NOT the job of the DLEP= protocol to solve the transport problems. If you have a special link betwe= en radio and router, just use a better transport protocol. DLEP should not = care as long as the transport is reliable. > = > Building our own reliable, low-delay, thinks-about-everything (and maybe = reinvent-the wheel) style transport into DLEP doesn't sound like a good ide= a. Exactly. Main objective is getting a document out as fast as we can, and more import= ant, get the protocol running out in the wild. Simple and straightforward i= s important here. We shortly discussed SCTP. Could be a better choice as it may somewhat bett= er support what we need. On the other hand, UDP and TCP stacks are everywhe= re and these fit. > = > If we want to use UDP, going the "lets use Stop-and-wait" might be the on= ly option that does not greatly increase the complexity of the protocol. Yes. TCP can easily beat such. Less work, better performance. That's why we deci= ded to go for TCP. Teco > = > Henning Rogge > = > -- = > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > = > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Fri Aug 9 09:15:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272DE21F9931 for ; Fri, 9 Aug 2013 09:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q81WXTZB9MmA for ; Fri, 9 Aug 2013 09:15:53 -0700 (PDT) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE2721F98AC for ; Fri, 9 Aug 2013 09:07:12 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id o10so2154744eaj.13 for ; Fri, 09 Aug 2013 09:07:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+XQu8yQgTIETEn5fQALu9rjY9QUoM/QeAo006Zbk6U4=; b=Na3ysXVmbOWw2tFwSuoSPZlFDyvYzSUdtACdiENnwg/k5kAG80Ms7DImFp2EwBWPml VJK7MypBDqNZVYYJIKPwm9Nl2ZSxvmzxZyZlRgJPtbNCQET6z54k+uLe1XW5zUruUrSb kvECCHCLJ+ghEAtGL2HdaNQB29sFOm4AS1GtnTKrlwZ+Em83Z80zKP1L9Dn+uCz0VX2Z VRi6PzYj+FrVgc3bulUCflBOETrp7FyBFBahx16wICwVoNlMHkeim17irsR9h9Nc0xTN whjfqAqe4iZ52HcQY51LRvBDJp9BqovTviaPcxYIOYesCYy3itMOy1FN5508EW3CSgwi yHmQ== X-Gm-Message-State: ALoCoQmjBzKbQCtLxF2a0TpWlJllCL1zIP9LRazBvC8QrE1WQvRSfAtHbVc+iTInq1bQFUL2vVcG X-Received: by 10.14.209.4 with SMTP id r4mr9560848eeo.131.1376064431541; Fri, 09 Aug 2013 09:07:11 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id a6sm17878042eei.10.2013.08.09.09.07.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 09:07:10 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Fri, 9 Aug 2013 18:07:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19E85BDD-E99C-4234-9836-837EF3738C5F@inf-net.nl> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1508) Cc: "manet@ietf.org List" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:15:57 -0000 Op 9 aug. 2013, om 17:36 heeft "Dearlove, Christopher (UK)" = het volgende geschreven: > " Main objective is getting a document out as fast as we can" >=20 > Don't let the IESG hear you say that, that's not the accepted main = objective creating RFCs. Correctness is important (or even dominant). I cannot see a contradiction. Teco >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Teco Boot > Sent: 09 August 2013 07:49 > To: manet@ietf.org List > Subject: Re: [manet] DLEP and TCP >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Op 9 aug. 2013, om 08:22 heeft Henning Rogge = het volgende geschreven: >=20 >> On 08/09/2013 08:16 AM, l.wood@surrey.ac.uk wrote: >>> I think the problem here lies in not knowing how to design protocols >>> on UDP. >>>=20 >>> Other groups - notably IRTF DTNRG - have had the effective outcome = of >>> "communication design is hard, let's just use TCP". >>=20 >> The point on using something simple is that it is NOT the job of the = DLEP protocol to solve the transport problems. If you have a special = link between radio and router, just use a better transport protocol. = DLEP should not care as long as the transport is reliable. >>=20 >> Building our own reliable, low-delay, thinks-about-everything (and = maybe reinvent-the wheel) style transport into DLEP doesn't sound like a = good idea. > Exactly. >=20 > Main objective is getting a document out as fast as we can, and more = important, get the protocol running out in the wild. Simple and = straightforward is important here. >=20 > We shortly discussed SCTP. Could be a better choice as it may somewhat = better support what we need. On the other hand, UDP and TCP stacks are = everywhere and these fit. >=20 >>=20 >> If we want to use UDP, going the "lets use Stop-and-wait" might be = the only option that does not greatly increase the complexity of the = protocol. > Yes. > TCP can easily beat such. Less work, better performance. That's why we = decided to go for TCP. >=20 > Teco >=20 >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From teco@inf-net.nl Fri Aug 9 09:25:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32921F9D34 for ; Fri, 9 Aug 2013 09:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPw-CF1s6Oqe for ; Fri, 9 Aug 2013 09:25:48 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id C438121E8064 for ; Fri, 9 Aug 2013 09:17:39 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e53so1815684eek.13 for ; Fri, 09 Aug 2013 09:17:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=dbX8NnYGL1PCIfV3kYzWZswL/sL67f8sEQdsFcolJE8=; b=gUKN4yZ5Ef0u5rRtWgcWUGVE7KZ09LGzEWWwnrs19qMkp48PP1CLTyQBqAe/sWKClQ DZ12erPTNrrHw79GN0BLT+zubzBH32V3Dhig8HS9cNOtrgmeJj/R1+PVR2TLHoR2xXie 38n9K6Tc7cwrU6Do2oVC4qKrFdlX5iTxkOyOVpqZuR1dbZjmJ1zqQ1ts7UDg4PuErkZz SrZJSkeEjQx3oN5nO95aHswGbsg8EuIJP7oESYy2IRLumq65W717UnMzKiI+bMTPfxxw dx3cLhhjQwgYcEHRenA7DLgXyc1b04GlBetiAi+hln2JEjllfUcpDwkDBNnPzXtfVhxh /ETA== X-Gm-Message-State: ALoCoQmBgTQ3nslsmIW8tfE2pIW5Lu9fAp4EmlbGpcNsjEgZvJSem4QWL3M4K1vLtgQ3+DcMBbUl X-Received: by 10.14.22.71 with SMTP id s47mr13831857ees.95.1376065049006; Fri, 09 Aug 2013 09:17:29 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id a4sm29926551eez.0.2013.08.09.09.17.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 09:17:28 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EF1A8@xmb-aln-x03.cisco.com> Date: Fri, 9 Aug 2013 18:17:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> <992CEFD2-08C2-4D7E-914E-59AE3E9E0737@ inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EF1A8@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1508) Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:25:53 -0000 Op 9 aug. 2013, om 17:26 heeft Stan Ratliff (sratliff) = het volgende geschreven: > Teco,=20 >=20 > On Aug 9, 2013, at 11:00 AM, Teco Boot wrote: >=20 >> Just took few more minutes to verify what would happen with DLEP flow = control on top of UDP, with "congestion on the router/radio link" or = "occasional loss-related delays". >> More concerns on using UDP=85 >>=20 >=20 > Can you elaborate? For example, what did you do to verify, and what = are the additional concerns? To be honest, I don't really understand = your statement "How would it work better with UDP, especially in those = cases where TCP intrudes some jitter?" It is a question. > I think TCP-induced jitter is one of the problems. With UDP, the = packet goes. Maybe it gets dropped, and the protocol has to account for = that, but it goes. It doesn't get buffered for some "unknown to the = application" amount of time.=20 I don't get why a TCP packet would not go. If there is congestion, both packets will have queuing delays. With = large congestion, UDP will blow up the link. But as we can easily agree = on, there shouldn't be congestion. It is a MUST. If there is loss, TCP recovers (rather quickly because very small RTT). = If you want to beat TCP in your app, go for it. It wouldn't make the = draft less pages, not to mention lines of code. On the end, I wonder if = you really outperform TCP. Probably you copied TCP (Nagle turned off). Teco >=20 > Regards, > Stan >=20 >=20 >> Teco >>=20 >>=20 >> Op 9 aug. 2013, om 16:46 heeft Teco Boot het = volgende geschreven: >>=20 >>> Stan, >>>=20 >>> How would it work better with UDP, especially in those cases where = TCP introduces some jitter? >>> Before this is made clear, my concerns are on UDP, not TCP. >>>=20 >>> Teco >>>=20 >>> Op 9 aug. 2013, om 16:31 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>>=20 >>>> OK, so we've still got Martin's concerns in front of us:=20 >>>>=20 >>>> (Inclusion from Martin.Duke@boeing.com): >>>> I'm a little concerned about flow control messages working over = TCP. We're looking at an application that emphasizes low latency and are = trying to operate with very small queues at the radio; to do this = without creating idle time at the radio requires tight bounds on when = credit grants get to the router. >>>>=20 >>>> In general a non-greedy application (like DLEP's control plane) = running TCP over an Ethernet connection should not trigger many packet = losses, but I'm concerned about both occasional loss-related delays, and = the Nagle algorithm raising the bound on control message delivery time. >>>>=20 >>>> Might we separate flow control from the TCP stream, just like Peer = Discovery messages? >>>> (end of inclusion) >>>>=20 >>>> As I've mentioned on several occasions, I'm adamantly opposed to = removing the flow control from the "base" DLEP spec. Removing flow = control from the base spec doesn't "fix" the problem, either - at least = to me, that's just "kicking the can down the road". There's a valid = concern here that TCP algorithms, and/or congestion on the router/radio = link, could really muck things up.=20 >>>>=20 >>>> Alternatives? >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>> On Aug 9, 2013, at 6:25 AM, Henning Rogge = wrote: >>>>=20 >>>>> On 08/09/2013 11:40 AM, l.wood@surrey.ac.uk wrote: >>>>>> That organisations became frustrated with RFC4938 does not = surprise >>>>>> me, despite the political weight behind it. >>>>>>=20 >>>>>> DLEP adapted the PPPOE mechanisms >>>>>=20 >>>>> One of the best things DLEP does is to get RID OF the PPPoE = mechanisms. Its neither end-to-end nor point-to-point. >>>>>=20 >>>>>> and metrics as much as possible; >>>>>=20 >>>>> I disagree again. DLEP is similar but we spent quite a bit of = discussion and work to fix a lot of issues with the metrics of RFC4938. >>>>>=20 >>>>>> it is the heir to that, and the chosen design, again with = poliical >>>>>> weight. If you don't like it, throw it out. But political weight = will >>>>>> make DLEP the chosen solution, whatever DLEP looks like. Feel = free to >>>>>> suggest alternatives, and to test that political weight. Good = luck! >>>>>=20 >>>>> I think DLEP already was pushed away from the RFC4938-like = encoding and protocol to a much better solution. Which is enough = evidence for me that there is quite a bit of working group input moving = the protocol. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> --=20 >>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>> Kommunikationssysteme (KOM) >>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 From Martin.Duke@boeing.com Fri Aug 9 13:30:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2816111E8131 for ; Fri, 9 Aug 2013 13:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf7pto2mp+Pk for ; Fri, 9 Aug 2013 13:30:37 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2C921F9D89 for ; Fri, 9 Aug 2013 13:25:01 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r79KP1aV008067 for ; Fri, 9 Aug 2013 13:25:01 -0700 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r79KOxjS008049 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 9 Aug 2013 13:25:00 -0700 Received: from XCH-BLV-103.nw.nos.boeing.com (130.247.25.118) by XCH-NWHT-03.nw.nos.boeing.com (130.247.71.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 9 Aug 2013 13:24:59 -0700 Received: from XCH-BLV-503.nw.nos.boeing.com ([169.254.3.226]) by XCH-BLV-103.nw.nos.boeing.com ([169.254.3.230]) with mapi id 14.02.0328.011; Fri, 9 Aug 2013 13:24:59 -0700 From: "Duke, Martin" To: "teco@inf-net.nl" , "sratliff@cisco.com" Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26p/9YLRK8LOUWRHN38Psx765mKLTgAgAAU9ICAAAXtAIABLS7wgACGS4CAAFYagIAAiYeAgAADLACAAAG6gIAAB2IAgAAimwCAAANTAIAACfaAgAAMq4CAAESagIAABDOA///iU+A= Date: Fri, 9 Aug 2013 20:24:58 +0000 Message-ID: <5A8A5085482DA84995F4E70F5093AB50253E5F@XCH-BLV-503.nw.nos.boeing.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:30:42 -0000 I agree that UDP, in itself, is going to have its own set of problems when = a message is lost, whether of a flow control type or not. If flow control i= s poorly designed I can see cases where flow dries up because the router ha= s zero credits and the first credit award is lost, so we'll have to develop= mechanisms to avoid that case. My concern is the process afterwards. In UDP the next flow control packet w= ill not incur any delay except for whatever it takes for other queued messa= ges and data to go out over the Ethernet interface. In the case of TCP, aft= er the lost message times out we'll be in slow start and later flow control= packets will have to wait for ACKs to come back. As for the Nagle algorithm, I agree that if we specify that DLEP must be in= voked with the TCP_NODELAY option we'll be OK. Martin -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= eco Boot Sent: Friday, August 09, 2013 7:46 AM To: Stan Ratliff Cc: Subject: Re: [manet] DLEP and TCP Stan, How would it work better with UDP, especially in those cases where TCP intr= oduces some jitter? Before this is made clear, my concerns are on UDP, not TCP. Teco Op 9 aug. 2013, om 16:31 heeft Stan Ratliff (sratliff) = het volgende geschreven: > OK, so we've still got Martin's concerns in front of us: > > (Inclusion from Martin.Duke@boeing.com): > I'm a little concerned about flow control messages working over TCP. We'r= e looking at an application that emphasizes low latency and are trying to o= perate with very small queues at the radio; to do this without creating idl= e time at the radio requires tight bounds on when credit grants get to the = router. > > In general a non-greedy application (like DLEP's control plane) running T= CP over an Ethernet connection should not trigger many packet losses, but I= 'm concerned about both occasional loss-related delays, and the Nagle algor= ithm raising the bound on control message delivery time. > > Might we separate flow control from the TCP stream, just like Peer Discov= ery messages? > (end of inclusion) > > As I've mentioned on several occasions, I'm adamantly opposed to removing= the flow control from the "base" DLEP spec. Removing flow control from the= base spec doesn't "fix" the problem, either - at least to me, that's just = "kicking the can down the road". There's a valid concern here that TCP algo= rithms, and/or congestion on the router/radio link, could really muck thing= s up. > > Alternatives? > > Regards, > Stan > > On Aug 9, 2013, at 6:25 AM, Henning Rogge wrote: > >> On 08/09/2013 11:40 AM, l.wood@surrey.ac.uk wrote: >>> That organisations became frustrated with RFC4938 does not surprise >>> me, despite the political weight behind it. >>> >>> DLEP adapted the PPPOE mechanisms >> >> One of the best things DLEP does is to get RID OF the PPPoE mechanisms. = Its neither end-to-end nor point-to-point. >> >>> and metrics as much as possible; >> >> I disagree again. DLEP is similar but we spent quite a bit of discussion= and work to fix a lot of issues with the metrics of RFC4938. >> >>> it is the heir to that, and the chosen design, again with poliical >>> weight. If you don't like it, throw it out. But political weight >>> will make DLEP the chosen solution, whatever DLEP looks like. Feel >>> free to suggest alternatives, and to test that political weight. Good l= uck! >> >> I think DLEP already was pushed away from the RFC4938-like encoding and = protocol to a much better solution. Which is enough evidence for me that th= ere is quite a bit of working group input moving the protocol. >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From l.wood@surrey.ac.uk Fri Aug 9 23:29:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F5321F9ADF for ; Fri, 9 Aug 2013 23:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zChK9IRXa+GM for ; Fri, 9 Aug 2013 23:29:16 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id C81DD21F9A35 for ; Fri, 9 Aug 2013 23:25:29 -0700 (PDT) Received: from [85.158.136.51:31684] by server-17.bemta-5.messagelabs.com id 9C/2B-26639-7DCD5025; Sat, 10 Aug 2013 06:25:27 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-8.tower-49.messagelabs.com!1376115927!22714863!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12271 invoked from network); 10 Aug 2013 06:25:27 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-8.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 10 Aug 2013 06:25:27 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Sat, 10 Aug 2013 07:25:26 +0100 From: To: , Date: Sat, 10 Aug 2013 07:25:27 +0100 Thread-Topic: [manet] DLEP and TCP Thread-Index: Ac6U6uMoMyIwWAXeT/SSm6bm2V11WAApojXM Message-ID: <290E20B455C66743BE178C5C84F124082240607505@EXMB01CMS.surrey.ac.uk> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk>, <5204C39D.1040402@fkie.fraunhofer.de> In-Reply-To: <5204C39D.1040402@fkie.fraunhofer.de> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 06:29:20 -0000 Sorry, I should have phrased that for clarity as ''adapted the mechanisms u= sing PPPoE" - including the 0-100 percentage TLVs (because representing 0-2= 55 in an octet would be difficult.) 0-100, TLVs, metrics inherited from the space the PPPoE solution was design= ed for - DLEP looks remarkably similar to RFC5578 and RFC4938 to me. A gene= ral solution? I have doubts. Lloyd Wood http://sat-net.com/L.Wood/router-modem-integration ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Henning = Rogge [henning.rogge@fkie.fraunhofer.de] Sent: 09 August 2013 11:25 To: manet@ietf.org Subject: Re: [manet] DLEP and TCP On 08/09/2013 11:40 AM, l.wood@surrey.ac.uk wrote: > That organisations became frustrated with RFC4938 does not surprise > me, despite the political weight behind it. > > DLEP adapted the PPPOE mechanisms One of the best things DLEP does is to get RID OF the PPPoE mechanisms. Its neither end-to-end nor point-to-point. > and metrics as much as possible; I disagree again. DLEP is similar but we spent quite a bit of discussion and work to fix a lot of issues with the metrics of RFC4938. > it is the heir to that, and the chosen design, again with poliical > weight. If you don't like it, throw it out. But political weight will > make DLEP the chosen solution, whatever DLEP looks like. Feel free to > suggest alternatives, and to test that political weight. Good luck! I think DLEP already was pushed away from the RFC4938-like encoding and protocol to a much better solution. Which is enough evidence for me that there is quite a bit of working group input moving the protocol. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From teco@inf-net.nl Sat Aug 10 00:14:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A4F11E817A for ; Sat, 10 Aug 2013 00:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9vcY4-VLo4h for ; Sat, 10 Aug 2013 00:14:33 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4C11021F9BEB for ; Sat, 10 Aug 2013 00:08:04 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so2475888eek.24 for ; Sat, 10 Aug 2013 00:08:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=7GmTME8PqnhDnkR7XYQ0kfkz5OGHVF7j9v7up5FaBPU=; b=YvLXNkJ88+hIQtSzVneHEklcrQQHs2aD8E8MrylzMNJdy9iyCCbTwG+2eyFjO3YmWH 3oz7cBKvZvKjvQvtkH5L3G8iHSsldZBUGHRKPrSayc3uCtq6ihbYhFDS/QGHjQN+rFyp 5Mg/oc5w/RYP5RCHyKA47ogbLGLLdyBxASpwiPdStiIvHxniRYe9V4/DWOd+EBj9n/m3 hndXlvF6zYDCMq/egD99NWqA98t2vb5k0hv6dW5/V9Ofmv6qswTQHLt77QXHHtEOgo7F 7e+8Jyg5igjJ4FN9ChKEY1j6o3mksRz832n7EnlnJnqm1KniU/ZgjHMZPy867gHzqnl5 ktWA== X-Gm-Message-State: ALoCoQlckCfmprfni2nkA1cIJAfvOWhZiO8jnsHV7pBppoHRQHu2/nK6qcmew7DWc99uPf20djwl X-Received: by 10.15.22.138 with SMTP id f10mr3889218eeu.126.1376118480920; Sat, 10 Aug 2013 00:08:00 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id j2sm35484894eep.6.2013.08.10.00.07.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Aug 2013 00:08:00 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <5A8A5085482DA84995F4E70F5093AB50253E5F@XCH-BLV-503.nw.nos.boeing.com> Date: Sat, 10 Aug 2013 09:07:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <893C1539-DFDB-4BA1-B442-7BA7BBE0E48A@inf-net.nl> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253E5 F@XCH-BLV-503.nw.nos.boeing.com> To: "Duke, Martin" X-Mailer: Apple Mail (2.1508) Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 07:14:38 -0000 Op 9 aug. 2013, om 22:24 heeft "Duke, Martin" = het volgende geschreven: > I agree that UDP, in itself, is going to have its own set of problems = when a message is lost, whether of a flow control type or not. If flow = control is poorly designed I can see cases where flow dries up because = the router has zero credits and the first credit award is lost, so we'll = have to develop mechanisms to avoid that case. Yes. My question is: does it outperform TCP and is the effort useful? >=20 > My concern is the process afterwards. In UDP the next flow control = packet will not incur any delay except for whatever it takes for other = queued messages and data to go out over the Ethernet interface. In the = case of TCP, after the lost message times out we'll be in slow start and = later flow control packets will have to wait for ACKs to come back. My assumption is that the router-radio link is not congested and even a = one MTU receive window doesn't introduce much of a problem. Again, router-radio link is high speed (e.g. >> 4 times RF link) and RTT = is almost zero (microseconds, not milliseconds). Remember: I don't want to push TCP that hard. I just say: use TCP or = work hard to get it right.=20 Maybe check SCTP. It may better for but is less widely deployed. Teco >=20 > As for the Nagle algorithm, I agree that if we specify that DLEP must = be invoked with the TCP_NODELAY option we'll be OK. >=20 > Martin >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Teco Boot > Sent: Friday, August 09, 2013 7:46 AM > To: Stan Ratliff > Cc: > Subject: Re: [manet] DLEP and TCP >=20 > Stan, >=20 > How would it work better with UDP, especially in those cases where TCP = introduces some jitter? > Before this is made clear, my concerns are on UDP, not TCP. >=20 > Teco >=20 > Op 9 aug. 2013, om 16:31 heeft Stan Ratliff (sratliff) = het volgende geschreven: >=20 >> OK, so we've still got Martin's concerns in front of us: >>=20 >> (Inclusion from Martin.Duke@boeing.com): >> I'm a little concerned about flow control messages working over TCP. = We're looking at an application that emphasizes low latency and are = trying to operate with very small queues at the radio; to do this = without creating idle time at the radio requires tight bounds on when = credit grants get to the router. >>=20 >> In general a non-greedy application (like DLEP's control plane) = running TCP over an Ethernet connection should not trigger many packet = losses, but I'm concerned about both occasional loss-related delays, and = the Nagle algorithm raising the bound on control message delivery time. >>=20 >> Might we separate flow control from the TCP stream, just like Peer = Discovery messages? >> (end of inclusion) >>=20 >> As I've mentioned on several occasions, I'm adamantly opposed to = removing the flow control from the "base" DLEP spec. Removing flow = control from the base spec doesn't "fix" the problem, either - at least = to me, that's just "kicking the can down the road". There's a valid = concern here that TCP algorithms, and/or congestion on the router/radio = link, could really muck things up. >>=20 >> Alternatives? >>=20 >> Regards, >> Stan >>=20 >> On Aug 9, 2013, at 6:25 AM, Henning Rogge = wrote: >>=20 >>> On 08/09/2013 11:40 AM, l.wood@surrey.ac.uk wrote: >>>> That organisations became frustrated with RFC4938 does not surprise >>>> me, despite the political weight behind it. >>>>=20 >>>> DLEP adapted the PPPOE mechanisms >>>=20 >>> One of the best things DLEP does is to get RID OF the PPPoE = mechanisms. Its neither end-to-end nor point-to-point. >>>=20 >>>> and metrics as much as possible; >>>=20 >>> I disagree again. DLEP is similar but we spent quite a bit of = discussion and work to fix a lot of issues with the metrics of RFC4938. >>>=20 >>>> it is the heir to that, and the chosen design, again with poliical >>>> weight. If you don't like it, throw it out. But political weight >>>> will make DLEP the chosen solution, whatever DLEP looks like. Feel >>>> free to suggest alternatives, and to test that political weight. = Good luck! >>>=20 >>> I think DLEP already was pushed away from the RFC4938-like encoding = and protocol to a much better solution. Which is enough evidence for me = that there is quite a bit of working group input moving the protocol. >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, >>> Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Sat Aug 10 00:32:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24DF11E8145 for ; Sat, 10 Aug 2013 00:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5sXjd35AXL9 for ; Sat, 10 Aug 2013 00:32:04 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4484421F9D5E for ; Sat, 10 Aug 2013 00:27:17 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id fo12so3615508lab.17 for ; Sat, 10 Aug 2013 00:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eLfjhiqLcS0hCuhOhxE7fe7LEhF5FbsatquR6+LkvVM=; b=M8iAef+EdvHLBmcL4mqnICAzT4exhilNZCEb7FVjk6K6vaK7fE0aPQzShydKsg2/hl FPq5wVuExM/1kWEoCgZjfDiID754IozqRLEuU+R1qEwhQy8AqzMWlzU9Q6huxYytNABt ZD8Ye7QuOAQrsUQDFkGoYqv5g7B/RzccpQqYMmoXry1DGqDH5XLYEAd3GiPPjAzsdXlO +ne+5E28Us6qT4/83yM+uiK0oAdA/2eO7Nb2wy3lyIxWfXut+Wpp3YZGF6BSYCR5nirC Q//7GS/XEyDXvX0FcCefDWOJpoh44Bkxewvq1TN7UFYlHs9Bc3jseGl24MTMeYV3+aoq xIbA== X-Received: by 10.152.120.136 with SMTP id lc8mr7239770lab.89.1376119636099; Sat, 10 Aug 2013 00:27:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.199.137 with HTTP; Sat, 10 Aug 2013 00:26:56 -0700 (PDT) In-Reply-To: <290E20B455C66743BE178C5C84F124082240607505@EXMB01CMS.surrey.ac.uk> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk> <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607505@EXMB01CMS.surrey.ac.uk> From: Henning Rogge Date: Sat, 10 Aug 2013 09:26:56 +0200 Message-ID: To: l.wood@surrey.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: MANET IETF Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 07:32:05 -0000 On Sat, Aug 10, 2013 at 8:25 AM, wrote: > Sorry, I should have phrased that for clarity as ''adapted the mechanisms using PPPoE" - including the 0-100 percentage TLVs (because representing 0-255 in an octet would be difficult.) The "Relative Link Quality" metric is really a legacy metric. Many people don't like it but we keep it there to keep everyone happy. And even then we had to fix the mistake of RFC4938 to declare a link that cannot be measured always as "perfect", which can be the death of heterogeneous networks. > TLVs, metrics inherited from the space the PPPoE solution was designed for - DLEP looks remarkably similar to RFC5578 and RFC4938 to me. A general solution? I have doubts. TLVs? I am sorry, but if you think that RFC5578 is the reason for using TLVs in a protocol then I think you have a little bit tunnel vision. About the list of metrics, that is the whole reason why we have started the "DLEP design team"... to cleanup the list of metrics and make sure we got them well defined. I think the current plan is to get the list of metrics in the DLEP core spec as small as possible to a minimum set and then write one or two additional Drafts about statistical data and physical-/linklayer metrics. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From hrogge@googlemail.com Sat Aug 10 00:37:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D57E21F9831 for ; Sat, 10 Aug 2013 00:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMADdXn5XFTP for ; Sat, 10 Aug 2013 00:37:37 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6A221F99E8 for ; Sat, 10 Aug 2013 00:32:19 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id u10so3725380lbi.14 for ; Sat, 10 Aug 2013 00:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=XojoHjMaAKixvLfErImHuuH+Cdur/KLUoCDdvHMuQrU=; b=r8o1wTbeaExS9046FgGY7b+2WJ9IvkxkFKioGnvynAUCGQAQziJWH+QPGwcmJVaFDl WYXwnrRIhFVzc3jiUcvlJ3BpVZB10WieyE7rbwT6NA1avhsKZEZ3yndgAzfix0DGkeU7 FxFxe6/TmII+zyAjbDl6ux90GtUbCRPY72Ej0X2I8asebV9Ai4BOjeF2tJQ/Ayv8ZGE9 3hC+6+DHaDOLn2ig0Slx6XWw/eGVCLAtwlMp3YAMpie9SzEAwEjA61g4sLQbkfgZym3j pKaoU0Psty66g3GQA9U5iNOmEf7YWfQe1EgNRUg6Cpko60ag06NWQbAhAfLVB0d/4br6 6BRA== X-Received: by 10.152.5.66 with SMTP id q2mr7491721laq.13.1376119938321; Sat, 10 Aug 2013 00:32:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.199.137 with HTTP; Sat, 10 Aug 2013 00:31:57 -0700 (PDT) In-Reply-To: <5A8A5085482DA84995F4E70F5093AB50253E5F@XCH-BLV-503.nw.nos.boeing.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk> <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253E5F@XCH-BLV-503.nw.nos.boeing.com> From: Henning Rogge Date: Sat, 10 Aug 2013 09:31:57 +0200 Message-ID: To: "Duke, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 07:37:39 -0000 On Fri, Aug 9, 2013 at 10:24 PM, Duke, Martin wrot= e: > I agree that UDP, in itself, is going to have its own set of problems whe= n a message is lost, whether of a flow control type or not. If flow control= is poorly designed I can see cases where flow dries up because the router = has zero credits and the first credit award is lost, so we'll have to devel= op mechanisms to avoid that case. > > My concern is the process afterwards. In UDP the next flow control packet= will not incur any delay except for whatever it takes for other queued mes= sages and data to go out over the Ethernet interface. In the case of TCP, a= fter the lost message times out we'll be in slow start and later flow contr= ol packets will have to wait for ACKs to come back. > > As for the Nagle algorithm, I agree that if we specify that DLEP must be = invoked with the TCP_NODELAY option we'll be OK. I think you are right, we should think about the TCP/UDP problem. But the first question we should ask is "is it a reasonable assumption that the radio/router link becomes congested". I think the answer is no. Anyone building a IP capable radio with DLEP support that has an air-interface as fast as the ethernet connection should check his or her priorities. 100 MBit and even Gigabit ethernet is really cheap today, which should solve the congestion problem for most radios. If you build a radio which has a faster air interface than its ethernet connection to the router, you will have lost anyways. Maybe I am wrong, but I would like to hear about the scenario where the ethernet link will be congested on a radio-router connection which use DLEP flow-control. Henning Rogge --=20 We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From jch@pps.univ-paris-diderot.fr Sun Aug 11 16:18:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D53111E8169 for ; Sun, 11 Aug 2013 16:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Uyzl1jGlPdc for ; Sun, 11 Aug 2013 16:17:59 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB5721F9930 for ; Sun, 11 Aug 2013 16:10:50 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r7BNAgjs006567; Mon, 12 Aug 2013 01:10:42 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3CBE156D63; Mon, 12 Aug 2013 01:10:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id bIdHdXu5e0NK; Mon, 12 Aug 2013 01:10:41 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-109-243-177-60.play-internet.pl [109.243.177.60]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E7AD056D60; Mon, 12 Aug 2013 01:10:40 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V8emT-00017B-Kt; Mon, 12 Aug 2013 01:10:37 +0200 Date: Mon, 12 Aug 2013 01:10:37 +0200 Message-ID: <87k3jromc2.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Dearlove, Christopher (UK)" In-Reply-To: References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 12 Aug 2013 01:10:44 +0200 (CEST) X-Miltered: at korolev with ID 520819F2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 520819F2.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 520819F2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "manet@ietf.org" Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 23:18:05 -0000 > If this is a metric for OLSRv2, ask yourself why you want a symmetric metric. We don't particularly want a symmetric metric. It just turns out that the metrics that have been shown to work well with the 802.11 MAC happen to be symmetric. ETX and ETT are metrics that are designed to model more or less accurately the behaviour of the 802.11 MAC, which uses ARQ for unicast frames. They try to take into account the fact that both the airtime and the number of txops consumed when sending a unicast frame depends on the loss probability in both the forward and the backwards directions. ETX and ETT are certainly not perfect, but they would appear to model 802.11 better than a simple packet loss metric. While both are symmetric as described in the litterature, it would be quite reasonable to design a variant of ETT that takes into account the differing size of data and acknowledgment frames, and therefore would no longer be symmetric. However, I don't know of any peer-reviewed hard data that shows that such a metric behaves better in practice than plain ETT. -- Juliusz From jch@pps.univ-paris-diderot.fr Sun Aug 11 16:43:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE73921F9E01 for ; Sun, 11 Aug 2013 16:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdekQ-3TjvHF for ; Sun, 11 Aug 2013 16:43:09 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 540B511E8133 for ; Sun, 11 Aug 2013 16:36:49 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46333) with ESMTP id r7BNag4o015434; Mon, 12 Aug 2013 01:36:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 46C0D56D63; Mon, 12 Aug 2013 01:36:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ksgRxGn4nFVj; Mon, 12 Aug 2013 01:36:41 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-109-243-177-60.play-internet.pl [109.243.177.60]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D944156D60; Mon, 12 Aug 2013 01:36:40 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V8fBe-00017j-3m; Mon, 12 Aug 2013 01:36:38 +0200 Date: Mon, 12 Aug 2013 01:36:38 +0200 Message-ID: <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Teco Boot In-Reply-To: <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 12 Aug 2013 01:36:45 +0200 (CEST) X-Miltered: at potemkin with ID 5208200A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5208200A.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5208200A.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 23:43:14 -0000 > Of we build flow control over UDP, how to handle loss? By using explicit application-layer acknowledgments, as is done in OSPF, EIGRP, uTP and many more protocols. > Why would it perform better than TCP? Because upon a loss event, you send new data, and decrease the rate of updates, rather than queueing ever increasing amounts of now obsolete data. (You can actually be smarter than that -- have a look at mosh.) > Doesn't the push option enforce direct delivery? No. It's a NOP. (It was originally intended to disable queueing in mainframes' I/O coprocessors.) > Nagle can be turned off, I think. Yes. -- Juliusz From jch@pps.univ-paris-diderot.fr Sun Aug 11 16:46:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2982A11E8141 for ; Sun, 11 Aug 2013 16:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVSGvOx9YGGG for ; Sun, 11 Aug 2013 16:46:33 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9BA21E808A for ; Sun, 11 Aug 2013 16:40:26 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46333) with ESMTP id r7BNe5eB016082; Mon, 12 Aug 2013 01:40:06 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DD57E56D63; Mon, 12 Aug 2013 01:40:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Mxf0-4sN5fEL; Mon, 12 Aug 2013 01:40:05 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-109-243-177-60.play-internet.pl [109.243.177.60]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BBDEC56D60; Mon, 12 Aug 2013 01:40:04 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V8fEv-00017q-9G; Mon, 12 Aug 2013 01:40:01 +0200 Date: Mon, 12 Aug 2013 01:40:01 +0200 Message-ID: <87fvufokz2.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Henning Rogge In-Reply-To: <52048A9F.3000803@fkie.fraunhofer.de> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 12 Aug 2013 01:40:06 +0200 (CEST) X-Miltered: at potemkin with ID 520820D5.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 520820D5.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 520820D5.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: manet@ietf.org Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 23:46:39 -0000 > The point on using something simple is that it is NOT the job of the > DLEP protocol to solve the transport problems. If you have a special > link between radio and router, just use a better transport > protocol. DLEP should not care as long as the transport is reliable. I think that's a good point. It would mean that the discovery subprotocol should be powerful enough to express something like "I can speak DLEP/TCP on port 1234, but also DLEP/DCCP on port 4567 and DLEP/UDP-based-reliable-protocol-of-the-day over port 7890". -- Juliusz From henning.rogge@fkie.fraunhofer.de Mon Aug 12 00:01:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8059121F9EFE for ; Mon, 12 Aug 2013 00:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILClnp6EbF+1 for ; Mon, 12 Aug 2013 00:01:35 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id B2E3711E8103 for ; Sun, 11 Aug 2013 23:52:09 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V8lz3-0004Og-Op for manet@ietf.org; Mon, 12 Aug 2013 08:52:05 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V8lz3-0000ic-MD for manet@ietf.org; Mon, 12 Aug 2013 08:52:05 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 12 Aug 2013 08:52:06 +0200 Message-ID: <5208860F.4010906@fkie.fraunhofer.de> Date: Mon, 12 Aug 2013 08:51:59 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090103030608000500080901" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17669/Mon Aug 12 03:06:27 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4c0df1132e657673ab78dbdd5ac9f7d6 Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 07:01:41 -0000 --------------ms090103030608000500080901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 08/12/2013 01:36 AM, Juliusz Chroboczek wrote: >> Why would it perform better than TCP? > > Because upon a loss event, you send new data, and decrease the rate of > updates, rather than queueing ever increasing amounts of now obsolete > data. (You can actually be smarter than that -- have a look at mosh.) Does this even happen on a non-saturated link AND a non-saturated=20 TCP-stream for DLEP? I mean, we are talking about sending kilobytes, maybe dozens of=20 kilobytes per second on a link that still has capacity for megabytes per = second. Even if we have a packet loss, which will trigger a congestion=20 avoidance, wouldn't fast retransmit and fast recovery clean the buffer=20 very quickly again? We are talking about a situation where there=20 outgoing buffer for the connection is nearly always empty because the=20 linklayer gets the packets away much faster than we produce them. >> Nagle can be turned off, I think. > > Yes. Yes, mentioning to turn of Nagle sounds like a good idea. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090103030608000500080901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MTIwNjUyMDRaMCMGCSqGSIb3DQEJBDEWBBQTOV5kuqFrGZ6s9HyY5kPJpN7k7DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAtdn5AJjGo+vSbH1JO5vW2ZGelwrDVQYTKFftUQ+iWUM+ X6j1Y0bo3y9XJoHQiqFIOGxd4fDaSw6TTTkE8X+0AnNiNndhTPB6esRjqzrLePdUn0OCsWNI 4ZCJRH7O0OR/r9rXrNKB196fHi4ZbXQYCVbxrPk55s08tpzY0Si9+IXWaurHbd4rOzTsvpCb FjXirPs4HssgQFUUjzYr5lCvkjX00Ix7pCGHrH+Vdktud3Cypa3bc2DybFXjEeffzuMmQQt/ ErdZrZ31K+NXe++3MJ+BvzKe9zIogOfJLxsZgUoGWSXwC4UlW7i21gczOQfPHj53szl+qM8X Rg1/D3QzfAAAAAAAAA== --------------ms090103030608000500080901-- From henning.rogge@fkie.fraunhofer.de Mon Aug 12 00:04:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7261121F9E3B for ; Mon, 12 Aug 2013 00:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiN-fvxj4Ssj for ; Mon, 12 Aug 2013 00:04:36 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id DA08B21F9F31 for ; Sun, 11 Aug 2013 23:53:56 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V8m0p-0004Qw-D8; Mon, 12 Aug 2013 08:53:55 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V8m0p-0000jr-AS; Mon, 12 Aug 2013 08:53:55 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 12 Aug 2013 08:53:55 +0200 Message-ID: <52088682.1030101@fkie.fraunhofer.de> Date: Mon, 12 Aug 2013 08:53:54 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de>, <290E20B455C66743BE178C5C84F124082240607503@EXMB01CMS.surrey.ac.uk>, <5204B0A2.6070707@fkie.fraunhofer.de> <290E20B455C66743BE178C5C84F124082240607504@EXMB01CMS.surrey.ac.uk> <5204C39D.1040402@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EEFCF@xmb-aln-x03.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050004070903040705030308" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17669/Mon Aug 12 03:06:27 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ce4bc42c0f341c6b36ab5749a0b03868 Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 07:04:52 -0000 --------------ms050004070903040705030308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 08/09/2013 04:31 PM, Stan Ratliff (sratliff) wrote: > OK, so we've still got Martin's concerns in front of us: > > (Inclusion from Martin.Duke@boeing.com): I'm a little concerned about > flow control messages working over TCP. We're looking at an > application that emphasizes low latency and are trying to operate > with very small queues at the radio; to do this without creating idle > time at the radio requires tight bounds on when credit grants get to > the router. > > In general a non-greedy application (like DLEP's control plane) > running TCP over an Ethernet connection should not trigger many > packet losses, but I'm concerned about both occasional loss-related > delays, and the Nagle algorithm raising the bound on control message > delivery time. I still would like to hear how this "heavy delay" would happen on a=20 non-saturated link which is magnitudes faster than the amount of traffic = we want to send. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050004070903040705030308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MTIwNjUzNTRaMCMGCSqGSIb3DQEJBDEWBBSbnhgcLDBp7kFeiU3YTBaS9MAy/DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAGpUXc22BlRe8HE7cL/88I6ZG9AV8/ubth4qOVNt9Nd3N CRTabPZYAXO4Wrg8sc2G2vAPdnNYk4D5AlUjq/prvxLsHwURXvRxvblEXeHGSqgcYvB4Db+A d1pHuFMoqXfHttujBVhWQfh8K+oRkJBSt7fDQuYsdTZmZbwVeL39Fx5zwH62fEBEmWM8FekO 9+4NKxgysxXcHPc4/G6h8P78/5MEySzwfwECNdpIdWWMmLzVfE686tBfwoQndklSEi+SWQlM CjQScN+Keexz3XtJT6vlybJvOaXyop4d9evzj8YtVXl9wL1P9Q323IHR+8RlawBmIVC1FQq3 a/a75EwuPgAAAAAAAA== --------------ms050004070903040705030308-- From henning.rogge@fkie.fraunhofer.de Mon Aug 12 00:12:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE22F11E813B for ; Mon, 12 Aug 2013 00:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDz2WOEcz7ku for ; Mon, 12 Aug 2013 00:12:37 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A007A21E80A1 for ; Sun, 11 Aug 2013 23:57:52 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V8m4d-00063b-Uq; Mon, 12 Aug 2013 08:57:51 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V8m4d-0000lH-SB; Mon, 12 Aug 2013 08:57:51 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 12 Aug 2013 08:57:52 +0200 Message-ID: <5208876E.9080600@fkie.fraunhofer.de> Date: Mon, 12 Aug 2013 08:57:50 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Juliusz Chroboczek References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <87fvufokz2.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87fvufokz2.wl%jch@pps.univ-paris-diderot.fr> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080501070404050605060906" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17669/Mon Aug 12 03:06:27 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 00b54f98fe2f0cea78af7465bd8f318d Cc: manet@ietf.org Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 07:12:48 -0000 --------------ms080501070404050605060906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 08/12/2013 01:40 AM, Juliusz Chroboczek wrote: >> The point on using something simple is that it is NOT the job of the >> DLEP protocol to solve the transport problems. If you have a special >> link between radio and router, just use a better transport >> protocol. DLEP should not care as long as the transport is reliable. > > I think that's a good point. It would mean that the discovery > subprotocol should be powerful enough to express something like "I can > speak DLEP/TCP on port 1234, but also DLEP/DCCP on port 4567 and > DLEP/UDP-based-reliable-protocol-of-the-day over port 7890". We could add this in an extension draft. We make TCP mandatory for every DLEP implementation (both radio and=20 router), but create a new TLV (in another draft, not in the core=20 document) where a radio announce "you can also use transport protocol X=20 on port Y". The router then can decide what to use to contact the radio. This would gives us an upgrade-path for special cases without bloating=20 the core document. I am totally against NOT having a mandatory transport protocol, because=20 this will quickly lead to DLEP radios and routers that are standard=20 compliant and incompatible with each other. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080501070404050605060906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MTIwNjU3NTBaMCMGCSqGSIb3DQEJBDEWBBQ8YPjoyewOaVerSLXtlMwfWEOkjzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAjhA430A6b8HhHHUyJkUDfo6OFabpsiTTqZv801B4W+/Y Cx6O6ahQGVgkVgWgtBYMqK6/Mg3neVzwdyW5vbDBI8e0OuFqlPow448d/HyBNgrP7Buwrrr5 oBcxorwmm89iUUectJFB8T2fOiLCM3Z9E5M7SBghxEb70WhzRbgCFRpaLbq+FlFdIosdek07 mWskJQaWt5u5Sk4N4nrlEzwcwT2KR5oDmXTQSvnX66e+K7tewhbCKLSKrlJuCkqbGtpfwTmL foRoECPXct0TUdWxEH5r0Idn9+Wr9NIXsQrjMDsEUy+z2fRzU7jgO93MPxoZk9rAljSVi5bI 6N7t37OU7wAAAAAAAA== --------------ms080501070404050605060906-- From rick.taylor@cassidian.com Mon Aug 12 03:20:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E558321E80BD for ; Mon, 12 Aug 2013 03:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_55=1, J_BACKHAIR_56=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVRiWwRayM5p for ; Mon, 12 Aug 2013 03:20:39 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id C661C21E80BF for ; Mon, 12 Aug 2013 01:47:04 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 12 Aug 2013 10:39:46 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 12 Aug 2013 10:39:46 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Aug 2013 10:39:46 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Aug 2013 10:39:46 +0200 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 09:39:45 +0100 From: "Taylor, Rick" To: Henning Rogge , Juliusz Chroboczek Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOlylC5wubj40FSEO/Z64zZmA+m5mRO8/Q Date: Mon, 12 Aug 2013 08:39:45 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <87fvufokz2.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.70] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Aug 2013 08:39:46.0331 (UTC) FILETIME=[7FCAB6B0:01CE9737] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-20076.006 X-TM-AS-Result: No--35.057100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 10:20:49 -0000 I'm entirely with Henning on this one. The core DLEP spec should specify s= omething along the lines of: * A DLEP implementation MUST support TCP if the radio to router interface u= ses IP. * A DLEP implementation using TCP SHOULD disable Nagle. * A DLEP implementation MAY advertise an alternative/improved transport pro= tocols (in some non-core defined extension TBD) and these transport protoco= ls MUST be reliable (do we need to define 'reliable' or is there an RFC tha= t covers our requirements?). I understand that some people may have concerns over congestion and flow-co= ntrol over the router<->radio link, but in the common case it is expected t= hat that link will be faster than the radio<->radio interface by enough to = negate the concerns. If the radio<->router link becomes an issue, then an alternative transport = MAY be used by supporting equipment, but it remains a problem for high-spee= d device implementers. Even if the radio<->radio link characteristics begin to approach the charac= teristics of the radio<->radio link, there is nothing to stop the radio and= /or router reducing the frequency of DLEP control messages to prevent inter= ference with the data-flow over the radio<->radio link. It is not expected with DLEP that protocol messages are exchanged so rapidl= y that a 10M Ethernet link is flooded, and most (all?) radio and router man= ufacturers already have embedded controllers on-board that can support fast= er than 10M on copper. We are not discussing a 9600 baud link between radio= and router. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge > Sent: 12 August 2013 07:58 > To: Juliusz Chroboczek > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and TCP > > On 08/12/2013 01:40 AM, Juliusz Chroboczek wrote: > >> The point on using something simple is that it is NOT the job of the > >> DLEP protocol to solve the transport problems. If you have a special > >> link between radio and router, just use a better transport > >> protocol. DLEP should not care as long as the transport is reliable. > > > > I think that's a good point. It would mean that the discovery > > subprotocol should be powerful enough to express something like "I can > > speak DLEP/TCP on port 1234, but also DLEP/DCCP on port 4567 and > > DLEP/UDP-based-reliable-protocol-of-the-day over port 7890". > > We could add this in an extension draft. > > We make TCP mandatory for every DLEP implementation (both radio and > router), but create a new TLV (in another draft, not in the core > document) where a radio announce "you can also use transport protocol X > on port Y". The router then can decide what to use to contact the radio. > > This would gives us an upgrade-path for special cases without bloating > the core document. > > I am totally against NOT having a mandatory transport protocol, because > this will quickly lead to DLEP radios and routers that are standard > compliant and incompatible with each other. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From jch@pps.univ-paris-diderot.fr Mon Aug 12 03:31:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBC911E816D for ; Mon, 12 Aug 2013 03:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOtqySSDRiGx for ; Mon, 12 Aug 2013 03:31:23 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8AC21F943C for ; Mon, 12 Aug 2013 01:57:52 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46333) with ESMTP id r7C8v5cN015376; Mon, 12 Aug 2013 10:57:05 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9C17956D9C; Mon, 12 Aug 2013 10:57:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id TWq4dMqUtGzF; Mon, 12 Aug 2013 10:56:59 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-164-126-147-117.play-internet.pl [164.126.147.117]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 341F856D9A; Mon, 12 Aug 2013 10:56:59 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V8nvs-00011B-Ck; Mon, 12 Aug 2013 10:56:56 +0200 Date: Mon, 12 Aug 2013 10:56:56 +0200 Message-ID: <87wqnrffs7.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Taylor, Rick" In-Reply-To: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <87fvufokz2.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 12 Aug 2013 10:57:05 +0200 (CEST) X-Miltered: at potemkin with ID 5208A361.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5208A361.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5208A361.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 10:31:33 -0000 > * A DLEP implementation MAY advertise an alternative/improved > transport protocols (in some non-core defined extension TBD) and > these transport protocols MUST be reliable I'm not sure about that. One of the reasons to use a protocol different from TCP is to discard obsolete data upon a loss event and send newer data instead. A reliable protocol cannot do that. (The other -- and main -- reason is to reduce the sending rate upon congestion.) A good description of one such protocol is a paper that I most warmly recommend, Keith Winstein, "Mosh, an interactive remote shell for mobile clients", USENIX 2012. -- Juliusz From henning.rogge@fkie.fraunhofer.de Mon Aug 12 03:34:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F82721E81A7 for ; Mon, 12 Aug 2013 03:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F9HYU7xgJJv for ; Mon, 12 Aug 2013 03:34:44 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 816A421F9AAE for ; Mon, 12 Aug 2013 02:04:06 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V8o2I-0005j8-Hn; Mon, 12 Aug 2013 11:03:34 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V8o2I-0001uG-F8; Mon, 12 Aug 2013 11:03:34 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 12 Aug 2013 11:03:34 +0200 Message-ID: <5208A4E5.1000005@fkie.fraunhofer.de> Date: Mon, 12 Aug 2013 11:03:33 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Juliusz Chroboczek References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <87fvufokz2.wl%jch@pps.univ-paris-diderot.fr> <87wqnrffs7.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87wqnrffs7.wl%jch@pps.univ-paris-diderot.fr> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080300020502020203000207" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17670/Mon Aug 12 09:12:24 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d234359da37fdd804938a4c4798d5bfd Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 10:34:50 -0000 --------------ms080300020502020203000207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 08/12/2013 10:56 AM, Juliusz Chroboczek wrote: >> * A DLEP implementation MAY advertise an alternative/improved >> transport protocols (in some non-core defined extension TBD) and >> these transport protocols MUST be reliable > > I'm not sure about that. > > One of the reasons to use a protocol different from TCP is to discard > obsolete data upon a loss event and send newer data instead. > A reliable protocol cannot do that. If the transport is allowed to drop packets, we are back at step A.=20 Suddenly we need all the acknowledgement/retransmission mechanism in DLEP= =2E Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080300020502020203000207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MTIwOTAzMzNaMCMGCSqGSIb3DQEJBDEWBBT0tgs55kMOrr8GUXWrj7H2Zi+N9jBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAT7zSVLVmIDqIxSNHFGfC0GmlwCELv+2PbFtoc5uEWRAQ Ax8kvqXWVdCtIFf6lPy7IBWDkTgAK+UIgV/ur+K0tiv953ZSjg6xN5jfnAcUSvUdHs5KmsR/ MQoUvgfmBZiQp6xX9+qOjTXTcp0UuZness8phGh+xLdqjaEjYdztGtw78FXKtVt8FmJ3n7Im aCFFsGECrgs8VJj1ADazTyEPJvUvGByJV03azAhHB/+EF8ASI1sBf1q86E3Ny3zHVFwq6oLU rRsBt0ykyaIjUYx8IgYcAGO4DzzFKK02P5CXWDI4VsWcPW1+XyqVHvNUXoDTv89O1YI62Ort XJcQI7UtQgAAAAAAAA== --------------ms080300020502020203000207-- From rick.taylor@cassidian.com Mon Aug 12 04:15:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9202621F99BE for ; Mon, 12 Aug 2013 04:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwLuh5ecLX1P for ; Mon, 12 Aug 2013 04:15:30 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3273221F9D53 for ; Mon, 12 Aug 2013 03:17:32 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 12 Aug 2013 12:17:22 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 12 Aug 2013 12:17:21 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Aug 2013 12:17:21 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Aug 2013 12:17:21 +0200 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 11:17:21 +0100 From: "Taylor, Rick" To: Juliusz Chroboczek Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOlznl5wubj40FSEO/Z64zZmA+m5mRWS2g Date: Mon, 12 Aug 2013 10:17:19 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <87fvufokz2.wl%jch@pps.univ-paris-diderot.fr> <50248905-e365-4c1f-adf4-1964062ff71e@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <50248905-e365-4c1f-adf4-1964062ff71e@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Aug 2013 10:17:21.0530 (UTC) FILETIME=[21C32DA0:01CE9745] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-20076.006 X-TM-AS-Result: No--19.098600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:15:36 -0000 > > * A DLEP implementation MAY advertise an alternative/improved > > transport protocols (in some non-core defined extension TBD) and > > these transport protocols MUST be reliable > > I'm not sure about that. > > One of the reasons to use a protocol different from TCP is to discard > obsolete data upon a loss event and send newer data instead. > A reliable protocol cannot do that. Dropping obsolete packets is not currently under consideration with DLEP. = What is an obsolete packet? Do you want that specified with each packet ty= pe? Are you suggesting we split the protocol into reliable and partial-rel= iable messages? I want to move away from this model, at least in the core spec. If a vendo= r wishes to implement a second transport built around SCTP with partial-rel= iability extensions and carefully specify (in an external document) which p= ackets are always delivered and which are 'replaced' under congestion with = newer information, then that is their business, but they MUST still support= TCP/IP. > > (The other -- and main -- reason is to reduce the sending rate upon > congestion.) Sending rate congestion (as previously stated) is not expected under 'usual= ' circumstances. For the unusual case, see above. > > A good description of one such protocol is a paper that I most warmly > recommend, > > Keith Winstein, "Mosh, an interactive remote shell for mobile clients", > USENIX 2012. I'll have a look at some point, but remember: the router is not 'mobile' in= relation to its local radio. This is not a 'remote' relationship. There = will always be a short cable at most between the devices. Rick Taylor The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From chris.dearlove@baesystems.com Mon Aug 12 04:50:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BB121F9814 for ; Mon, 12 Aug 2013 04:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.178 X-Spam-Level: X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whln5Bm3WPK3 for ; Mon, 12 Aug 2013 04:50:03 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B5E4F21F8B04 for ; Mon, 12 Aug 2013 04:22:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,861,1367967600"; d="scan'208";a="363543402" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Aug 2013 12:22:58 +0100 X-IronPort-AV: E=Sophos;i="4.89,861,1367967600"; d="scan'208";a="24168619" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 12 Aug 2013 12:22:58 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.90]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Mon, 12 Aug 2013 12:22:58 +0100 From: "Dearlove, Christopher (UK)" To: Juliusz Chroboczek Thread-Topic: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 Thread-Index: AQHOk2eUwRww7Jk9E0e8cj+lD3bcH5mKAPcAgAAClgCAATUT8IAFX8eAgADaswA= Date: Mon, 12 Aug 2013 11:22:57 +0000 Message-ID: References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> <87k3jromc2.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87k3jromc2.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:50:09 -0000 OK. We need to be clear on the applicability, but that's a detail. Given your comments, and the requirements of OLSRv2 both to have a metric i= mmediately, and that it doesn't need to be symmetric, the following would b= e my (not fully thought through) first thought. - You need a metric immediately. In the absence of any other information yo= u may have a forward measure, you'll have to assume backward is poor, and c= ombine those two. - Later you will have backward information, e.g. in a TLV in a HELLO messag= e. You can then revise your combined forward/backward metric - but used to = represent the inward metric. The combination can be asymmetric if you like,= or symmetric. - The other end does the same to get its inward metric, your outward metric= . If using a symmetric combination these may well be the same, which makes = for more efficient HELLO messages. But you don't make that assumption. If y= our neighbour tells you a significantly different view of its in, your out,= metric (in a HELLO message) than your view of your in metric then you have= two choices (a) ignore the difference, use what you are given. Under no ci= rcumstances substitute your value for its value, that's a looping problem w= aiting to happen, (b) recognise this is really messed up and reject the lin= k. Exactly how to do the latter is stepping outside NHDP, but permitted by = its extension clauses. Personally I'd go with (a). -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Juliusz Chroboczek [mailto:jch@pps.univ-paris-diderot.fr] = Sent: 12 August 2013 00:11 To: Dearlove, Christopher (UK) Cc: Henning Rogge; Joe Macker; manet@ietf.org Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-= 02 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- > If this is a metric for OLSRv2, ask yourself why you want a symmetric met= ric. = We don't particularly want a symmetric metric. It just turns out that the metrics that have been shown to work well with the 802.11 MAC happen to be symmetric. ETX and ETT are metrics that are designed to model more or less accurately the behaviour of the 802.11 MAC, which uses ARQ for unicast frames. They try to take into account the fact that both the airtime and the number of txops consumed when sending a unicast frame depends on the loss probability in both the forward and the backwards directions. ETX and ETT are certainly not perfect, but they would appear to model 802.11 better than a simple packet loss metric. While both are symmetric as described in the litterature, it would be quite reasonable to design a variant of ETT that takes into account the differing size of data and acknowledgment frames, and therefore would no longer be symmetric. However, I don't know of any peer-reviewed hard data that shows that such a metric behaves better in practice than plain ETT. -- Juliusz ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From rick.taylor@cassidian.com Mon Aug 12 04:50:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634F511E8189 for ; Mon, 12 Aug 2013 04:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAVJS9sF5cAE for ; Mon, 12 Aug 2013 04:50:30 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id C3F8021F9654 for ; Mon, 12 Aug 2013 04:23:59 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 12 Aug 2013 13:23:55 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 12 Aug 2013 13:23:55 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Aug 2013 13:23:55 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Aug 2013 13:23:54 +0200 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 12:23:54 +0100 From: "Taylor, Rick" To: "manet@ietf.org" Thread-Topic: DLEP message classification Thread-Index: Ac6XTmy1hQYaNPIpQSG3x14RrKiFlg== Date: Mon, 12 Aug 2013 11:23:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Aug 2013 11:23:54.0942 (UTC) FILETIME=[6E057DE0:01CE974E] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-20076.006 X-TM-AS-Result: No--15.216100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [manet] DLEP message classification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:50:38 -0000 As a clarification from those who haven't read a DLEP draft for a while, DL= EP protocol messages can be split into the following classes: 1) Discovery messages. 2) Control messages. 3) Event messages. 4) Status messages. It must be remembered that NONE of these messages travel over the radio med= ium, the DLEP protocol operates between a radio and a directly connected ra= dio. If a radio needs to communicate with another device in order to satis= fy some part of the DLEP protocol, then it is the radio's business how that= occurs. Discovery messages are broadcast from a radio to discover an attached route= r, via a link-local multicast/broadcast message. UDP is proposed as a defa= ult protocol. These messages are unreliable by definition. Control messages are used for session initiation (and optional termination)= . This class may also include flow-control and other functionality-request= messages. These messages require reliable in-order delivery. They also r= equire a DLEP protocol level acknowledgement. Event messages describe a change of session state, such as Neighbour_Up, Ne= ighbour_Down. They must be delivered reliably and in-order, but do not req= uire explicit acknowledgement at the DLEP protocol level: the events have o= ccurred whether the router likes it or not. Status messages describe the change of status of a link or neighbour, examp= les include metric updates. Such messages do not strictly need to be deliv= ered reliably, but must be delivered in order. It is logically valid for a = metric change event to be cancelled by the sender before delivery if a late= r message supersedes the information. Like event messages, status messages= require no explicit acknowledgement at the DLEP protocol level. TCP is an ideal transport protocol for delivering Control and Event message= s, and it is considered by the active DLEP participants that specifying a n= ew protocol that implements all the reliability and in-order delivery of TC= P is just reinventing the wheel. It is also accepted that the Nagle algori= thm does not add benefit, and SHOULD be disabled. It could be debated that a new protocol should be defined for Status messag= es, taking advantage of the relaxed delivery requirements. The proposal is= to mandate TCP/IP as a default supported protocol, but allow some mechanis= m within the discovery or session initiation steps to allow compatible rout= ers and radios to establish an alternate protocol to deliver status message= s. It has also been argued that there may be a class of control messages from = router to radio (the characteristic request/flow-control messages) that may= benefit from a more relaxed delivery model (in-order but allow superseding= ). Again, this can be supplied by using a second negotiated protocol as pe= r status messages. A compelling reason for mandating a TCP + UDP stack as minimal transport pr= otocols is that embedded implementations for these protocols are freely ava= ilable and the majority of radios implementing DLEP already support an IP s= tack for the data-plane. Specifying an elaborate custom transport stack ju= st for DLEP will diminish uptake of the protocol from radio vendors and wil= l relegate DLEP to obscurity. Just my 2 pennies worth... Rick Taylor The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From chris.dearlove@baesystems.com Mon Aug 12 04:50:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E4A11E818E for ; Mon, 12 Aug 2013 04:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.196 X-Spam-Level: X-Spam-Status: No, score=-9.196 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbeXcbbl63Il for ; Mon, 12 Aug 2013 04:50:54 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8E17621F9FA7 for ; Mon, 12 Aug 2013 04:26:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,861,1367967600"; d="scan'208";a="363544318" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Aug 2013 12:25:34 +0100 X-IronPort-AV: E=Sophos;i="4.89,861,1367967600"; d="scan'208";a="24168841" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 12 Aug 2013 12:25:34 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.90]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Mon, 12 Aug 2013 12:25:34 +0100 From: "Dearlove, Christopher (UK)" To: Teco Boot Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26tDWOpIqYY+Uy8o0+IQ/ULg5mJpxwAgAAU84CAAAXuAIABpjIAgAANR4CAAFYagIAAiYeAgAADLACAAAG6gIAAB2EAgACjGKD///jkgIAEeHAA Date: Mon, 12 Aug 2013 11:25:34 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> <19E85BDD-E99C-4234-9836-837EF3738C5F@inf-net.nl> In-Reply-To: <19E85BDD-E99C-4234-9836-837EF3738C5F@inf-net.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:50:59 -0000 If your main objective is getting a document out fast, you may be prepared = to sacrifice some quality, as that's now a secondary objective. That's not = the tradeoff the IESG will make in my experience. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 09 August 2013 17:07 To: Dearlove, Christopher (UK) Cc: manet@ietf.org List Subject: Re: [manet] DLEP and TCP ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Op 9 aug. 2013, om 17:36 heeft "Dearlove, Christopher (UK)" het volgende geschreven: > " Main objective is getting a document out as fast as we can" >=20 > Don't let the IESG hear you say that, that's not the accepted main object= ive creating RFCs. Correctness is important (or even dominant). I cannot see a contradiction. Teco >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Teco Boot > Sent: 09 August 2013 07:49 > To: manet@ietf.org List > Subject: Re: [manet] DLEP and TCP >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Op 9 aug. 2013, om 08:22 heeft Henning Rogge het volgende geschreven: >=20 >> On 08/09/2013 08:16 AM, l.wood@surrey.ac.uk wrote: >>> I think the problem here lies in not knowing how to design protocols >>> on UDP. >>>=20 >>> Other groups - notably IRTF DTNRG - have had the effective outcome of >>> "communication design is hard, let's just use TCP". >>=20 >> The point on using something simple is that it is NOT the job of the DLE= P protocol to solve the transport problems. If you have a special link betw= een radio and router, just use a better transport protocol. DLEP should not= care as long as the transport is reliable. >>=20 >> Building our own reliable, low-delay, thinks-about-everything (and maybe= reinvent-the wheel) style transport into DLEP doesn't sound like a good id= ea. > Exactly. >=20 > Main objective is getting a document out as fast as we can, and more impo= rtant, get the protocol running out in the wild. Simple and straightforward= is important here. >=20 > We shortly discussed SCTP. Could be a better choice as it may somewhat be= tter support what we need. On the other hand, UDP and TCP stacks are everyw= here and these fit. >=20 >>=20 >> If we want to use UDP, going the "lets use Stop-and-wait" might be the o= nly option that does not greatly increase the complexity of the protocol. > Yes. > TCP can easily beat such. Less work, better performance. That's why we de= cided to go for TCP. >=20 > Teco >=20 >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From rick.taylor@cassidian.com Mon Aug 12 05:33:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C3321F9DFC for ; Mon, 12 Aug 2013 05:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGamF6172xyQ for ; Mon, 12 Aug 2013 05:33:39 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id AF0A521F9D55 for ; Mon, 12 Aug 2013 05:12:52 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 12 Aug 2013 14:12:49 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 12 Aug 2013 14:12:48 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Aug 2013 14:12:48 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Aug 2013 14:12:48 +0200 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 13:12:47 +0100 From: "Taylor, Rick" To: "Dearlove, Christopher (UK)" , Teco Boot Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26t5wubj40FSEO/Z64zZmA+m5mJpxwAgAAU84CAAAXuAIABpjIAgAANR4CAAFYagIAAiYeAgAADLACAAAG6gIAAB2EAgACjGKD///jkgIAEeHAAgAANapA= Date: Mon, 12 Aug 2013 12:12:47 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> <19E85BDD-E99C-4234-9836-837EF3738C5F@inf-net.nl> <8c7d7f06-50da-4e2b-b75a-1c9d3c668c7a@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <8c7d7f06-50da-4e2b-b75a-1c9d3c668c7a@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.70] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Aug 2013 12:12:48.0158 (UTC) FILETIME=[425ABBE0:01CE9755] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-20076.007 X-TM-AS-Result: No--47.824200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org List" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 12:33:45 -0000 I believe the intention is to make rapid progress towards a document of the= usual high standard demanded by the IESG. Is that sufficiently politically correct? Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Dearlove, Christopher (UK) > Sent: 12 August 2013 12:26 > To: Teco Boot > Cc: manet@ietf.org List > Subject: Re: [manet] DLEP and TCP > > If your main objective is getting a document out fast, you may be prepare= d > to sacrifice some quality, as that's now a secondary objective. That's no= t > the tradeoff the IESG will make in my experience. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 09 August 2013 17:07 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org List > Subject: Re: [manet] DLEP and TCP > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Op 9 aug. 2013, om 17:36 heeft "Dearlove, Christopher (UK)" > het volgende geschreven: > > > " Main objective is getting a document out as fast as we can" > > > > Don't let the IESG hear you say that, that's not the accepted main > objective creating RFCs. Correctness is important (or even dominant). > I cannot see a contradiction. > > Teco > > > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Teco Boot > > Sent: 09 August 2013 07:49 > > To: manet@ietf.org List > > Subject: Re: [manet] DLEP and TCP > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > Op 9 aug. 2013, om 08:22 heeft Henning Rogge > het volgende geschreven: > > > >> On 08/09/2013 08:16 AM, l.wood@surrey.ac.uk wrote: > >>> I think the problem here lies in not knowing how to design protocols > >>> on UDP. > >>> > >>> Other groups - notably IRTF DTNRG - have had the effective outcome of > >>> "communication design is hard, let's just use TCP". > >> > >> The point on using something simple is that it is NOT the job of the > DLEP protocol to solve the transport problems. If you have a special link > between radio and router, just use a better transport protocol. DLEP > should not care as long as the transport is reliable. > >> > >> Building our own reliable, low-delay, thinks-about-everything (and > maybe reinvent-the wheel) style transport into DLEP doesn't sound like a > good idea. > > Exactly. > > > > Main objective is getting a document out as fast as we can, and more > important, get the protocol running out in the wild. Simple and > straightforward is important here. > > > > We shortly discussed SCTP. Could be a better choice as it may somewhat > better support what we need. On the other hand, UDP and TCP stacks are > everywhere and these fit. > > > >> > >> If we want to use UDP, going the "lets use Stop-and-wait" might be the > only option that does not greatly increase the complexity of the protocol= . > > Yes. > > TCP can easily beat such. Less work, better performance. That's why we > decided to go for TCP. > > > > Teco > > > >> > >> Henning Rogge > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) > >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From sratliff@cisco.com Mon Aug 12 07:29:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD3D21E80B9 for ; Mon, 12 Aug 2013 07:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkUH8wsv4dHr for ; Mon, 12 Aug 2013 07:29:23 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA3811E80FA for ; Mon, 12 Aug 2013 07:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7833; q=dns/txt; s=iport; t=1376317315; x=1377526915; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=497wBmfJLuu9ZdyKVpss0qVjUKJVMpbvBRfibOGEt3Y=; b=PwvscfHicbNef9dHRPY5VegyLG3Um4hMY/ReW6lRsmen9hH8oHVed5uH cnuuMNBxRVDvri5kzIZqZtVWG+xHf/xbC4QjP1OrgCr3Sc6J8TOKagGF3 2S6RAXxYw8SCdzh3BNoMyVNnW9CbrIfh18gbnkPpl3+hQC/6727hrQpw1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAODuCFKtJV2b/2dsb2JhbABagwY1UL5UgRkWdIIkAQEBAwEBAQFSGQMIBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIiAIGDLYzjnUKBgh7AgYFIQUHAgSDFXYDiHWgQIMbgWgJFyI X-IronPort-AV: E=Sophos;i="4.89,862,1367971200"; d="scan'208";a="246258988" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 12 Aug 2013 14:21:52 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7CELq9E008811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 14:21:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 09:21:52 -0500 From: "Stan Ratliff (sratliff)" To: "Taylor, Rick" Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26thqeH9HMbGU+WXMCShCPLOJmJpxwAgAAU84CAAAXuAIABpjIAgAANR4CAAFYagIAAiYeAgAADLACAAAG6gIAAB2EAgACjGKD///jkgIAEeHAAgAANapCAAHhTgA== Date: Mon, 12 Aug 2013 14:21:52 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFC6D@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com>, <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> <19E85BDD-E99C-4234-9836-837EF3738C5F@inf-net.nl> <8c7d7f06-50da-4e2b-b75a-1c9d3c668c7a@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 14:29:28 -0000 Chris,=20 I think we're all a bit frustrated with the lack of progress, and it's time= to kick the intensity level up a notch or two. No one that I know of is re= ady to sacrifice correctness on the altar of expediency - we just want it d= one.=20 Regards, Stan On Aug 12, 2013, at 8:12 AM, "Taylor, Rick" wro= te: > I believe the intention is to make rapid progress towards a document of t= he usual high standard demanded by the IESG. >=20 > Is that sufficiently politically correct? >=20 > Rick Taylor >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >> Dearlove, Christopher (UK) >> Sent: 12 August 2013 12:26 >> To: Teco Boot >> Cc: manet@ietf.org List >> Subject: Re: [manet] DLEP and TCP >>=20 >> If your main objective is getting a document out fast, you may be prepar= ed >> to sacrifice some quality, as that's now a secondary objective. That's n= ot >> the tradeoff the IESG will make in my experience. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: Teco Boot [mailto:teco@inf-net.nl] >> Sent: 09 August 2013 17:07 >> To: Dearlove, Christopher (UK) >> Cc: manet@ietf.org List >> Subject: Re: [manet] DLEP and TCP >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Op 9 aug. 2013, om 17:36 heeft "Dearlove, Christopher (UK)" >> het volgende geschreven: >>=20 >>> " Main objective is getting a document out as fast as we can" >>>=20 >>> Don't let the IESG hear you say that, that's not the accepted main >> objective creating RFCs. Correctness is important (or even dominant). >> I cannot see a contradiction. >>=20 >> Teco >>=20 >>=20 >>>=20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> Of Teco Boot >>> Sent: 09 August 2013 07:49 >>> To: manet@ietf.org List >>> Subject: Re: [manet] DLEP and TCP >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Op 9 aug. 2013, om 08:22 heeft Henning Rogge >> het volgende geschreven: >>>=20 >>>> On 08/09/2013 08:16 AM, l.wood@surrey.ac.uk wrote: >>>>> I think the problem here lies in not knowing how to design protocols >>>>> on UDP. >>>>>=20 >>>>> Other groups - notably IRTF DTNRG - have had the effective outcome of >>>>> "communication design is hard, let's just use TCP". >>>>=20 >>>> The point on using something simple is that it is NOT the job of the >> DLEP protocol to solve the transport problems. If you have a special lin= k >> between radio and router, just use a better transport protocol. DLEP >> should not care as long as the transport is reliable. >>>>=20 >>>> Building our own reliable, low-delay, thinks-about-everything (and >> maybe reinvent-the wheel) style transport into DLEP doesn't sound like a >> good idea. >>> Exactly. >>>=20 >>> Main objective is getting a document out as fast as we can, and more >> important, get the protocol running out in the wild. Simple and >> straightforward is important here. >>>=20 >>> We shortly discussed SCTP. Could be a better choice as it may somewhat >> better support what we need. On the other hand, UDP and TCP stacks are >> everywhere and these fit. >>>=20 >>>>=20 >>>> If we want to use UDP, going the "lets use Stop-and-wait" might be the >> only option that does not greatly increase the complexity of the protoco= l. >>> Yes. >>> TCP can easily beat such. Less work, better performance. That's why we >> decided to go for TCP. >>>=20 >>> Teco >>>=20 >>>>=20 >>>> Henning Rogge >>>>=20 >>>> -- >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) >>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to th= is e-mail is private and in addition may include commercially sensitive inf= ormation. The contents of this e-mail are for the intended recipient only a= nd therefore if you wish to disclose the information contained within this = e-mail or attached files, please contact the sender prior to any such discl= osure. If you are not the intended recipient, any disclosure, copying or di= stribution is prohibited. Please also contact the sender and inform them of= the error and delete the e-mail, including any attached files from your sy= stem. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs= , Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.c= om > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Mon Aug 12 08:44:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC1221E836E for ; Mon, 12 Aug 2013 08:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBds3UhG7zAa for ; Mon, 12 Aug 2013 08:44:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7621E82A7 for ; Mon, 12 Aug 2013 07:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2520; q=dns/txt; s=iport; t=1376318204; x=1377527804; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Kjpk/jUoYVAFoKroskPKVsAHtYXb0Z7+KiBow9KEL5Y=; b=NqrZteLWa+G1K6HimnTKKS9dO9Uh4MNAoBU3H1k5JIpIcrboy+vodlWw HKkXf7ereecKmMOcctURuNaQ8rhvCnscZkmcojXnRB9hMDy2IBFGbTFj/ kXkJUzK6PDApvgn7rhekHBM54FGguPQjCKF2bR/GL45SzKWh8/PzoVq4K k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACTyCFKtJV2Z/2dsb2JhbABbgwY1UL5UgRkWdIIkAQEBAwEBAQFrCwULAgEIGAodBycLFBECBA4FCIgCBgy2So51gRMCMQeDG3YDiHWgQIMbgXE5 X-IronPort-AV: E=Sophos;i="4.89,862,1367971200"; d="scan'208";a="246352017" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 12 Aug 2013 14:36:41 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7CEafKk006956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 14:36:41 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 09:36:40 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26ihqeH9HMbGU+WXMCShCPLOJmKC7EAgAAU9ICAAAXyAIABpi0AgAANR4CAAARGgIAAFXIAgAUQcACAAHmjgIAAgdUA Date: Mon, 12 Aug 2013 14:36:40 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> In-Reply-To: <5208860F.4010906@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <28526595CE9A184BB51E9C8CA2024778@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 15:44:46 -0000 On Aug 12, 2013, at 2:51 AM, Henning Rogge wrote: > On 08/12/2013 01:36 AM, Juliusz Chroboczek wrote: >>> Why would it perform better than TCP? >>=20 >> Because upon a loss event, you send new data, and decrease the rate of >> updates, rather than queueing ever increasing amounts of now obsolete >> data. (You can actually be smarter than that -- have a look at mosh.) >=20 > Does this even happen on a non-saturated link AND a non-saturated TCP-str= eam for DLEP? >=20 > I mean, we are talking about sending kilobytes, maybe dozens of kilobytes= per second on a link that still has capacity for megabytes per second. But, at this point, we're somewhat designing the protocol with a network im= plementation in mind, aren't we? I mean, just flipping back through the rec= ent email thread, I've seen a couple of assumptions stated:=20 1. The link between router and radio is *always* local (e.g. the radio is t= he next hop), and=20 2. The link between router and radio will *always* be faster (some have sai= d 'orders of magnitude faster') than the RF link.=20 If the consensus of the WG is that those assumptions will always hold, then= OK. Perhaps I should add them to the assumptions section of the draft. To = be honest, I don't have any implementations in mind that would violate thos= e 2 assumptions; but I don't know if that's the case for all potential impl= ementers of DLEP. So, it makes me stop and think... Regards, Stan >=20 > Even if we have a packet loss, which will trigger a congestion avoidance,= wouldn't fast retransmit and fast recovery clean the buffer very quickly a= gain? We are talking about a situation where there outgoing buffer for the = connection is nearly always empty because the linklayer gets the packets aw= ay much faster than we produce them. >=20 >>> Nagle can be turned off, I think. >>=20 >> Yes. >=20 > Yes, mentioning to turn of Nagle sounds like a good idea. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Mon Aug 12 08:49:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AC821E80E9 for ; Mon, 12 Aug 2013 08:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VJv4W5mjrbs for ; Mon, 12 Aug 2013 08:49:35 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4069421F9A25 for ; Mon, 12 Aug 2013 07:47:27 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mf11so4824991lab.1 for ; Mon, 12 Aug 2013 07:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zaMSD4eLjJ+Utnx4qKLaofC/bDSp0rb1kR7pZq031kE=; b=HKJIDmlJX6S5I+C3o3i6VIvX1Y2/Tn1gbY6T0dK9X1+cB9KCcM2fFCOQJ2RgJPhsxd xaKF67T1aPEPumxNbzUmRtFm9ItkklXeHl1a6ezuQVgkFJwTlsW+5dfFm6QHSWKtcz2m aZ08OKaT4OssrkSw5WmuHhwsVRCFzHJtEEFh76jFK/ooAYQxqau6TXqmtnkcMs9cyYjI RMlzj+pQ2PZDF6KRtMuIwQWgZltd0GOVAKl5cTuFKT0keQNDbXlVGiSONjw0MAMD6T2B dzMdxpUmVRnQBHh7Mkj65tJMwBh6J1mS+O3qbZzi0gZnMdx7owOxSxKMPL8tsqHyct+o ykfw== X-Received: by 10.112.63.2 with SMTP id c2mr9814894lbs.6.1376318846135; Mon, 12 Aug 2013 07:47:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.199.137 with HTTP; Mon, 12 Aug 2013 07:47:06 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFC6D@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <290E20B455C66743BE178C5C84F124082240607500@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F124082240607502@EXMB01CMS.surrey.ac.uk> <52048A9F.3000803@fkie.fraunhofer.de> <19E85BDD-E99C-4234-9836-837EF3738C5F@inf-net.nl> <8c7d7f06-50da-4e2b-b75a-1c9d3c668c7a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFC6D@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Mon, 12 Aug 2013 16:47:06 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 15:49:35 -0000 On Mon, Aug 12, 2013 at 4:21 PM, Stan Ratliff (sratliff) wrote: > Chris, > > I think we're all a bit frustrated with the lack of progress, and it's time to kick the intensity level up a notch or two. No one that I know of is ready to sacrifice correctness on the altar of expediency - we just want it done. Yes, thats also one reason why we started the "design team", to do some effective research on the metrics for DLEP in parallel so we can create a comprehensive list before we run it through the Manet WG again. Discussing the transport part here in the group while also working on a list of metrics should speed up things (hopefully) a lot. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From brian.adamson@nrl.navy.mil Mon Aug 12 09:34:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD7121F9A59 for ; Mon, 12 Aug 2013 09:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_BACKHAIR_56=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n192w8d3B0Y for ; Mon, 12 Aug 2013 09:34:55 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) by ietfa.amsl.com (Postfix) with ESMTP id DC0BE11E811B for ; Mon, 12 Aug 2013 08:50:49 -0700 (PDT) Received: from macsimus.itd.nrl.navy.mil (macsimus.itd.nrl.navy.mil [132.250.92.151]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id r7CFoSP9020480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 11:50:28 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-320-730953183 From: Brian Adamson In-Reply-To: Date: Mon, 12 Aug 2013 11:50:27 -0400 Message-Id: <4A2F46C4-6B1C-4BBC-9D9B-613EF7AA3822@nrl.navy.mil> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <87fvufokz2.wl%jch@pps.univ-paris-diderot.fr> To: "Taylor, Rick" X-Mailer: Apple Mail (2.1085) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Cc: "manet@ietf.org" , Juliusz Chroboczek Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 16:34:59 -0000 --Apple-Mail-320-730953183 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I mostly concur with the recommendation here(e.g. strive to let DLEP = work on top of different physical/logical media) , but think the DLEP = specification should clearly indicate what its requirements for the = underlying transport & interconnect are in terms of: 1) ordered message delivery 2) reliability 3) adaptive (e.g. dynamic congestion control) or preset transfer rate, = or both 4) flow control=20 5) Any DLEP transport session parameters that need to be established 6) Automated discovery (e.g. similar to what PPPoE can do but using = mDNS, uPNP or something?) There will likely be different message bus technologies that might be = suitable for handling DLEP requirements. =20 The one concern here is to do this in a way that doesn't defeat = interoperability. I.e., some minimal common mechanism should be = mandated. Brian Adamson brian.adamson@nrl.navy.mil On Aug 12, 2013, at 4:39 AM, Taylor, Rick wrote: > I'm entirely with Henning on this one. The core DLEP spec should = specify something along the lines of: >=20 > * A DLEP implementation MUST support TCP if the radio to router = interface uses IP. >=20 > * A DLEP implementation using TCP SHOULD disable Nagle. >=20 > * A DLEP implementation MAY advertise an alternative/improved = transport protocols (in some non-core defined extension TBD) and these = transport protocols MUST be reliable (do we need to define 'reliable' or = is there an RFC that covers our requirements?). >=20 > I understand that some people may have concerns over congestion and = flow-control over the router<->radio link, but in the common case it is = expected that that link will be faster than the radio<->radio interface = by enough to negate the concerns. >=20 > If the radio<->router link becomes an issue, then an alternative = transport MAY be used by supporting equipment, but it remains a problem = for high-speed device implementers. >=20 > Even if the radio<->radio link characteristics begin to approach the = characteristics of the radio<->radio link, there is nothing to stop the = radio and/or router reducing the frequency of DLEP control messages to = prevent interference with the data-flow over the radio<->radio link. >=20 > It is not expected with DLEP that protocol messages are exchanged so = rapidly that a 10M Ethernet link is flooded, and most (all?) radio and = router manufacturers already have embedded controllers on-board that can = support faster than 10M on copper. We are not discussing a 9600 baud = link between radio and router. >=20 > Rick Taylor >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Henning Rogge >> Sent: 12 August 2013 07:58 >> To: Juliusz Chroboczek >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP and TCP >>=20 >> On 08/12/2013 01:40 AM, Juliusz Chroboczek wrote: >>>> The point on using something simple is that it is NOT the job of = the >>>> DLEP protocol to solve the transport problems. If you have a = special >>>> link between radio and router, just use a better transport >>>> protocol. DLEP should not care as long as the transport is = reliable. >>>=20 >>> I think that's a good point. It would mean that the discovery >>> subprotocol should be powerful enough to express something like "I = can >>> speak DLEP/TCP on port 1234, but also DLEP/DCCP on port 4567 and >>> DLEP/UDP-based-reliable-protocol-of-the-day over port 7890". >>=20 >> We could add this in an extension draft. >>=20 >> We make TCP mandatory for every DLEP implementation (both radio and >> router), but create a new TLV (in another draft, not in the core >> document) where a radio announce "you can also use transport protocol = X >> on port Y". The router then can decide what to use to contact the = radio. >>=20 >> This would gives us an upgrade-path for special cases without = bloating >> the core document. >>=20 >> I am totally against NOT having a mandatory transport protocol, = because >> this will quickly lead to DLEP radios and routers that are standard >> compliant and incompatible with each other. >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > The information contained within this e-mail and any files attached to = this e-mail is private and in addition may include commercially = sensitive information. The contents of this e-mail are for the intended = recipient only and therefore if you wish to disclose the information = contained within this e-mail or attached files, please contact the = sender prior to any such disclosure. If you are not the intended = recipient, any disclosure, copying or distribution is prohibited. Please = also contact the sender and inform them of the error and delete the = e-mail, including any attached files from your system. Cassidian = Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, = Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-320-730953183 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Brian = Adamson



On Aug 12, 2013, at 4:39 AM, Taylor, Rick wrote:

I'm = entirely with Henning on this one.  The core DLEP spec should = specify something along the lines of:

* A DLEP implementation = MUST support TCP if the radio to router interface uses IP.

* A = DLEP implementation using TCP SHOULD disable Nagle.

* A DLEP = implementation MAY advertise an alternative/improved transport protocols = (in some non-core defined extension TBD) and these transport protocols = MUST be reliable (do we need to define 'reliable' or is there an RFC = that covers our requirements?).

I understand that some people may = have concerns over congestion and flow-control over the = router<->radio link, but in the common case it is expected that = that link will be faster than the radio<->radio interface by = enough to negate the concerns.

If the radio<->router link = becomes an issue, then an alternative transport MAY be used by = supporting equipment, but it remains a problem for high-speed device = implementers.

Even if the radio<->radio link = characteristics begin to approach the characteristics of the = radio<->radio link, there is nothing to stop the radio and/or = router reducing the frequency of DLEP control messages to prevent = interference with the data-flow over the radio<->radio = link.

It is not expected with DLEP that protocol messages are = exchanged so rapidly that a 10M Ethernet link is flooded, and most = (all?) radio and router manufacturers already have embedded controllers = on-board that can support faster than 10M on copper. We are not = discussing a 9600 baud link between radio and router.

Rick = Taylor

-----Original = Message-----
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf Of
Henning Rogge
Sent: 12 August 2013 07:58
To: Juliusz Chroboczek
Cc: manet@ietf.org
Subject: Re: [manet] DLEP and = TCP

On 08/12/2013 01:40 AM, Juliusz Chroboczek = wrote:
The point on using something = simple is that it is NOT the job of = the
DLEP = protocol to solve the transport problems. If you have a = special
link = between radio and router, just use a better = transport
protocol. DLEP should not care as long as the transport is = reliable.

I think that's a good point. =  It would mean that the = discovery
subprotocol should be powerful = enough to express something like "I = can
speak DLEP/TCP on port 1234, but also DLEP/DCCP on port = 4567 and
DLEP/UDP-based-reliable-protocol-of-the-day over port = 7890".

We could add = this in an extension draft.

We make TCP = mandatory for every DLEP implementation (both radio = and
router), but create a new = TLV (in another draft, not in the core
document) where a radio announce "you can also use = transport protocol X
on port = Y". The router then can decide what to use to contact the = radio.

This would = gives us an upgrade-path for special cases without = bloating
the core = document.

I am totally = against NOT having a mandatory transport protocol, = because
this will quickly lead = to DLEP radios and routers that are standard
compliant and incompatible with each = other.

Henning = Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut = f=FCr
Kommunikation, = Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, = Germany
Telefon +49 228 = 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge@fkie= .fraunhofer.de http://www.fkie.fraunhofer.de

The information contained within this e-mail and any = files attached to this e-mail is private and in addition may include = commercially sensitive information. The contents of this e-mail are for = the intended recipient only and therefore if you wish to disclose the = information contained within this e-mail or attached files, please = contact the sender prior to any such disclosure. If you are not the = intended recipient, any disclosure, copying or distribution is = prohibited. Please also contact the sender and inform them of the error = and delete the e-mail, including any attached files from your system. = Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com
________= _______________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail-320-730953183-- From hrogge@googlemail.com Mon Aug 12 09:44:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9300F21F9BA0 for ; Mon, 12 Aug 2013 09:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SOBcD-+xBFS for ; Mon, 12 Aug 2013 09:44:28 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE3B21F9976 for ; Mon, 12 Aug 2013 09:11:15 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id 13so4887557lba.6 for ; Mon, 12 Aug 2013 09:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=//J5djVsvPOWohvxPHcBOg56nME+yCFbZpQCpwLhFxE=; b=IoW2PLxgV61SaHXQAf08qste7McfJIuPeN5849aj9SFkIePBy63uNkg8xV2d6Ng9Hh S0YL3QSioix+TrNWIzgqCJuSzWhlDmGFuqQWut7YBLDl4NIY8/odU0v7sYegrsFHYk8K Oxux1VhfAx4Y3tLYu7iVgvqr0UUX3jSNrMk76mwjoikBSDv/q0SSw/c3EJRUYQ69AQYQ 0yXGJ6sEKpa3c0F/egRqZ5B0ZbBJwZSpXz/SoymZHWuyhAcodWonhaYhe4C8kcf8VUEO bZA1toTn01uu3LtgL89jvzow6YakxQe/5u+rkfUq/l9GgkiR27RrYV2CuY1uWWcPsNla hniQ== X-Received: by 10.152.8.51 with SMTP id o19mr1660923laa.42.1376323874353; Mon, 12 Aug 2013 09:11:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.199.137 with HTTP; Mon, 12 Aug 2013 09:10:54 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Mon, 12 Aug 2013 18:10:54 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 16:44:29 -0000 On Mon, Aug 12, 2013 at 4:36 PM, Stan Ratliff (sratliff) wrote: > But, at this point, we're somewhat designing the protocol with a network = implementation in mind, aren't we? I mean, just flipping back through the r= ecent email thread, I've seen a couple of assumptions stated: > 1. The link between router and radio is *always* local (e.g. the radio is= the next hop), and If DLEP use linklocal multicast for discovery it will not work for more than one (IP) hop anyways. Also sending bridged traffic over multiple IP hops will require some kind of tunnel, which should be out of scope for the DLEP core spec. Using multiple layer-2 hops might work, as long as you keep the total datarate in mind. Connecting multiple slow radios over a single gigabit ethernet switch to the router might work, but it would still need either a manageable switch (VLANs to select to outgoing ports) or some crazy trickery with the traffic. > 2. The link between router and radio will *always* be faster (some have s= aid 'orders of magnitude faster') than the RF link. I would say yes. If someone wants to violate this 2nd assumption, then I can see a way to still make this work: 1) use a dedicated point to point ethernet link 2) use prioritization and traffic shaping to guarantee there is always capacity left for the DLEP traffic. > If the consensus of the WG is that those assumptions will always hold, th= en OK. Perhaps I should add them to the assumptions section of the draft. T= o be honest, I don't have any implementations in mind that would violate th= ose 2 assumptions; but I don't know if that's the case for all potential im= plementers of DLEP. So, it makes me stop and think... I think they are both reasonable. Especially if you plan to use flow-control with DLEP. Henning Rogge --=20 We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From jch@pps.univ-paris-diderot.fr Mon Aug 12 09:57:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE6521E8105 for ; Mon, 12 Aug 2013 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC0ufM0Sxbb2 for ; Mon, 12 Aug 2013 09:57:09 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF4D21F9E04 for ; Mon, 12 Aug 2013 09:36:18 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46333) with ESMTP id r7CGaEC5031395; Mon, 12 Aug 2013 18:36:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3F2CC56D9A; Mon, 12 Aug 2013 18:36:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id d8SQ8MgOAwC4; Mon, 12 Aug 2013 18:36:08 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-31-174-24-237.play-internet.pl [31.174.24.237]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CA6CB56DCE; Mon, 12 Aug 2013 18:36:07 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V8v6C-0001oX-5Y; Mon, 12 Aug 2013 18:36:04 +0200 Date: Mon, 12 Aug 2013 18:36:04 +0200 Message-ID: <87k3jqg93f.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Dearlove, Christopher (UK)" In-Reply-To: References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> <87k3jromc2.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 12 Aug 2013 18:36:14 +0200 (CEST) X-Miltered: at potemkin with ID 52090EFE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 52090EFE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 52090EFE.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "manet@ietf.org" Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 16:57:16 -0000 > - You need a metric immediately. I think I strongly agree with you -- if OLSRv2 is to be relevant in The Real World (as opposed to simulation), it needs to come with a reference metric that works better than hop count. I am fairly happy with Henning's work (up to some editorial changes that I still haven't had time to fully write up), and the only point I have strong feelings about is that it should be renamed to avoid confusion with ETT. As to the other points -- I'm glad that you are aware of the issue (and, perhaps immodestly, I like thinking that I've been instrumental in helping people think about it), but I don't think it is as urgent as Henning's current work. (We're currently experimenting with some very exciting new metrics in the Babel world, and at least some of that work should be relevant to OLSRv2. Unfortunately, my current favourite metric, Z3, is not isotonic, and hence cannot be used with Dijkstra's algorithm.) -- Juliusz From jch@pps.univ-paris-diderot.fr Mon Aug 12 10:07:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE14021F9B86 for ; Mon, 12 Aug 2013 10:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyw2K7S9Ib7q for ; Mon, 12 Aug 2013 10:07:01 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F6421F9A72 for ; Mon, 12 Aug 2013 09:50:23 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46333) with ESMTP id r7CGoJCu001626; Mon, 12 Aug 2013 18:50:19 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5E75E56DCD; Mon, 12 Aug 2013 18:50:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id p_qwlzz_bvNo; Mon, 12 Aug 2013 18:50:13 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-31-174-24-237.play-internet.pl [31.174.24.237]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4213856D9A; Mon, 12 Aug 2013 18:50:13 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V8vJp-0001oy-NV; Mon, 12 Aug 2013 18:50:09 +0200 Date: Mon, 12 Aug 2013 18:50:09 +0200 Message-ID: <87d2pig8fy.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Stan Ratliff (sratliff)" In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 12 Aug 2013 18:50:19 +0200 (CEST) X-Miltered: at potemkin with ID 5209124B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5209124B.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5209124B.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:07:07 -0000 > 1. The link between router and radio is *always* local... > 2. The link between router and radio will *always* be faster... Assuming these assumptions always hold in normal usage of DLEP -- is it acceptable for DLEP to collapse when they do not? Should it be able to recover in a timely manner when the conditions are met once again? -- Juliusz From ulrich@herberg.name Mon Aug 12 10:17:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C7821F81FF for ; Mon, 12 Aug 2013 10:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSMoa+UoALeE for ; Mon, 12 Aug 2013 10:17:33 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0081921F9951 for ; Mon, 12 Aug 2013 10:06:02 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hz10so2946622vcb.40 for ; Mon, 12 Aug 2013 10:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6yo/ca7qmDf1dWg3aItqzntSSH1Wtntff2rMvhDPFp4=; b=OWzL6vx7sTm5N6nqOz2pOcrxDyxnW1ofpMG+8k3JxnPCqLTAsaq9foG9/rHtonERWm FjTNix+8DNojaUdqlUjryonBTLLv2NLdzpca6HtTtaNObbC+nEpn1VYT2SyhrcD0792+ oYRpxHJH4LphV2XNY03BimFM3MU9dmje4uc2g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6yo/ca7qmDf1dWg3aItqzntSSH1Wtntff2rMvhDPFp4=; b=ePG99jRC4DZTI2vAyWoKuglSrp3lQEm2CTr3qJ8+AriqV50lLpXVEP3PS7Hr+LWW6D s29dFEEzp40fyyPc2SPpCj0OQQ2yUHANYLH5PiZ/yPusvyUgoqTYuWwcz1I33d04Lo5R CxHWLETnEwb8jpUjUP1+NffjPL+II8p5rtAU9n6xz+GbdyCH1Yh9jQyRp9EYhv+9QmgZ NgbghoablS+eWgYArjzGjHzZ0reay1NzKX55wF8s0KIXfcfeW5YFUuFxHiRLO8A3P8D2 nMFxjrLNFtOvjifj82ZXnSYxpGkkOY1OV3fWSa1gA1XEQCgc/TJ/lJJ2c0vjwX79ROmi YBmg== X-Gm-Message-State: ALoCoQk64Ph2GLw0lrum3QaH4xPKku3bmQztfstZ0GfOW4Q+J017MVvL0us289p1Bjr8J2o+DlOn MIME-Version: 1.0 X-Received: by 10.58.128.71 with SMTP id nm7mr34983veb.51.1376327150999; Mon, 12 Aug 2013 10:05:50 -0700 (PDT) Received: by 10.220.127.65 with HTTP; Mon, 12 Aug 2013 10:05:50 -0700 (PDT) In-Reply-To: <87k3jqg93f.wl%jch@pps.univ-paris-diderot.fr> References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> <87k3jromc2.wl%jch@pps.univ-paris-diderot.fr> <87k3jqg93f.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 12 Aug 2013 10:05:50 -0700 Message-ID: From: Ulrich Herberg To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:17:34 -0000 I think that Chris meant that a router needs to send out a metric to a newly discovered neighbor, even if it has not yet received the inbound metric from that new neighbor. That's different from the question whether we need a new metric specification. I am in favor of working on a such a document, but I would like to see a new revision first. Chris mentioned a few good points recently in an email [1]. I think these should be addressed before the document is considered for WG adoption. [1] http://www.ietf.org/mail-archive/web/manet/current/msg15522.html Ulrich On Mon, Aug 12, 2013 at 9:36 AM, Juliusz Chroboczek wrote: >> - You need a metric immediately. > > I think I strongly agree with you -- if OLSRv2 is to be relevant in > The Real World (as opposed to simulation), it needs to come with > a reference metric that works better than hop count. I am fairly > happy with Henning's work (up to some editorial changes that I still > haven't had time to fully write up), and the only point I have strong > feelings about is that it should be renamed to avoid confusion with ETT. > > As to the other points -- I'm glad that you are aware of the issue > (and, perhaps immodestly, I like thinking that I've been instrumental > in helping people think about it), but I don't think it is as urgent > as Henning's current work. > > (We're currently experimenting with some very exciting new metrics in > the Babel world, and at least some of that work should be relevant to > OLSRv2. Unfortunately, my current favourite metric, Z3, is not isotonic, > and hence cannot be used with Dijkstra's algorithm.) > > -- Juliusz > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From chris.dearlove@baesystems.com Mon Aug 12 10:20:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4AF21F9DCE for ; Mon, 12 Aug 2013 10:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xE4jGApYIGL for ; Mon, 12 Aug 2013 10:20:10 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3F85821F88FB for ; Mon, 12 Aug 2013 10:12:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,863,1367967600"; d="scan'208";a="363671884" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Aug 2013 18:12:30 +0100 X-IronPort-AV: E=Sophos;i="4.89,863,1367967600"; d="scan'208";a="24214050" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 12 Aug 2013 18:12:29 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.90]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Mon, 12 Aug 2013 18:12:30 +0100 From: "Dearlove, Christopher (UK)" To: Juliusz Chroboczek Thread-Topic: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 Thread-Index: AQHOk2eUwRww7Jk9E0e8cj+lD3bcH5mKAPcAgAAClgCAATUT8IAFX8eAgADaswCAAElmAIAAGUCQ Date: Mon, 12 Aug 2013 17:12:29 +0000 Message-ID: References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> <87k3jromc2.wl%jch@pps.univ-paris-diderot.fr> <87k3jqg93f.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87k3jqg93f.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:20:15 -0000 I think you have misinterpreted what I meant. (I just see Ulrich has made the same point, so I don't need to explain.) That's not to say I disagree with you, just that's not the point I made. Of course OLSRv2 already has non-hop count metrics. Whatever you like. As a= n example, a trivial - but nonetheless useful - one is a small set of well-= separated values for a set of different bandwidths. It's not standardised, = so it's specific to a network, and needs appropriate management. But you ca= n do it today (or for some time). (Note that I'm not considering Wi-Fi networks here, but rather heterogeneou= s networks with inherently quite different types of links.) -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Juliusz Chroboczek [mailto:jch@pps.univ-paris-diderot.fr] = Sent: 12 August 2013 17:36 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-= 02 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- > - You need a metric immediately. I think I strongly agree with you -- if OLSRv2 is to be relevant in The Real World (as opposed to simulation), it needs to come with a reference metric that works better than hop count. I am fairly happy with Henning's work (up to some editorial changes that I still haven't had time to fully write up), and the only point I have strong feelings about is that it should be renamed to avoid confusion with ETT. As to the other points -- I'm glad that you are aware of the issue (and, perhaps immodestly, I like thinking that I've been instrumental in helping people think about it), but I don't think it is as urgent as Henning's current work. (We're currently experimenting with some very exciting new metrics in the Babel world, and at least some of that work should be relevant to OLSRv2. Unfortunately, my current favourite metric, Z3, is not isotonic, and hence cannot be used with Dijkstra's algorithm.) -- Juliusz ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From jch@pps.univ-paris-diderot.fr Mon Aug 12 10:39:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2721F89C3 for ; Mon, 12 Aug 2013 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43tZCjdQ-5hj for ; Mon, 12 Aug 2013 10:39:34 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id CE94821F87B7 for ; Mon, 12 Aug 2013 10:35:36 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r7CHZWJb011829; Mon, 12 Aug 2013 19:35:32 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1281856DCF; Mon, 12 Aug 2013 19:35:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id P08V6SI5cIab; Mon, 12 Aug 2013 19:35:31 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-5-173-235-74.play-internet.pl [5.173.235.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D680756DD4; Mon, 12 Aug 2013 19:35:30 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V8w1f-0001sU-3C; Mon, 12 Aug 2013 19:35:27 +0200 Date: Mon, 12 Aug 2013 19:35:27 +0200 Message-ID: <87a9kmg6cg.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ulrich Herberg In-Reply-To: References: <8761vhvguv.wl%jch@pps.univ-paris-diderot.fr> <87k3jromc2.wl%jch@pps.univ-paris-diderot.fr> <87k3jqg93f.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 12 Aug 2013 19:35:32 +0200 (CEST) X-Miltered: at korolev with ID 52091CE4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 52091CE4.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 52091CE4.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:39:40 -0000 > I think that Chris meant that a router needs to send out a metric to a > newly discovered neighbor, even if it has not yet received the inbound > metric from that new neighbor. Ah, I had read "immediately" and "later" as current and later specifications. Sorry for the misunderstanding. (Note to self -- don't reply to e-mail just before supper.) -- Juliusz From jari.arkko@piuha.net Mon Aug 12 10:50:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C950021F9C20; Mon, 12 Aug 2013 10:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyee2HZNjM1O; Mon, 12 Aug 2013 10:50:21 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id DACB721F9BF7; Mon, 12 Aug 2013 10:50:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 348252CC51; Mon, 12 Aug 2013 20:50:19 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XDhImv3E4Vu; Mon, 12 Aug 2013 20:50:18 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 59D062CC48; Mon, 12 Aug 2013 20:50:18 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jari Arkko In-Reply-To: <3140092F-123B-4FD3-A7DF-A61C44C76262@vigilsec.com> Date: Mon, 12 Aug 2013 20:50:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3140092F-123B-4FD3-A7DF-A61C44C76262@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1508) Cc: IETF Gen-ART , manet@ietf.org, IESG Subject: Re: [manet] Gen-ART Review of draft-ietf-manet-rfc6622-bis-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:50:27 -0000 Russ: Thank you very much for your review and re-review. I have placed a = no-objection ballot for this draft for the upcoming IESG telechat. Jari On Aug 9, 2013, at 1:09 AM, Russ Housley wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-manet-rfc6622-bis-04 > Reviewer: Russ Housley > Review Date: 2013-06-15 > IETF LC End Date: 2013-06-27 > IESG Telechat date: 2013-08-15 >=20 > Summary: The document is ready for publication as a > standards track RFC. >=20 > I reviewed -02 during IETF Last Call, and all of my concerns have > been addressed in -04. From sratliff@cisco.com Mon Aug 12 10:59:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F11D21F9D55 for ; Mon, 12 Aug 2013 10:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1XOcNVRmU5K for ; Mon, 12 Aug 2013 10:59:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D686121F9433 for ; Mon, 12 Aug 2013 10:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2114; q=dns/txt; s=iport; t=1376330364; x=1377539964; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3+rhAV8oe0o1uRSUuLwzIeQ/egOjyDreWPd0GHG0zyo=; b=mXfYDIsii/m1xBP5rtZgIVinhxUUPSuBf/gnU08buYBBa5B6FpljfZ4X Lm+FRtDlSXCVE7muRB1MybwwLMi8yDaCTPiCxasW0a0hGzhJxx2WecYVy 632q97xDjA6DLANY7tQleTV/kxgbZbGnBwoHIH0M5CwIQTReFhRrTACbh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPwhCVKtJV2Z/2dsb2JhbABbgwaBBb5VgRoWdIIkAQEBAwF5EAIBCA4UJDIlAgQOBQiIAga2ZpAIAjEHgxt2A6k1gxuCKg X-IronPort-AV: E=Sophos;i="4.89,863,1367971200"; d="scan'208";a="243375441" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 12 Aug 2013 17:59:23 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7CHxN1G026849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 17:59:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 12:59:23 -0500 From: "Stan Ratliff (sratliff)" To: Juliusz Chroboczek Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26ihqeH9HMbGU+WXMCShCPLOJmKC7EAgAAU9ICAAAXyAIABpi0AgAANR4CAAARGgIAAFXIAgAUQcACAAHmjgIAAgdUAgAAlS4CAABNXAA== Date: Mon, 12 Aug 2013 17:59:22 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0740@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <87d2pig8fy.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87d2pig8fy.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="Windows-1252" Content-ID: <671A3EFFF766094A813D352C911FDD46@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:59:31 -0000 On Aug 12, 2013, at 12:50 PM, Juliusz Chroboczek wrote: >> 1. The link between router and radio is *always* local... >> 2. The link between router and radio will *always* be faster... >=20 > Assuming these assumptions always hold in normal usage of DLEP -- is > it acceptable for DLEP to collapse when they do not? Should it be > able to recover in a timely manner when the conditions are met once again= ? >=20 A couple of observations. First, the obvious answer to your questions are "= no" and "yes", respectively.=20 Second, I'm not sure we've discussed a case yet where DLEP would "collapse"= =85 but perhaps we're working off of different interpretations of that term= . What I can see is a case where, if the physical link from router to radio= is ever outpaced by the wireless link, *or* in the case where the router-r= adio link is sporadically congested, then the notion of flow-controlling th= e radio via DLEP is problematic (due to potential packet delays within the = transport mechanism, or DLEP flow-control packet drops). Outside of the (op= tional) flow control mechanism, I'm not seeing a case where even sporadic c= ongestion on the router-radio link would cause an issue I'd define as a "co= llapse" - the worst case I can see is the dropping/re-transmission of a "Ne= ighbor Down" packet, which could cause traffic black-holing for the duratio= n of the TCP retransmission cycle. However, the same issue would exist usin= g UDP as a transport: if the "Neighbor Down" is dropped, traffic could get = black-holed unless/until the sender (the radio) (a) determines that the Nei= ghbor Down got dropped, and (b) successfully retransmits it. In either case= , the problem would persist until either the DLEP implementation (or the tr= ansport) successfully transmits the packet, *or* the routing protocol's "De= ad Timer" fires. Therefore, you could argue that the routing protocol's De= ad Timer effective acts as a "backstop" for this occurrence.=20 Is there a case I'm missing? Regards, Stan > -- Juliusz From jch@pps.univ-paris-diderot.fr Mon Aug 12 12:09:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCDD21F9CE2 for ; Mon, 12 Aug 2013 12:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcsWlqj3vDkB for ; Mon, 12 Aug 2013 12:09:23 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6B421F9958 for ; Mon, 12 Aug 2013 12:09:10 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r7CJ8qRO025420; Mon, 12 Aug 2013 21:08:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CBE7F56DDD; Mon, 12 Aug 2013 21:08:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id bf906Y2desBq; Mon, 12 Aug 2013 21:08:51 +0200 (CEST) Received: from pirx.pps.jussieu.fr (user-5-173-235-74.play-internet.pl [5.173.235.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7213656DE0; Mon, 12 Aug 2013 21:08:49 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V8xTy-0002Gh-Ar; Mon, 12 Aug 2013 21:08:46 +0200 Date: Mon, 12 Aug 2013 21:08:46 +0200 Message-ID: <8761vag20x.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Stan Ratliff (sratliff)" In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0740@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <87d2pig8fy.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0740@xmb-aln-x03.cisco.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 12 Aug 2013 21:08:52 +0200 (CEST) X-Miltered: at korolev with ID 520932C4.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 520932C4.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 520932C4.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:09:32 -0000 >>> 1. The link between router and radio is *always* local... >>> 2. The link between router and radio will *always* be faster... >> Assuming these assumptions always hold in normal usage of DLEP -- >> is it acceptable for DLEP to collapse when they do not? Should it >> be able to recover in a timely manner when the conditions are met >> once again? > A couple of observations. First, the obvious answer to your > questions are "no" and "yes", respectively. Yeah, they were rigged ;-) > Second, I'm not sure we've discussed a case yet where DLEP would "collapse" [...] > Is there a case I'm missing? TCP will buffer DLEP updates even when the router-radio link is hopelessly congested or down. When the link is operational again, new updates will be sent only after TCP times out (which can take up to 30 seconds, if memory serves) and the buffers drain (which can take an arbitrarily large amount of time unless the amount of buffering is carefully controlled). We're probably speaking of a worst case of at least a couple of minutes in a naive implementation. I'm pretty sure that can be reduced to well under one minute (without kernel changes) by carefully controlling the size of the TCP buffers with non-blocking writes, using application-layer keepalives with short timeouts, and probably other tricks. Is doing that properly any easier than implementing a well-designed protocol layered over UDP? I don't know, since, while I have a fair amount of experience with implementing stuff over UDP, I don't have any with implementing real-time protocols over TCP. -- Juliusz From sratliff@cisco.com Mon Aug 12 12:32:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8423321F9EED for ; Mon, 12 Aug 2013 12:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcRs2cXRigqh for ; Mon, 12 Aug 2013 12:32:16 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 95DC221F9EDD for ; Mon, 12 Aug 2013 12:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2315; q=dns/txt; s=iport; t=1376335936; x=1377545536; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Yfzb+zu9OiaYua1PMnfa+64FSgm97KZ+XMx022EVoAQ=; b=ETlVvtrYhjiNddo1kGAOqspyslQ49Iprk/oiMN082iQpOE3zUPG6CWC2 oWCAUjDSX0tfFYuW6iMJD1+gqJW8+iv4Ua3cDErVjEAcEU8Z9kloZJzOg MOcNE6GOy0Z1LsN8CP0blllBKfZyCtoCjfvSTnz0VdOL03gubWgwk1ybV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAMc3CVKtJV2Y/2dsb2JhbABbgwaBBb5WgRsWdIIkAQEBAwF5EAIBCA4UJDIlAgQOBQiIAga2Zo51gRMCMQeDG3YDqTWDG4FxOQ X-IronPort-AV: E=Sophos;i="4.89,863,1367971200"; d="scan'208";a="246439937" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 12 Aug 2013 19:32:12 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7CJWCBw014892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 19:32:12 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 14:32:12 -0500 From: "Stan Ratliff (sratliff)" To: Juliusz Chroboczek Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOk26ihqeH9HMbGU+WXMCShCPLOJmKC7EAgAAU9ICAAAXyAIABpi0AgAANR4CAAARGgIAAFXIAgAUQcACAAHmjgIAAgdUAgAAlS4CAABNXAIAAE2QAgAAGi4A= Date: Mon, 12 Aug 2013 19:32:11 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0B01@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <87d2pig8fy.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0740@xmb-aln-x03.cisco.com> <8761vag20x.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <8761vag20x.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8A18EADC8E666A42A3DE28CB80D2A1E8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:32:22 -0000 On Aug 12, 2013, at 3:08 PM, Juliusz Chroboczek wrote: >>>> 1. The link between router and radio is *always* local... >>>> 2. The link between router and radio will *always* be faster... >=20 >>> Assuming these assumptions always hold in normal usage of DLEP -- >>> is it acceptable for DLEP to collapse when they do not? Should it >>> be able to recover in a timely manner when the conditions are met >>> once again? >=20 >> A couple of observations. First, the obvious answer to your >> questions are "no" and "yes", respectively. >=20 > Yeah, they were rigged ;-) Yes. To the point that my initial reaction was to consider your email as no= t serious, and therefore, to not respond. >=20 >> Second, I'm not sure we've discussed a case yet where DLEP would "collap= se" > [...] >> Is there a case I'm missing? >=20 > TCP will buffer DLEP updates even when the router-radio link is > hopelessly congested or down. When the link is operational again, new > updates will be sent only after TCP times out (which can take up to 30 > seconds, if memory serves) and the buffers drain (which can take an > arbitrarily large amount of time unless the amount of buffering is > carefully controlled). We're probably speaking of a worst case of at > least a couple of minutes in a naive implementation. A "couple of minutes" bumps into the routing protocol's Dead Timer (even wi= th a naive implementation of the Dead Timer), so=85=20 Keeping the application-level Heartbeat message in the specification would = allow an implementation to detect the problem faster. It might seem like ov= erkill at first blush, but I think there's some merit to keep it, even over= TCP.=20 Stan >=20 > I'm pretty sure that can be reduced to well under one minute (without > kernel changes) by carefully controlling the size of the TCP buffers > with non-blocking writes, using application-layer keepalives with > short timeouts, and probably other tricks. Is doing that properly any > easier than implementing a well-designed protocol layered over UDP? > I don't know, since, while I have a fair amount of experience with > implementing stuff over UDP, I don't have any with implementing > real-time protocols over TCP. >=20 > -- Juliusz From teco@inf-net.nl Mon Aug 12 22:07:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39BB11E8127 for ; Mon, 12 Aug 2013 22:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl1w2Sr-IQmd for ; Mon, 12 Aug 2013 22:07:18 -0700 (PDT) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADA911E80D3 for ; Mon, 12 Aug 2013 22:07:12 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id mz11so2117380bkb.23 for ; Mon, 12 Aug 2013 22:07:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=TzggXPyyvRnSmQga+a9UHSqLuFnwv6bKKcYkM4rSzug=; b=DfVzppSLmiV0GXdAydNwOh/cskdKbaxdFnKGHl9+pTPLp1B4XCPxeTPy9nkzVp3wKd uxBf94IRVV54B+GmpNUIp1V7CVHUFEoHwv+GX79ZOPlGiZsY5a3YxbS8oME/uH7/QjHL 4Tvx/+vxDmMDpqXWWbX04VpY5XE/GBmhym0gXFWWeiyd3JjE7po29m0Sa05/ttq8096u 3XDP6WR9vR5PwJwyLsRpFzhtc+AGOs9NpxOCq6AHBKaKHpGlyn4MDLZR6VN+krCS7V+Y aA3JWNXJuXABxw6VszsV1k+Hq0tyJAV/JN2uIS84nzkYfV0GeSWp7YlZMj3BHPMn4YZG xeNQ== X-Gm-Message-State: ALoCoQlMp9dBmrNd+xOQvyOw8oTqThzt0qPEqxpHgXekQvaAn7jtH97IMWWWpDYPz2+5zwrCvNj6 X-Received: by 10.204.234.5 with SMTP id ka5mr993110bkb.5.1376370430026; Mon, 12 Aug 2013 22:07:10 -0700 (PDT) Received: from [10.87.10.157] ([88.128.80.4]) by mx.google.com with ESMTPSA id jh13sm6032492bkb.13.2013.08.12.22.07.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Aug 2013 22:07:08 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0B01@xmb-aln-x03.cisco.com> Date: Tue, 13 Aug 2013 07:06:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16566C37-3102-4CAC-9A0F-D040672421B1@inf-net.nl> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <87d2pig8fy.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0740@xmb-aln-x03.cisco.com> <8761vag20x.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0B01@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1508) Cc: "" , Juliusz Chroboczek Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 05:07:24 -0000 Op 12 aug. 2013, om 21:32 heeft "Stan Ratliff (sratliff)" = het volgende geschreven: >=20 > On Aug 12, 2013, at 3:08 PM, Juliusz Chroboczek = wrote: >=20 >>>>> 1. The link between router and radio is *always* local... >>>>> 2. The link between router and radio will *always* be faster... >>=20 >>>> Assuming these assumptions always hold in normal usage of DLEP -- >>>> is it acceptable for DLEP to collapse when they do not? Should it >>>> be able to recover in a timely manner when the conditions are met >>>> once again? >>=20 >>> A couple of observations. First, the obvious answer to your >>> questions are "no" and "yes", respectively. >>=20 >> Yeah, they were rigged ;-) >=20 > Yes. To the point that my initial reaction was to consider your email = as not serious, and therefore, to not respond. >=20 >>=20 >>> Second, I'm not sure we've discussed a case yet where DLEP would = "collapse" >> [...] >>> Is there a case I'm missing? >>=20 >> TCP will buffer DLEP updates even when the router-radio link is >> hopelessly congested or down. When the link is operational again, = new >> updates will be sent only after TCP times out (which can take up to = 30 >> seconds, if memory serves) and the buffers drain (which can take an >> arbitrarily large amount of time unless the amount of buffering is >> carefully controlled). We're probably speaking of a worst case of at >> least a couple of minutes in a naive implementation. >=20 > A "couple of minutes" bumps into the routing protocol's Dead Timer = (even with a naive implementation of the Dead Timer), so=85=20 >=20 > Keeping the application-level Heartbeat message in the specification = would allow an implementation to detect the problem faster. It might = seem like overkill at first blush, but I think there's some merit to = keep it, even over TCP.=20 Sure we keep the heartbeats. I would like to see a fresh TCP connection = in seconds rather than minutes. The new connection will reset state = machines, so neighbors go down and up. Teco >=20 > Stan >=20 >>=20 >> I'm pretty sure that can be reduced to well under one minute (without >> kernel changes) by carefully controlling the size of the TCP buffers >> with non-blocking writes, using application-layer keepalives with >> short timeouts, and probably other tricks. Is doing that properly = any >> easier than implementing a well-designed protocol layered over UDP? >> I don't know, since, while I have a fair amount of experience with >> implementing stuff over UDP, I don't have any with implementing >> real-time protocols over TCP. >>=20 >> -- Juliusz >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From rick.taylor@cassidian.com Tue Aug 13 01:24:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6AA21F9E05 for ; Tue, 13 Aug 2013 01:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.261 X-Spam-Level: * X-Spam-Status: No, score=1.261 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_BACKHAIR_56=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RchA4bTxbTut for ; Tue, 13 Aug 2013 01:24:25 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 235AB21F9D83 for ; Tue, 13 Aug 2013 01:24:21 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 13 Aug 2013 10:24:19 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 13 Aug 2013 10:24:18 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Aug 2013 10:24:18 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Aug 2013 10:24:18 +0200 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 09:24:17 +0100 From: "Taylor, Rick" To: Brian Adamson Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOlylC5wubj40FSEO/Z64zZmA+m5mRuYBTgAEUMiA= Date: Tue, 13 Aug 2013 08:24:16 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <52024712.8090907@fkie.fraunhofer.de> <90DFDC60-0875-4084-AD3C-9C3BEA11FCCF@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C101E93EA@xmb-aln-x03.cisco.com> <5A8A5085482DA84995F4E70F5093AB50253C3A@XCH-BLV-503.nw.nos.boeing.com> <87fvufokz2.wl%jch@pps.univ-paris-diderot.fr> <10d5268c-7f09-469c-ad4f-02bbd7cd3340@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <10d5268c-7f09-469c-ad4f-02bbd7cd3340@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.70] Content-Type: multipart/alternative; boundary="_000_B177F831FB91F242972D0C35F6A0733105BA07E1SUCNPTEXM01coma_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2013 08:24:18.0102 (UTC) FILETIME=[80EFF560:01CE97FE] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-20078.005 X-TM-AS-Result: No--31.649700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" , Juliusz Chroboczek Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 08:24:30 -0000 --_000_B177F831FB91F242972D0C35F6A0733105BA07E1SUCNPTEXM01coma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, I tried to start a breakdown of requirements, see my email to the li= st entitled "DLEP message classification". I agree that there are situations where the radio and router may be connect= ed by a non-IP medium, e.g. a PCI bus. Rick Taylor ________________________________ From: Brian Adamson [mailto:brian.adamson@nrl.navy.mil] Sent: 12 August 2013 16:50 To: Taylor, Rick Cc: Henning Rogge; Juliusz Chroboczek; manet@ietf.org Subject: Re: [manet] DLEP and TCP I mostly concur with the recommendation here(e.g. strive to let DLEP work o= n top of different physical/logical media) , but think the DLEP specificati= on should clearly indicate what its requirements for the underlying transpo= rt & interconnect are in terms of: 1) ordered message delivery 2) reliability 3) adaptive (e.g. dynamic congestion control) or preset transfer rate, or b= oth 4) flow control 5) Any DLEP transport session parameters that need to be established 6) Automated discovery (e.g. similar to what PPPoE can do but using mDNS, u= PNP or something?) There will likely be different message bus technologies that might be suita= ble for handling DLEP requirements. The one concern here is to do this in a way that doesn't defeat interoperab= ility. I.e., some minimal common mechanism should be mandated. Brian Adamson brian.adamson@nrl.navy.mil On Aug 12, 2013, at 4:39 AM, Taylor, Rick wrote: I'm entirely with Henning on this one. The core DLEP spec should specify s= omething along the lines of: * A DLEP implementation MUST support TCP if the radio to router interface u= ses IP. * A DLEP implementation using TCP SHOULD disable Nagle. * A DLEP implementation MAY advertise an alternative/improved transport pro= tocols (in some non-core defined extension TBD) and these transport protoco= ls MUST be reliable (do we need to define 'reliable' or is there an RFC tha= t covers our requirements?). I understand that some people may have concerns over congestion and flow-co= ntrol over the router<->radio link, but in the common case it is expected t= hat that link will be faster than the radio<->radio interface by enough to = negate the concerns. If the radio<->router link becomes an issue, then an alternative transport = MAY be used by supporting equipment, but it remains a problem for high-spee= d device implementers. Even if the radio<->radio link characteristics begin to approach the charac= teristics of the radio<->radio link, there is nothing to stop the radio and= /or router reducing the frequency of DLEP control messages to prevent inter= ference with the data-flow over the radio<->radio link. It is not expected with DLEP that protocol messages are exchanged so rapidl= y that a 10M Ethernet link is flooded, and most (all?) radio and router man= ufacturers already have embedded controllers on-board that can support fast= er than 10M on copper. We are not discussing a 9600 baud link between radio= and router. Rick Taylor -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Henning Rogge Sent: 12 August 2013 07:58 To: Juliusz Chroboczek Cc: manet@ietf.org Subject: Re: [manet] DLEP and TCP On 08/12/2013 01:40 AM, Juliusz Chroboczek wrote: The point on using something simple is that it is NOT the job of the DLEP protocol to solve the transport problems. If you have a special link between radio and router, just use a better transport protocol. DLEP should not care as long as the transport is reliable. I think that's a good point. It would mean that the discovery subprotocol should be powerful enough to express something like "I can speak DLEP/TCP on port 1234, but also DLEP/DCCP on port 4567 and DLEP/UDP-based-reliable-protocol-of-the-day over port 7890". We could add this in an extension draft. We make TCP mandatory for every DLEP implementation (both radio and router), but create a new TLV (in another draft, not in the core document) where a radio announce "you can also use transport protocol X on port Y". The router then can decide what to use to contact the radio. This would gives us an upgrade-path for special cases without bloating the core document. I am totally against NOT having a mandatory transport protocol, because this will quickly lead to DLEP radios and routers that are standard compliant and incompatible with each other. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com --_000_B177F831FB91F242972D0C35F6A0733105BA07E1SUCNPTEXM01coma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Brian, I tried t= o start a breakdown of requirements, see my email to the list entitled R= 20;DLEP message classification”.

 

I agree that the= re are situations where the radio and router may be connected by a non-IP m= edium, e.g. a PCI bus.

 

Rick Taylor

 

From:= Brian Adamson [mailto:brian.adamson@nrl.navy.mil]
Sent: 12 August 2013 16:50 To: Taylor, Rick
Cc: Henning Rogge; Juliusz C= hroboczek; manet@ietf.org
Subject: Re: [manet] DLEP an= d TCP

 

I mostly concur with the recommendation here(e.g. st= rive to let DLEP work on top of different physical/logical media) , but thi= nk the DLEP specification should clearly indicate what its requirements for the underlying transport & intercon= nect are in terms of:

 

1) ordered message delivery

2) reliability

3) adaptive (e.g. dynamic congestion control) or pre= set transfer rate, or both

4) flow control 

5) Any DLEP transport session parameters that need t= o be established

6) Automated discovery (e.g. similar to what PPPoE c= an do but using mDNS, uPNP or something?)

 

There will likely be different message bus technolog= ies that might be suitable for handling DLEP requirements.  

 

The one concern here is to do this in a way that doe= sn't defeat interoperability.  I.e., some minimal common mechanism sho= uld be mandated.

 

= Brian = Adamson

=  =

=

 

On Aug 12, 2013, at 4:39 AM, Taylor, Rick wrote:



I'm entirely with Henning on this one.  The cor= e DLEP spec should specify something along the lines of:

* A DLEP implementation MUST support TCP if the radio to router interface u= ses IP.

* A DLEP implementation using TCP SHOULD disable Nagle.

* A DLEP implementation MAY advertise an alternative/improved transport pro= tocols (in some non-core defined extension TBD) and these transport protoco= ls MUST be reliable (do we need to define 'reliable' or is there an RFC tha= t covers our requirements?).

I understand that some people may have concerns over congestion and flow-co= ntrol over the router<->radio link, but in the common case it is expe= cted that that link will be faster than the radio<->radio interface b= y enough to negate the concerns.

If the radio<->router link becomes an issue, then an alternative tran= sport MAY be used by supporting equipment, but it remains a problem for hig= h-speed device implementers.

Even if the radio<->radio link characteristics begin to approach the = characteristics of the radio<->radio link, there is nothing to stop t= he radio and/or router reducing the frequency of DLEP control messages to p= revent interference with the data-flow over the radio<->radio link.

It is not expected with DLEP that protocol messages are exchanged so rapidl= y that a 10M Ethernet link is flooded, and most (all?) radio and router man= ufacturers already have embedded controllers on-board that can support fast= er than 10M on copper. We are not discussing a 9600 baud link between radio and router.

Rick Taylor


-----Original Message-----

From: manet-bounces@ietf.org [mailt= o:manet-bounces@ietf.org] On Behalf Of

Henning Rogge

Sent: 12 August 2013 07:58

To: Juliusz Chroboczek

Cc: manet@ietf.org

Subject: Re: [manet] DLEP and TCP

 

On 08/12/2013 01:40 AM, Juliusz Chroboczek wrote:

The point on using something simple is that it is NO= T the job of the

DLEP protocol to solve the transport problems. If yo= u have a special

link between radio and router, just use a better tra= nsport

protocol. DLEP should not care as long as the transp= ort is reliable.

 

I think that's a good point.  It would mean tha= t the discovery

subprotocol should be powerful enough to express som= ething like "I can

speak DLEP/TCP on port 1234, but also DLEP/DCCP on p= ort 4567 and

DLEP/UDP-based-reliable-protocol-of-the-day over por= t 7890".

 

We could add this in an extension draft.

 

We make TCP mandatory for every DLEP implementation = (both radio and

router), but create a new TLV (in another draft, not= in the core

document) where a radio announce "you can also = use transport protocol X

on port Y". The router then can decide what to = use to contact the radio.

 

This would gives us an upgrade-path for special case= s without bloating

the core document.

 

I am totally against NOT having a mandatory transpor= t protocol, because

this will quickly lead to DLEP radios and routers th= at are standard

compliant and incompatible with each other.

 

Henning Rogge

 

--

Diplom-Informatiker Henning Rogge , Fraunhofer-Insti= tut f=FCr

Kommunikation, Informationsverarbeitung und Ergonomi= e FKIE

Kommunikationssysteme (KOM)

Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany

Telefon +49 228 9435-961,   Fax +4= 9 228 9435 685

= mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de=


The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cas= sidian.com --_000_B177F831FB91F242972D0C35F6A0733105BA07E1SUCNPTEXM01coma_-- From rick.taylor@cassidian.com Tue Aug 13 01:26:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8835C21F9F13 for ; Tue, 13 Aug 2013 01:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=1.930, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE14AzHIEMKb for ; Tue, 13 Aug 2013 01:25:59 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 85C0421F9E05 for ; Tue, 13 Aug 2013 01:25:58 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 13 Aug 2013 10:25:45 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 13 Aug 2013 10:25:44 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Aug 2013 10:25:44 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Aug 2013 10:25:44 +0200 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 09:25:43 +0100 From: "Taylor, Rick" To: Teco Boot , "Stan Ratliff (sratliff)" Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOl+Lu5wubj40FSEO/Z64zZmA+m5mSzUog Date: Tue, 13 Aug 2013 08:25:43 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <87d2pig8fy.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0740@xmb-aln-x03.cisco.com> <8761vag20x.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F0B01@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2013 08:25:44.0086 (UTC) FILETIME=[B4301360:01CE97FE] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-20078.005 X-TM-AS-Result: No--47.884200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "" , Juliusz Chroboczek Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 08:26:04 -0000 +1 for heartbeats remaining. BGP shows that they are still needed even whe= n running over TCP. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Teco Boot > Sent: 13 August 2013 06:07 > To: Stan Ratliff (sratliff) > Cc: ; Juliusz Chroboczek > Subject: Re: [manet] DLEP and TCP > > > Op 12 aug. 2013, om 21:32 heeft "Stan Ratliff (sratliff)" > het volgende geschreven: > > > > > On Aug 12, 2013, at 3:08 PM, Juliusz Chroboczek diderot.fr> wrote: > > > >>>>> 1. The link between router and radio is *always* local... > >>>>> 2. The link between router and radio will *always* be faster... > >> > >>>> Assuming these assumptions always hold in normal usage of DLEP -- > >>>> is it acceptable for DLEP to collapse when they do not? Should it > >>>> be able to recover in a timely manner when the conditions are met > >>>> once again? > >> > >>> A couple of observations. First, the obvious answer to your > >>> questions are "no" and "yes", respectively. > >> > >> Yeah, they were rigged ;-) > > > > Yes. To the point that my initial reaction was to consider your email a= s > not serious, and therefore, to not respond. > > > >> > >>> Second, I'm not sure we've discussed a case yet where DLEP would > "collapse" > >> [...] > >>> Is there a case I'm missing? > >> > >> TCP will buffer DLEP updates even when the router-radio link is > >> hopelessly congested or down. When the link is operational again, new > >> updates will be sent only after TCP times out (which can take up to 30 > >> seconds, if memory serves) and the buffers drain (which can take an > >> arbitrarily large amount of time unless the amount of buffering is > >> carefully controlled). We're probably speaking of a worst case of at > >> least a couple of minutes in a naive implementation. > > > > A "couple of minutes" bumps into the routing protocol's Dead Timer (eve= n > with a naive implementation of the Dead Timer), so... > > > > Keeping the application-level Heartbeat message in the specification > would allow an implementation to detect the problem faster. It might seem > like overkill at first blush, but I think there's some merit to keep it, > even over TCP. > > Sure we keep the heartbeats. I would like to see a fresh TCP connection i= n > seconds rather than minutes. The new connection will reset state machines= , > so neighbors go down and up. > > Teco > > > > > Stan > > > >> > >> I'm pretty sure that can be reduced to well under one minute (without > >> kernel changes) by carefully controlling the size of the TCP buffers > >> with non-blocking writes, using application-layer keepalives with > >> short timeouts, and probably other tricks. Is doing that properly any > >> easier than implementing a well-designed protocol layered over UDP? > >> I don't know, since, while I have a fair amount of experience with > >> implementing stuff over UDP, I don't have any with implementing > >> real-time protocols over TCP. > >> > >> -- Juliusz > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From rick.taylor@cassidian.com Tue Aug 13 01:33:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766CB21E80EB for ; Tue, 13 Aug 2013 01:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvGvNoPBxfpi for ; Tue, 13 Aug 2013 01:33:37 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6E39B21E80E6 for ; Tue, 13 Aug 2013 01:33:37 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 13 Aug 2013 10:33:36 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 13 Aug 2013 10:33:35 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Aug 2013 10:33:35 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Aug 2013 10:33:35 +0200 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 09:33:34 +0100 From: "Taylor, Rick" To: Henning Rogge , "Stan Ratliff (sratliff)" Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOl3aF5wubj40FSEO/Z64zZmA+m5mSzomw Date: Tue, 13 Aug 2013 08:33:33 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2013 08:33:35.0752 (UTC) FILETIME=[CD529880:01CE97FF] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-20078.005 X-TM-AS-Result: No--8.244500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 08:33:42 -0000 > > 1. The link between router and radio is *always* local (e.g. the radio > is the next hop), and > > If DLEP use linklocal multicast for discovery it will not work for > more than one (IP) hop anyways. Also sending bridged traffic over > multiple IP hops will require some kind of tunnel, which should be out > of scope for the DLEP core spec. > > Using multiple layer-2 hops might work, as long as you keep the total > datarate in mind. Connecting multiple slow radios over a single > gigabit ethernet switch to the router might work, but it would still > need either a manageable switch (VLANs to select to outgoing ports) or > some crazy trickery with the traffic. > I was working under the assumption that the radio and router were *always* = local and in a one-to-one relationship. As stated before, discovery become= s extremely complex with one-to-many radios to routers and switches. Also,= describing neighbours by their L2 address becomes 'unusual' in a one-to-ma= ny case. I would recommend staying away from the complex switched case, and specifyi= ng something like 'a logical 1-hop connection between radio and router is r= equired'. Rick Taylor The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From henning.rogge@fkie.fraunhofer.de Tue Aug 13 05:05:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1538011E814D for ; Tue, 13 Aug 2013 05:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXVg3d0un27B for ; Tue, 13 Aug 2013 05:05:03 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 87F0711E813B for ; Tue, 13 Aug 2013 05:05:03 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V9DLR-0000hg-NC for manet@ietf.org; Tue, 13 Aug 2013 14:05:01 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V9DLR-0001NT-KD for manet@ietf.org; Tue, 13 Aug 2013 14:05:01 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 13 Aug 2013 14:05:01 +0200 Message-ID: <520A20E9.7090101@fkie.fraunhofer.de> Date: Tue, 13 Aug 2013 14:04:57 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010102030909060704060905" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17675/Tue Aug 13 09:32:11 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c9c66f32f18f586296172d92028f39d6 Subject: [manet] DLEP flow control scheme on shared medium radio X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:05:09 -0000 --------------ms010102030909060704060905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I have been looking at the DLEP flow control mechanism and wonder how to = make it work on a radio with a shared medium. Instead of having a queue for each neighbor, radios with a shared medium = might have only a single queue in total (or maybe one per layer-2 priorit= y). How can we support this with the DLEP flow control? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010102030909060704060905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MTMxMjA1MDBaMCMGCSqGSIb3DQEJBDEWBBSTNgu+wDNZR6jJvEMtWQ09quU45zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAnYZ965E6f2k7sbi0LbT7y1ydhSDO/D/gk/K65RNvEWnE H3kG65DCI/BqLas6uxjmpzlNmdGuCG/bAJTnIe1v2FdVrtU7OiVdvmyQoEemGSXzuSevNJpK NQ/4SaFNgXlduxaXkSO3eKlzrX2GkLrCAEOQkav83kdbFJ8dxaA6RqEd7bryCvG8lbq4Glk1 jxv5s0mr0Y4vG2C/E3yZV4FXdGMGZW19BNb7nuN38EOQIBXlIpt+s7axnUA5MSD6T1glPENG A75FqGmxUgqp1hF082zkuwEgWEa5VdrA+tjr05wNVasJXL2CgQp3SnDckQ2YDnggaQQvUcL2 d4tUUrvylQAAAAAAAA== --------------ms010102030909060704060905-- From Martin.Duke@boeing.com Tue Aug 13 08:34:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A225F11E8184 for ; Tue, 13 Aug 2013 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0Pshlub1ANE for ; Tue, 13 Aug 2013 08:34:48 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 674B211E80E8 for ; Tue, 13 Aug 2013 08:34:48 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r7DFYh9w021779 for ; Tue, 13 Aug 2013 08:34:44 -0700 Received: from XCH-PHX-311.sw.nos.boeing.com (xch-phx-311.sw.nos.boeing.com [130.247.25.171]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r7DFYfuC021753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 13 Aug 2013 08:34:42 -0700 Received: from XCH-BLV-503.nw.nos.boeing.com ([169.254.3.226]) by XCH-PHX-311.sw.nos.boeing.com ([169.254.11.63]) with mapi id 14.02.0328.011; Tue, 13 Aug 2013 08:34:44 -0700 From: "Duke, Martin" To: "henning.rogge@fkie.fraunhofer.de" , "manet@ietf.org" Thread-Topic: [manet] DLEP flow control scheme on shared medium radio Thread-Index: AQHOmB1rFnFZ7NeZ40mNEoZfrnOOe5mTQ/uw Date: Tue, 13 Aug 2013 15:34:43 +0000 Message-ID: <5A8A5085482DA84995F4E70F5093AB50254298@XCH-BLV-503.nw.nos.boeing.com> References: <520A20E9.7090101@fkie.fraunhofer.de> In-Reply-To: <520A20E9.7090101@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [manet] DLEP flow control scheme on shared medium radio X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 15:34:53 -0000 I concur -- it would be easy enough to allow flow control TLVs in peer upda= te messages if the context is appropriate. -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: Tuesday, August 13, 2013 5:05 AM To: manet@ietf.org Subject: [manet] DLEP flow control scheme on shared medium radio Hi, I have been looking at the DLEP flow control mechanism and wonder how to ma= ke it work on a radio with a shared medium. Instead of having a queue for each neighbor, radios with a shared medium mi= ght have only a single queue in total (or maybe one per layer-2 priority). How can we support this with the DLEP flow control? Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation= , Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) F= raunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From hrogge@googlemail.com Tue Aug 13 08:54:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1C421F9C81 for ; Tue, 13 Aug 2013 08:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a59DJJy+ODT for ; Tue, 13 Aug 2013 08:54:43 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E50E221F93E1 for ; Tue, 13 Aug 2013 08:54:17 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so4444327qeb.15 for ; Tue, 13 Aug 2013 08:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=02G2EZ6EqS+6rBuDo9ZykxNPUn9YX7qyVA39J77Rt00=; b=F685JdXv0m+UJ0TOKw7irbpukyhof28sxDfmF3mrpC0JKthiNINna/f9YROX/lFcNC gMa+pddpWBa6Qpr9/SYQ/SUOBJXTPV/Pobg9OxApFNVvZag8pVrul1Nv/9D/bW0/tj1S D79PqFCgfnFlXCgpPybtP6M/HFvYJGE0AbWnw2kJKd6v4cle//IHpMx2dI6hrL31Xbuj e7S5vymrPItyjCev2S/aeJqh29rN2IJQtgFFDKpPhj36oxUkHJKToddyYahhUZ5XXU7A oaVqwUtXnehMUCcG8q1ppRUO6V9DBIVgjRl1vjeE2ht4il0anir2+GCBS/nG9VeIW4eR b0cg== X-Received: by 10.229.63.198 with SMTP id c6mr921339qci.59.1376409257255; Tue, 13 Aug 2013 08:54:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.203.7 with HTTP; Tue, 13 Aug 2013 08:53:57 -0700 (PDT) In-Reply-To: <5A8A5085482DA84995F4E70F5093AB50254298@XCH-BLV-503.nw.nos.boeing.com> References: <520A20E9.7090101@fkie.fraunhofer.de> <5A8A5085482DA84995F4E70F5093AB50254298@XCH-BLV-503.nw.nos.boeing.com> From: Henning Rogge Date: Tue, 13 Aug 2013 17:53:57 +0200 Message-ID: To: "Duke, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] DLEP flow control scheme on shared medium radio X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 15:54:44 -0000 Without DLEP flow control its practically impossible to run QoS on the router when connected to an external radio. We could just activate "fq-codel", but that would still kill priorization. Henning Rogge On Tue, Aug 13, 2013 at 5:34 PM, Duke, Martin wrot= e: > I concur -- it would be easy enough to allow flow control TLVs in peer up= date messages if the context is appropriate. > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Henning Rogge > Sent: Tuesday, August 13, 2013 5:05 AM > To: manet@ietf.org > Subject: [manet] DLEP flow control scheme on shared medium radio > > Hi, > > I have been looking at the DLEP flow control mechanism and wonder how to = make it work on a radio with a shared medium. > > Instead of having a queue for each neighbor, radios with a shared medium = might have only a single queue in total (or maybe one per layer-2 priority)= . > > How can we support this with the DLEP flow control? > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikati= on, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM)= Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From chris.dearlove@baesystems.com Wed Aug 14 02:38:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797FB21E808E for ; Wed, 14 Aug 2013 02:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.547 X-Spam-Level: X-Spam-Status: No, score=-9.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF3VRhc37OQq for ; Wed, 14 Aug 2013 02:37:58 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 729A121E8090 for ; Wed, 14 Aug 2013 02:37:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,876,1367967600"; d="scan'208";a="364235970" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 14 Aug 2013 10:37:55 +0100 X-IronPort-AV: E=Sophos;i="4.89,876,1367967600"; d="scan'208";a="24392301" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 14 Aug 2013 10:37:55 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.167]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Wed, 14 Aug 2013 10:37:55 +0100 From: "Dearlove, Christopher (UK)" To: "Taylor, Rick" , Henning Rogge , "Stan Ratliff (sratliff)" Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOl3aFDWOpIqYY+Uy8o0+IQ/ULg5mSzomwgAGlA2A= Date: Wed, 14 Aug 2013 09:37:54 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 09:38:02 -0000 Sooner or later, someone is going to suggest replacing the ethernet cable b= etween the two by a wireless link, probably based on some version of 802.11= . Maybe not in the sorts of networks some of us are interested in, but in s= ome networks. (That's not meant to be an argument for or against any specific proposal, j= ust something to consider.) -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= aylor, Rick Sent: 13 August 2013 09:34 To: Henning Rogge; Stan Ratliff (sratliff) Cc: Subject: Re: [manet] DLEP and TCP ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- > > 1. The link between router and radio is *always* local (e.g. the radio > is the next hop), and > > If DLEP use linklocal multicast for discovery it will not work for > more than one (IP) hop anyways. Also sending bridged traffic over > multiple IP hops will require some kind of tunnel, which should be out > of scope for the DLEP core spec. > > Using multiple layer-2 hops might work, as long as you keep the total > datarate in mind. Connecting multiple slow radios over a single > gigabit ethernet switch to the router might work, but it would still > need either a manageable switch (VLANs to select to outgoing ports) or > some crazy trickery with the traffic. > I was working under the assumption that the radio and router were *always* = local and in a one-to-one relationship. As stated before, discovery become= s extremely complex with one-to-many radios to routers and switches. Also,= describing neighbours by their L2 address becomes 'unusual' in a one-to-ma= ny case. I would recommend staying away from the complex switched case, and specifyi= ng something like 'a logical 1-hop connection between radio and router is r= equired'. Rick Taylor The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Wed Aug 14 03:27:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D58211E814C for ; Wed, 14 Aug 2013 03:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHxEBu44WHMM for ; Wed, 14 Aug 2013 03:27:31 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A664F11E8110 for ; Wed, 14 Aug 2013 03:27:30 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V9YIa-0004Ur-3s for manet@ietf.org; Wed, 14 Aug 2013 12:27:28 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V9YIa-0004hB-0s for manet@ietf.org; Wed, 14 Aug 2013 12:27:28 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 14 Aug 2013 12:27:28 +0200 Message-ID: <520B5B8A.10907@fkie.fraunhofer.de> Date: Wed, 14 Aug 2013 12:27:22 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000901080709010409040409" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17678/Wed Aug 14 09:47:37 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a22a8819f20226a2167e46b22584aa1b Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 10:27:36 -0000 --------------ms000901080709010409040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 08/14/2013 11:37 AM, Dearlove, Christopher (UK) wrote: > Sooner or later, someone is going to suggest replacing the ethernet > cable between the two by a wireless link, probably based on some > version of 802.11. Maybe not in the sorts of networks some of us are > interested in, but in some networks. If this happens we can suggest they this person creates a draft with an=20 appropriate transport protocol for DLEP. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000901080709010409040409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA4MTQxMDI3MjZaMCMGCSqGSIb3DQEJBDEWBBRV3J0/t6W7Z4fYbnz0gnAAyJ0IBjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAtNvJmAro/Jc9mfELBsKfQgifrnN5hfph9Ao/ndgJpK3D 4DBBXvUMW9Gh+nGUp/BEOSZYL4e5bkk8uz4OrvEqV36Uk/bphI9OKgRUJSdMb4qhhG5NEbDl hLMUFMSVZY2bBv1kTpYZPbHMqesnNcRJOxwLSHiPodQClSx+ZfNHTH6zWzYoj5oV2pwkzZyt rs/8g/DPcw2xEguLjGDzx7AlAeHUtmFmGrD7Keky4WBIdszMRSxhyyCSxJu5IC5JUcuBEQ6T c/VVlnf+bJZry0iC5jh4yE2WNqqQZ0E94aEl4DZzsjx7CIbz+xN15z6bYEsD8uMgAAf/bEME 4dtO3zAKqwAAAAAAAA== --------------ms000901080709010409040409-- From chris.dearlove@baesystems.com Wed Aug 14 03:46:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E4911E8122 for ; Wed, 14 Aug 2013 03:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dW874BSv1p-Y for ; Wed, 14 Aug 2013 03:46:34 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 487C811E811E for ; Wed, 14 Aug 2013 03:46:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,876,1367967600"; d="scan'208";a="306689087" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Aug 2013 11:46:33 +0100 X-IronPort-AV: E=Sophos;i="4.89,876,1367967600"; d="scan'208";a="25362099" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 14 Aug 2013 11:46:33 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.167]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0328.009; Wed, 14 Aug 2013 11:46:33 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOl3aFDWOpIqYY+Uy8o0+IQ/ULg5mSzomwgAGlA2D///58AIAAFUDQ Date: Wed, 14 Aug 2013 10:46:32 +0000 Message-ID: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> <520B5B8A.10907@fkie.fraunhofer.de> In-Reply-To: <520B5B8A.10907@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 10:46:38 -0000 The person who does this probably isn't even going to know DLEP exists, let= alone consider submitting Internet Drafts. They'll just replace an etherne= t cable. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 14 August 2013 11:27 To: manet@ietf.org Subject: Re: [manet] DLEP and TCP On 08/14/2013 11:37 AM, Dearlove, Christopher (UK) wrote: > Sooner or later, someone is going to suggest replacing the ethernet > cable between the two by a wireless link, probably based on some > version of 802.11. Maybe not in the sorts of networks some of us are > interested in, but in some networks. If this happens we can suggest they this person creates a draft with an = appropriate transport protocol for DLEP. Henning Rogge -- = Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Wed Aug 14 03:47:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CF211E81AB for ; Wed, 14 Aug 2013 03:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOU1fcLv+aPl for ; Wed, 14 Aug 2013 03:47:13 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id B83A211E81A9 for ; Wed, 14 Aug 2013 03:47:12 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e53so4389293eek.13 for ; Wed, 14 Aug 2013 03:47:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ppA3gdDXa6pbhactINIUErI8tfUbCPSEXNvztNV7xJo=; b=H1ZFspP1MOoUPSUcTShsLM8nW0x6df5v2zhT0R3y0KPga0V12epjoJlZ7ViRp5tDhf 4CgEgBMqUz1jazwK7ZdhqMoY+LakunZ9C4lwIPBmJwxLiIFa7VT2xJIH9c4ZUEmYKsnA c3qoNqqkf3sBH6FbAlTd+KhMxOPM65CliiwHuRsy25apqhEIzDZQfWg2gFekd40scSEV OLvoRMfgnpq2b3fa/M0+9yTEOQ5vyAj9tTVbeoQAEwg4hQ0IgJjAYNuPmwwBSnEc2e6u CrPS3zE5Fs6OlFWUBo2PQaLgKJL+w3e8IvhzIoC8VH8tFjTF8BYC0kbXPsERdS4bSrbB k3LA== X-Gm-Message-State: ALoCoQlrJrQwsbl0De1R+IxjcQDzK76LvENzzZqkcwXo2+6yMEByr2JHZ1MtFtpX0bDKhCZzfofs X-Received: by 10.14.218.5 with SMTP id j5mr123590eep.134.1376477231797; Wed, 14 Aug 2013 03:47:11 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id f49sm68396292eec.7.2013.08.14.03.47.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 03:47:10 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <520B5B8A.10907@fkie.fraunhofer.de> Date: Wed, 14 Aug 2013 12:47:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> <520B5B8A.10907@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1508) Cc: manet@ietf.org Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 10:47:17 -0000 Op 14 aug. 2013, om 12:27 heeft Henning Rogge = het volgende geschreven: > On 08/14/2013 11:37 AM, Dearlove, Christopher (UK) wrote: >> Sooner or later, someone is going to suggest replacing the ethernet >> cable between the two by a wireless link, probably based on some >> version of 802.11. Maybe not in the sorts of networks some of us are >> interested in, but in some networks. >=20 > If this happens we can suggest they this person creates a draft with = an appropriate transport protocol for DLEP. I wonder if this is needed. As long as the peer RF link has enough = capacity for DLEP, it is OK. Also, a low rate wired link could be a = bottleneck (USB1.1 to 802.11ac radio). Or an ethernet bridge with low = rate wired links (which I use), for example to connect a satcom terminal = on somewhat longer distance with a router (I don't do that right now). Teco >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Wed Aug 14 07:15:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1DF11E8175 for ; Wed, 14 Aug 2013 07:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjSp-G-BMyib for ; Wed, 14 Aug 2013 07:15:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E80F421F9E40 for ; Wed, 14 Aug 2013 07:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2013; q=dns/txt; s=iport; t=1376489711; x=1377699311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GLHnuI+VkcL/UcDlUVsDB4OwJzl92xK82tpKluWVSS8=; b=YarvN6iGmbEaSpq3qHk8dajtDtFQbIzqv0l7NqNAhrQQBK7VZljbitd6 LeV8Tk2+7lPVph0oAI2vpcNEzQiUCmo1tYXQ/Cop0IjV9a0+hQcGBvI6d LYadhIY2zLcgKcSIhd548LnFM78Tv6p+ax9NReYWvDS0jlFC6SozCJuwU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFADyQC1KtJV2a/2dsb2JhbABbgwY1UL5lgSMWdIIkAQEBAwEBAQFrCxACAQgYCh0HJwsUEQIEDgUIiAIGDLkbkB0CMQeDG3cDqTaDG4Iq X-IronPort-AV: E=Sophos;i="4.89,877,1367971200"; d="scan'208";a="247308753" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 14 Aug 2013 14:15:09 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7EEF94q002550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 14:15:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 09:15:08 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOl3aFhqeH9HMbGU+WXMCShCPLOJmSzomwgAH6QgCAAA3SAIAABYKAgAA6JYA= Date: Wed, 14 Aug 2013 14:15:08 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F2505@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> <520B5B8A.10907@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="Windows-1252" Content-ID: <80CFD7FA44024543AC6C34C100872B9F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:15:16 -0000 As long as we're (still) talking about low-rate router-to-radio links, and = DLEP=85.=20 What if I take a router, stick a cable into a FastEthernet port, and run th= e other end to a MIMO radio? At least in theory, methinks the RF link is no= w faster than the Ethernet cable=85 Regards, Stan On Aug 14, 2013, at 6:47 AM, Teco Boot wrote: >=20 > Op 14 aug. 2013, om 12:27 heeft Henning Rogge het volgende geschreven: >=20 >> On 08/14/2013 11:37 AM, Dearlove, Christopher (UK) wrote: >>> Sooner or later, someone is going to suggest replacing the ethernet >>> cable between the two by a wireless link, probably based on some >>> version of 802.11. Maybe not in the sorts of networks some of us are >>> interested in, but in some networks. >>=20 >> If this happens we can suggest they this person creates a draft with an = appropriate transport protocol for DLEP. >=20 > I wonder if this is needed. As long as the peer RF link has enough capaci= ty for DLEP, it is OK. Also, a low rate wired link could be a bottleneck (U= SB1.1 to 802.11ac radio). Or an ethernet bridge with low rate wired links (= which I use), for example to connect a satcom terminal on somewhat longer d= istance with a router (I don't do that right now). >=20 > Teco >=20 >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Aug 14 07:41:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B9011E81EB for ; Wed, 14 Aug 2013 07:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0fo0k3CZBiz for ; Wed, 14 Aug 2013 07:41:27 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id C970C21F9A06 for ; Wed, 14 Aug 2013 07:41:27 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id k15so4871910qcv.26 for ; Wed, 14 Aug 2013 07:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=pdddxF2cf+2kWxmAR7Odvc3C4TMGGN5O6ORNlLhaijk=; b=ryzlqoB5IsN4vo2nOoGEj75cyGzY63/9VBG199diuPr9ohOw/tuJT/UK0FVvFAGZzE i6bAoLk5kQdEK7x2tWDQOlDJYUMzDxDMNzhQd1Zqg7oi4GwbRADV2xYLclF5ay4xd946 mbbqR8XJ9sa2k/FPVvnHfFORpnqeBy800M2++dtkNMA1qX3NbSJLbiolrG22Mb/bKLeJ 7tWhWGtm1fmlSZXLDJwUCbhdBXWMXTMxzu8zLmhpEfKtTkvrctcTACyQdYKknqnXNWm9 agcrUFTOk71Dkkx8xBbnztCAaE/XMwwN3SfWA0gxGsFQEr0eE1KQBBAreeEMhaQHMZH4 MvcA== X-Received: by 10.224.45.69 with SMTP id d5mr2631102qaf.108.1376491287254; Wed, 14 Aug 2013 07:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.203.7 with HTTP; Wed, 14 Aug 2013 07:41:06 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F2505@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> <520B5B8A.10907@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F2505@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Wed, 14 Aug 2013 16:41:06 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:41:28 -0000 On Wed, Aug 14, 2013 at 4:15 PM, Stan Ratliff (sratliff) wrote: > As long as we're (still) talking about low-rate router-to-radio links, an= d DLEP=85. > > What if I take a router, stick a cable into a FastEthernet port, and run = the other end to a MIMO radio? At least in theory, methinks the RF link is = now faster than the Ethernet cable=85 yes, it would be. But you could not use the full capacity of the RF link anymore because you added an artificial bottleneck. Henning Rogge --=20 We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From sratliff@cisco.com Wed Aug 14 07:47:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F0C11E8169 for ; Wed, 14 Aug 2013 07:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNNUl7EQf2YM for ; Wed, 14 Aug 2013 07:47:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBC221E8093 for ; Wed, 14 Aug 2013 07:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1311; q=dns/txt; s=iport; t=1376491622; x=1377701222; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xs4oHMafNBw9PR9ij5RqZA/omOc4Fo4I1XwuO3vV1TA=; b=cXyGsMq9K0HG6tBc0EVpUhOvo3C930jFkjQes6go04PKBy5SF2wDpU3M DOheNibMikMc4lnk2+4Fk+CPTSOt5m+jwG+6SYMdof8HSaf2KeN+5CCnH k56c823lDSkWaH9Zrh+MMBzzb5IphvYSehqRdl4TVPi4fOk+hSdrC6ZgW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAESXC1KtJXG9/2dsb2JhbABbgwY1UL5lgSMWdIIkAQEBAwEBAQFrCwULAgEIDgoKJCcLJQIEDgUIh3YDCQYMsD0NiFoEjVWCSAIxB4MbdwOpNoMbgio X-IronPort-AV: E=Sophos;i="4.89,877,1367971200"; d="scan'208";a="247236186" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 14 Aug 2013 14:47:01 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7EEl0Rl012425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 14:47:00 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 09:47:00 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] DLEP and TCP Thread-Index: AQHOl3aFhqeH9HMbGU+WXMCShCPLOJmSzomwgAH6QgCAAA3SAIAABYKAgAA6JYCAAAc+AIAAAaYA Date: Wed, 14 Aug 2013 14:47:00 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F28BA@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> <520B5B8A.10907@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F2505@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6194049AA19FA246B80199302C3A3B7E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:47:07 -0000 That's absolutely true for outbound traffic. However, the RF could be maxim= ally used for inbound traffic, thus creating the congested router-to-radio = link we've been theorizing on=85 My point is that overloading the router-to-radio link isn't as hard as I in= itially thought - in fact, it's pretty straightforward... Regards, Stan On Aug 14, 2013, at 10:41 AM, Henning Rogge wrote: > On Wed, Aug 14, 2013 at 4:15 PM, Stan Ratliff (sratliff) > wrote: >> As long as we're (still) talking about low-rate router-to-radio links, a= nd DLEP=85. >>=20 >> What if I take a router, stick a cable into a FastEthernet port, and run= the other end to a MIMO radio? At least in theory, methinks the RF link is= now faster than the Ethernet cable=85 >=20 > yes, it would be. But you could not use the full capacity of the RF > link anymore because you added an artificial bottleneck. >=20 > Henning Rogge >=20 > --=20 > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Aug 14 07:50:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DB411E8169 for ; Wed, 14 Aug 2013 07:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtZK-gUqMEyW for ; Wed, 14 Aug 2013 07:50:17 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 88F0611E8165 for ; Wed, 14 Aug 2013 07:50:17 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id j10so4920207qcx.39 for ; Wed, 14 Aug 2013 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/nyMt2mtZTP81pPDUMW7XJ6Ipw1WwNZcySVnkw2x/j8=; b=gV28YidKsmguPEbW//l2k2/uywXjgrTOhHowLX/jq9Ex25H+KKR0B9ZFysFto93n6j UmEBkUjtRguTi7VJSi0H7ZJPm5gqYSC/0Al4TYSeAQJKTaMTx2sGraFAowLC8KHE4JmJ /W/1oAhS5nLd7i65IlJNoxCCLYyoeKP68Ixi9VxS4RiDmpbMO2wbanKevkjCc/GjFIjg ekKC5/0TDOpZtNjk7Vdwm0CTV9hJJT83zuI1j88qvFU/vYYtIi4eWGGMyNY1aFUzFYMp xlaTJ4qWsrJAXMkriWzj+X35Kh9781uOh8JDD4VU+8AM816YMiOo7jWQ/rxJIEbg19tW YSgA== X-Received: by 10.49.1.166 with SMTP id 6mr11878885qen.65.1376491815701; Wed, 14 Aug 2013 07:50:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.203.7 with HTTP; Wed, 14 Aug 2013 07:49:55 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F28BA@xmb-aln-x03.cisco.com> References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> <520B5B8A.10907@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F2505@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F28BA@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Wed, 14 Aug 2013 16:49:55 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:50:18 -0000 As long as the radio prioritize the DLEP traffic on the Ethernet link this might still be okay. Not perfect, but not a catastrophe either. Maybe we should add this into the suggestions/best-practice part of the dra= ft? Henning Rogge On Wed, Aug 14, 2013 at 4:47 PM, Stan Ratliff (sratliff) wrote: > That's absolutely true for outbound traffic. However, the RF could be max= imally used for inbound traffic, thus creating the congested router-to-radi= o link we've been theorizing on=85 > > My point is that overloading the router-to-radio link isn't as hard as I = initially thought - in fact, it's pretty straightforward... > > Regards, > Stan > > > On Aug 14, 2013, at 10:41 AM, Henning Rogge wrote= : > >> On Wed, Aug 14, 2013 at 4:15 PM, Stan Ratliff (sratliff) >> wrote: >>> As long as we're (still) talking about low-rate router-to-radio links, = and DLEP=85. >>> >>> What if I take a router, stick a cable into a FastEthernet port, and ru= n the other end to a MIMO radio? At least in theory, methinks the RF link i= s now faster than the Ethernet cable=85 >> >> yes, it would be. But you could not use the full capacity of the RF >> link anymore because you added an artificial bottleneck. >> >> Henning Rogge >> >> -- >> We began as wanderers, and we are wanderers still. We have lingered >> long enough on the shores of the cosmic ocean. We are ready at last to >> set sail for the stars - Carl Sagan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > --=20 We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From teco@inf-net.nl Wed Aug 14 08:10:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51EB11E8165 for ; Wed, 14 Aug 2013 08:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sYNqbGzPuUI for ; Wed, 14 Aug 2013 08:10:05 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60A3E11E814C for ; Wed, 14 Aug 2013 08:10:04 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id r16so4943491ead.3 for ; Wed, 14 Aug 2013 08:10:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=x8CuFU078Jo6tgyjmSG2AR3NigB3OSD2uzjuFPFxRj4=; b=ivO0+QI5YRDIy5fNBFBQrXdFmIA+aGkdjuYmeqveFSQi9IDoAQsLTnYaPCRqT1ZiXC ziivOfB3WC6YqYLd6jY5bGcNe8TesEdGoEZd7RUybpxU60ggXq5HY72bET87iY5cct/E zDLYErPBFi6hR3o2dl3b7EohYY9WdWwBpWH8mmcjd7v3bHadlLYMtE03Mqo6gJQFXBU4 nK3gcCWZSnmnDplbhgcplc9HGIOrB6qY2aTEcszbCMDnYHfAzyw0pmK3Dzx/x2Jd0l37 qY27Cre3HvpWjFEoM3k4iZK7skTJGpV07vF4bUJbqKUrKoxwgMze7fD9fOD1LaeAixr5 atxA== X-Gm-Message-State: ALoCoQnXsHamnKwtykn7dKaJuleTHUtcSBEwdJ+gmvqhyo5LeD4d9NktTH2i2HMv2ZF86XALk3um X-Received: by 10.14.210.8 with SMTP id t8mr15315847eeo.39.1376493003324; Wed, 14 Aug 2013 08:10:03 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id a1sm75865861eem.1.2013.08.14.08.10.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 08:10:02 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Wed, 14 Aug 2013 17:09:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87y58dtzy9.wl%jch@pps.univ-paris-diderot.fr> <2ED1D3801ACAAB459FDB4EAC9EAD090C101ECD89@xmb-aln-x03.cisco.com> <1375981185.17678.202.camel@localhost> <527910C0-992E-4E6C-8411-EE4EB3F7B597@inf-net.nl> <87haevol4p.wl%jch@pps.univ-paris-diderot.fr> <5208860F.4010906@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101EFD45@xmb-aln-x03.cisco.com> <78afe125-903e-4ec1-82a5-3790a37197e0@SUCNPTEXC01.COM.AD.UK.DS.CORP> <520B5B8A.10907@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F2505@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C101F28BA@xmb-aln-x03.cisco.com> To: Henning Rogge , "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1508) Cc: manet@ietf.org Subject: Re: [manet] DLEP and TCP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:10:10 -0000 The bloody user traffic.... Back to starting point: DLEP router radio link should (must?) have = higher capacity than RF link. It doesn't matter if it is ethernet, = 802.11-something or whatever. My suggested rule of thumb: 4 times = maximum rate on RF. Router would know MDR and DLEP interface, so it = could log a message if conditions are not as specified. Now what would happen when there is (temporary) congestion on the router = radio link. I would say that is one of the unimportant discussions. And = that most of DLEP is not really affected. Transfer of link metrics can = tolerate some delay, I think. For flow control, the effect might be = unused idle time on the RF link. OK, not perfect. But nothing breaks. Having QoS on the router to radio link for DLEP and DLEP flow control = because the radio doesn't have QoS functions? I don't go in that = direction.=20 Teco Op 14 aug. 2013, om 16:49 heeft Henning Rogge = het volgende geschreven: > As long as the radio prioritize the DLEP traffic on the Ethernet link > this might still be okay. Not perfect, but not a catastrophe either. >=20 > Maybe we should add this into the suggestions/best-practice part of = the draft? >=20 > Henning Rogge >=20 > On Wed, Aug 14, 2013 at 4:47 PM, Stan Ratliff (sratliff) > wrote: >> That's absolutely true for outbound traffic. However, the RF could be = maximally used for inbound traffic, thus creating the congested = router-to-radio link we've been theorizing on=85 >>=20 >> My point is that overloading the router-to-radio link isn't as hard = as I initially thought - in fact, it's pretty straightforward... >>=20 >> Regards, >> Stan >>=20 >>=20 >> On Aug 14, 2013, at 10:41 AM, Henning Rogge = wrote: >>=20 >>> On Wed, Aug 14, 2013 at 4:15 PM, Stan Ratliff (sratliff) >>> wrote: >>>> As long as we're (still) talking about low-rate router-to-radio = links, and DLEP=85. >>>>=20 >>>> What if I take a router, stick a cable into a FastEthernet port, = and run the other end to a MIMO radio? At least in theory, methinks the = RF link is now faster than the Ethernet cable=85 >>>=20 >>> yes, it would be. But you could not use the full capacity of the RF >>> link anymore because you added an artificial bottleneck. >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> We began as wanderers, and we are wanderers still. We have lingered >>> long enough on the shores of the cosmic ocean. We are ready at last = to >>> set sail for the stars - Carl Sagan >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 >=20 >=20 > --=20 > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From internet-drafts@ietf.org Wed Aug 14 11:56:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CD811E818E; Wed, 14 Aug 2013 11:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XyYZJ+0D-XO; Wed, 14 Aug 2013 11:56:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D61711E80EA; Wed, 14 Aug 2013 11:56:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130814185631.954.89472.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 11:56:31 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-sec-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 18:56:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Integrity Protection for Control Messages in NHDP and OL= SRv2 Author(s) : Ulrich Herberg Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-olsrv2-sec-04.txt Pages : 15 Date : 2013-08-14 Abstract: This document specifies integrity and replay protection for the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp TLV based on POSIX time. The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444. This document updates RFC 6130 and RFC xxxx by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-olsrv2-sec-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-olsrv2-sec-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From chris.dearlove@baesystems.com Fri Aug 16 05:59:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA1A11E8278 for ; Fri, 16 Aug 2013 05:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMncY8Hh8cIV for ; Fri, 16 Aug 2013 05:59:06 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id E3DCA11E8110 for ; Fri, 16 Aug 2013 05:59:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,895,1367967600"; d="scan'208";a="307295434" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Aug 2013 13:59:04 +0100 X-IronPort-AV: E=Sophos;i="4.89,895,1367967600"; d="scan'208";a="25645458" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 16 Aug 2013 13:59:04 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.167]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0328.009; Fri, 16 Aug 2013 13:59:04 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: IDs presemted in Berlin Thread-Index: Ac6af5Fq3se/1MLIS0GTdRoITUFK2g== Date: Fri, 16 Aug 2013 12:59:03 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "'Stan Ratliff' \(sratliff@cisco.com\)" Subject: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 12:59:10 -0000 I don't believe that the chairs have raised the WG adoption of the IDs I pr= esented at Berlin. Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and draft-dearl= ove-manet-nhdp-olsrv2-tlv-extension are intended for Standards Track, and a= s minor updates to NHDP and OLSRv2, which we would like to progress as fast= as possible. The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious have no = problem with being adopted as a WG document, but it needs at least one more= revision, which we intend to do as an author draft, so there isn't the sam= e time pressure there. However of course we would like discussion any time = from now. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sratliff@cisco.com Fri Aug 16 08:37:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CED11E8281 for ; Fri, 16 Aug 2013 08:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76T33XoYhmqm for ; Fri, 16 Aug 2013 08:37:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BC63311E827B for ; Fri, 16 Aug 2013 08:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1955; q=dns/txt; s=iport; t=1376667445; x=1377877045; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2V3KafO2owE+4XZe33gIcAlT1vxza5Sm7EJE1KcE5i0=; b=O2nosBquq2KUZm1kh3KilSaQsJ5xl1Q/d+CEUyDUKK5K9pMHAVqA45Xl TDKJxGzyBJxUfXtpR0YPlLfbHF5CAQQ+ApD5DjmdVjLHcUkYn0Wivf4aL uMYiP5zTaAE0j+YKe36H6lZ85o7www+p4TuPio/ugsIxLHZ+T8TnL0Aij E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAHpGDlKtJXG//2dsb2JhbABbgwY1Ub8bgSsWdIIkAQEBAwFVJAULAgEIIiQyJQEBBA4FCIgCBroEjwMKgRACMQeDG3cDiHWgRIMcgWgJFyI X-IronPort-AV: E=Sophos;i="4.89,895,1367971200"; d="scan'208";a="247976140" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 16 Aug 2013 15:37:25 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7GFbP37022079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 15:37:25 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 10:37:25 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: IDs presemted in Berlin Thread-Index: Ac6af5Fq3se/1MLIS0GTdRoITUFK2gAQNj+A Date: Fri, 16 Aug 2013 15:37:23 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:37:31 -0000 OK, so to the WG - do we have consensus to adopt these documents as working= group docs?=20 Regards, Stan On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" wrote: > I don't believe that the chairs have raised the WG adoption of the IDs I = presented at Berlin. >=20 > Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and draft-dea= rlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards Track, and= as minor updates to NHDP and OLSRv2, which we would like to progress as fa= st as possible. >=20 > The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious have n= o problem with being adopted as a WG document, but it needs at least one mo= re revision, which we intend to do as an author draft, so there isn't the s= ame time pressure there. However of course we would like discussion any tim= e from now. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From teco@inf-net.nl Fri Aug 16 09:00:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3F321F9E00 for ; Fri, 16 Aug 2013 09:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mc8beojsEMPo for ; Fri, 16 Aug 2013 09:00:12 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id BFAF921F96B1 for ; Fri, 16 Aug 2013 09:00:11 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id c50so1009976eek.18 for ; Fri, 16 Aug 2013 09:00:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=saKWaiyHSHi+uM8++0SkPcRbmqguXfeizv0i7jNTKjk=; b=Dtws6j5J1ubdEn/T01p5ouGWHLvSLutbnv/q5bLffg17H7EgXxGuA/OuaY+eYKnKwl KYtm0mmnoADUH6dyqutwNKFluopD5PbXwpyXPO5KOK5VJMd456tlRjsaEJY7fAG48h8F GTEdYDWxZ20DvyZf7gPGtDT2P7ARSWEHzGTgJCwn372CMTzqgu6SlDZixTlVjJ5w1Nel B27dwRblPRvcVXLoRR+AeVvnkvY/BbgsseruMEi9K0ijdcl0E8QjPersuhaVTqfq5PWW IhfWf8d6a4xajxXXR8UoTSrZlML/+8lsoEoF5XsAuHeIXFexqrbOywnMCMmWih4rsNTN 7yCQ== X-Gm-Message-State: ALoCoQkmf8Vo1HM39W4Dyn4kJSE+Y5rJOyc5dVcNunZ9nHYa+vIPhp9YreyFJYEo3gINa/HbmVJh X-Received: by 10.14.122.132 with SMTP id t4mr3101288eeh.20.1376668810665; Fri, 16 Aug 2013 09:00:10 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id m54sm3616204eex.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 09:00:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> Date: Fri, 16 Aug 2013 18:00:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" , "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1508) Cc: "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:00:18 -0000 Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce problems = in a network with and without routers that implement this? If so, I think we need some discussion first. Teco Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: > OK, so to the WG - do we have consensus to adopt these documents as = working group docs?=20 >=20 > Regards, > Stan >=20 > On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >=20 >> I don't believe that the chairs have raised the WG adoption of the = IDs I presented at Berlin. >>=20 >> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>=20 >> The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious = have no problem with being adopted as a WG document, but it needs at = least one more revision, which we intend to do as an author draft, so = there isn't the same time pressure there. However of course we would = like discussion any time from now. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri Aug 16 09:28:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BE011E8193 for ; Fri, 16 Aug 2013 09:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTQwGzKmbpEt for ; Fri, 16 Aug 2013 09:28:20 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EF3E721F9A72 for ; Fri, 16 Aug 2013 09:28:19 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz10so1541784veb.3 for ; Fri, 16 Aug 2013 09:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cz6RYum5CXr/whRq4/2fZkHSDnMwdlAFI5pQ8G8OUu4=; b=vxgfLp6jnPIqTVOJGe/AIvpydMkaOE1kngPO4GxKnL7uYlielTgFQRQl5XtzKElrDe g1rtVpavj5ieZGrbFr4PUEsyEZA0XOzeJVzLwxTXANYnRwrUTUYdxvL5TjFIBd6kyEKK ViGRt0fLUFzGXWHJfzSMaCc5kUiUuOWiaS5dE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cz6RYum5CXr/whRq4/2fZkHSDnMwdlAFI5pQ8G8OUu4=; b=cl2J6GBX6Qyi116ra+XreNbJD6WEqJuHTm1dq1nOaB7HfIiPTcHKraI5HNaObXa90G pPkkh0zlXayH6Hxu41iy5KefXd62Kl/l1NaE4dbzRph74wNWPzk5RUCbrUFY2rLVLNBj 0EgWvYDnOaWLkJyj5u2Y+Em9UzWDqhDBxO6VFAe33cVr65oioex/Ho+aNL1a8nZjR818 P9E8vvZa0HP9jtll+g+p1COyh7uq7TXvuZpws4nnW1UaapAAZcZYEgRewbkmqulJjDjw xrTKXSmBGVAgAEu1kNn7CFpC0BxDUXq6SWjB7zgUSK1KKbrnvypBeP982afvN1RBhGcN mdpA== X-Gm-Message-State: ALoCoQm0uSHHCs3tKS9lNIonZycTfPfZNa7HLerASZrKjHB+krgECZ4phFxVIxTgWnN7PW1wsoNU MIME-Version: 1.0 X-Received: by 10.220.164.70 with SMTP id d6mr1958181vcy.19.1376670499306; Fri, 16 Aug 2013 09:28:19 -0700 (PDT) Received: by 10.220.127.65 with HTTP; Fri, 16 Aug 2013 09:28:19 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> Date: Fri, 16 Aug 2013 09:28:19 -0700 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=047d7b414aa4158fcf04e4131474 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:28:21 -0000 --047d7b414aa4158fcf04e4131474 Content-Type: text/plain; charset=ISO-8859-1 I am in favor of WG adoption of the two intended std tracks documents. As Chris suggested, I would prefer to see another revision / some more discussion of the MT document before adoption. Ulrich On Fri, Aug 16, 2013 at 8:37 AM, Stan Ratliff (sratliff) wrote: > OK, so to the WG - do we have consensus to adopt these documents as > working group docs? > > Regards, > Stan > > On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" < > chris.dearlove@baesystems.com> wrote: > > > I don't believe that the chairs have raised the WG adoption of the IDs I > presented at Berlin. > > > > Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and > draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards > Track, and as minor updates to NHDP and OLSRv2, which we would like to > progress as fast as possible. > > > > The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious have > no problem with being adopted as a WG document, but it needs at least one > more revision, which we intend to do as an author draft, so there isn't the > same time pressure there. However of course we would like discussion any > time from now. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b414aa4158fcf04e4131474 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am in favor of WG adoption of the two intended std track= s documents. As Chris suggested, I would prefer to see another revision / s= ome more discussion of the MT document before adoption.

Ulrich


On Fri, Aug 1= 6, 2013 at 8:37 AM, Stan Ratliff (sratliff) <sratliff@cisco.com>= wrote:
OK, so to the WG - do we have consensus to a= dopt these documents as working group docs?

Regards,
Stan

On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com= > wrote:

> I don't believe that the chairs have raised the WG adoption of the= IDs I presented at Berlin.
>
> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and draft-= dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards Track, = and as minor updates to NHDP and OLSRv2, which we would like to progress as= fast as possible.
>
> The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious= have no problem with being adopted as a WG document, but it needs at least= one more revision, which we intend to do as an author draft, so there isn&= #39;t the same time pressure there. However of course we would like discuss= ion any time from now.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44= 1245 242194 | =A0Fax: +44 1245 242124
> chris.dearlove@baesys= tems.com | http= ://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> ******************************************************************** > This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ******************************************************************** >

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b414aa4158fcf04e4131474-- From christopher.dearlove@gmail.com Fri Aug 16 09:43:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF611E81C3 for ; Fri, 16 Aug 2013 09:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U8oE8b2eSoP for ; Fri, 16 Aug 2013 09:43:45 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id DF8E511E8169 for ; Fri, 16 Aug 2013 09:43:44 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so1777672wgg.16 for ; Fri, 16 Aug 2013 09:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=w7nsXUteVtUt6A20Kn+wWzsOoursPc0HUD5LpHJHHXc=; b=SXRo0VpcgRAvD9B454SqgUjJv3ov0kcZ2FIHN77MeAEwZE4qcI4rq9hknTxwln2DSX 80zyfo2P1v6ET2QsX91KsjYWoVVqpupxgEVvTmi2NelR46vrpX4JbhnHFFLhrJwst+KO 1NeL0djTZbtVJNjF3ViT4SUAJIIS6Wv5ygcsNj+Zss2kDesfmTqpfQtMplXuCWk74EKD Hu9nkaiAHNXAeZ4TklfL6kblOuvy7gHrFTx2KyNgvLK/NRHXCpV8bcWM7yDyJJCf6+JB sbFcK9kX7VIl7406HVWIxF4m43a5HMZc7UHswbl+enLxpdLmKKLZHXumiEXWBDT8BbbJ bQtA== X-Received: by 10.180.9.69 with SMTP id x5mr5828198wia.41.1376671424032; Fri, 16 Aug 2013 09:43:44 -0700 (PDT) Received: from [192.168.254.2] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id fz8sm9490164wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 09:43:42 -0700 (PDT) References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> Mime-Version: 1.0 (1.0) In-Reply-To: <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> X-Mailer: iPhone Mail (10B350) From: Christopher Dearlove Date: Fri, 16 Aug 2013 17:43:41 +0100 To: Teco Boot Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:43:46 -0000 I think my starting point with such a discussion would be who has an impleme= ntation? Yes, there are possible minor issues for implementations (though it= 's also possible for an implementation to need no changes at all). But the m= ost pointless thing would be protecting (in a minor way) hypothetical implem= entations while people actually with them want this. (I'm not saying those with them have all said they want this. I'm asking.) -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 16 Aug 2013, at 17:00, Teco Boot wrote: > Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce problems in a= network with and without routers that implement this? > If so, I think we need some discussion first. >=20 > Teco >=20 > Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) het volgende geschreven: >=20 >> OK, so to the WG - do we have consensus to adopt these documents as worki= ng group docs?=20 >>=20 >> Regards, >> Stan >>=20 >> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" wrote: >>=20 >>> I don't believe that the chairs have raised the WG adoption of the IDs I= presented at Berlin. >>>=20 >>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and draft-de= arlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards Track, and= as minor updates to NHDP and OLSRv2, which we would like to progress as fas= t as possible. >>>=20 >>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious have n= o problem with being adopted as a WG document, but it needs at least one mor= e revision, which we intend to do as an author draft, so there isn't the sam= e time pressure there. However of course we would like discussion any time f= rom now. >>>=20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Fri Aug 16 10:06:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D1711E8166 for ; Fri, 16 Aug 2013 10:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwOnvP5lRrwC for ; Fri, 16 Aug 2013 10:06:07 -0700 (PDT) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id 788B211E8174 for ; Fri, 16 Aug 2013 10:06:06 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id m14so1112204eaj.20 for ; Fri, 16 Aug 2013 10:06:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zdJI+e0e7s8GTl3dBxc92/uayE3iwsHPpfTwDLBgZC8=; b=X8XIHg6mVnCV27oHauOpsWKKDvmVRIeAaG13mZgkuSUdw2tJvYH8uLKXa4/jwiMeAT +mjxyYPPLIxTucW4fu/MZxW8KjEqMykJYAr6lm/a7egPIyJRNPfiLd3LBCjkj6k1M1Fg xZu39BBacxFkt29JPltOEaqf9FoHH+/orAWRa7RoPNH5AhxNou9i6U44v/k+ea9pSCXv 2PCICtTehYHykB3sJXV9r5krlAHE2Pe/1coreWjb0/iGki6lDXh0afYn98E3me9kqlm8 t7/5hJAfZDaxRQq2p4OfxzUBiwoD25bqsIyveBiO6YINu8EcnF3XaBCNf6uhyjaCOr+p vWwg== X-Gm-Message-State: ALoCoQkek1+p64tfek6LY9Mr4dpkzXQErvfvsxu0QcV2eZVBsGja62S1QCDODKTkv2Li/BGVUFsy X-Received: by 10.15.43.140 with SMTP id x12mr63378eev.61.1376672761619; Fri, 16 Aug 2013 10:06:01 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id d8sm3968144eeh.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 10:06:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> Date: Fri, 16 Aug 2013 19:05:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> To: Christopher Dearlove X-Mailer: Apple Mail (2.1508) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 17:06:13 -0000 May I read that there are problems? If so, we cannot bring out a std track RFC followed up with something = that can not interoperate with it. Or we mark the to_be RFC as obsolete. = That's how it works. Teco PS1. you mentioned something about IESG and correctness... PS2: I understand the motivation. discussion could be how to deal with = it. Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: > I think my starting point with such a discussion would be who has an = implementation? Yes, there are possible minor issues for implementations = (though it's also possible for an implementation to need no changes at = all). But the most pointless thing would be protecting (in a minor way) = hypothetical implementations while people actually with them want this. >=20 > (I'm not saying those with them have all said they want this. I'm = asking.) >=20 > -- =20 > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) >=20 > On 16 Aug 2013, at 17:00, Teco Boot wrote: >=20 >> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce = problems in a network with and without routers that implement this? >> If so, I think we need some discussion first. >>=20 >> Teco >>=20 >> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>=20 >>> OK, so to the WG - do we have consensus to adopt these documents as = working group docs?=20 >>>=20 >>> Regards, >>> Stan >>>=20 >>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >>>=20 >>>> I don't believe that the chairs have raised the WG adoption of the = IDs I presented at Berlin. >>>>=20 >>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>>>=20 >>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious = have no problem with being adopted as a WG document, but it needs at = least one more revision, which we intend to do as an author draft, so = there isn't the same time pressure there. However of course we would = like discussion any time from now. >>>>=20 >>>> --=20 >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> = ******************************************************************** >>>> This email and any attachments are confidential to the intended >>>> recipient and may also be privileged. If you are not the intended >>>> recipient please delete it from your system and notify the sender. >>>> You should not copy it or use it for any purpose nor disclose or >>>> distribute its contents to any other person. >>>> = ******************************************************************** >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From christopher.dearlove@gmail.com Fri Aug 16 10:14:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C579311E81EC for ; Fri, 16 Aug 2013 10:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpP2vkMySJQu for ; Fri, 16 Aug 2013 10:14:06 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 80A3511E8185 for ; Fri, 16 Aug 2013 10:14:05 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id f14so1022115wiw.7 for ; Fri, 16 Aug 2013 10:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+jaBeFfXAnCUr00lMlHuCb/9y/wWPuvNW3P+y3DB/bg=; b=LZ7XhlL89g9zTV7hDzj7X/IjDzKwkpHUCSNwLKEP8F/sPcR5cfAGb+sdq5abnfegs2 zmaP32umYBnDrokZReilm6+/M4DLa//VeYOZMEtCZhgaYoSYdf+4G8XU9uW1QS/USK2O WXfrbcQyzC/M3UgHz5LGbIFPsr2cpB0lA49PiTuiD7xxZ94EXukvwM3clH55MwQ5Koj2 IBnc3oDwhFXZ+6o3riFJwiOwcxhyplNOv7EsCcBKXaja3y7et9Ldn15EhfC3MMSaxsEF 21WMpvz0wbaU5h1I4S/Q044VMYv8HnMWZgZZSUBecatv43ZQUw9lQn6Y/ch4XdF5wZS/ i5SA== X-Received: by 10.180.84.65 with SMTP id w1mr47596wiy.4.1376673244626; Fri, 16 Aug 2013 10:14:04 -0700 (PDT) Received: from [192.168.254.1] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id fu13sm3568628wic.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 10:14:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christopher Dearlove In-Reply-To: <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> Date: Fri, 16 Aug 2013 18:14:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1283) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 17:14:06 -0000 You can read this that there are minor issues, which I wouldn't elevate = to the level of problems. Your comment on the inability to modify RFCs is just plain wrong. Was = RFC 791 obsoleted when the TOS bits function was changed? No. Many more = such examples could be given. I'm actually not aware of anyone with an implementation who doesn't = support this. Just in case not obvious, that includes me. Does anyone with an implementation have an issue? On 16 Aug 2013, at 18:05, Teco Boot wrote: > May I read that there are problems? > If so, we cannot bring out a std track RFC followed up with something = that can not interoperate with it. Or we mark the to_be RFC as obsolete. = That's how it works. >=20 > Teco >=20 > PS1. you mentioned something about IESG and correctness... > PS2: I understand the motivation. discussion could be how to deal with = it. >=20 > Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: >=20 >> I think my starting point with such a discussion would be who has an = implementation? Yes, there are possible minor issues for implementations = (though it's also possible for an implementation to need no changes at = all). But the most pointless thing would be protecting (in a minor way) = hypothetical implementations while people actually with them want this. >>=20 >> (I'm not saying those with them have all said they want this. I'm = asking.) >>=20 >> -- =20 >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >>=20 >> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>=20 >>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce = problems in a network with and without routers that implement this? >>> If so, I think we need some discussion first. >>>=20 >>> Teco >>>=20 >>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>>=20 >>>> OK, so to the WG - do we have consensus to adopt these documents as = working group docs?=20 >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >>>>=20 >>>>> I don't believe that the chairs have raised the WG adoption of the = IDs I presented at Berlin. >>>>>=20 >>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>>>>=20 >>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious = have no problem with being adopted as a WG document, but it needs at = least one more revision, which we intend to do as an author draft, so = there isn't the same time pressure there. However of course we would = like discussion any time from now. >>>>>=20 >>>>> --=20 >>>>> Christopher Dearlove >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>=20 >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England & Wales No: 1996687 >>>>>=20 >>>>>=20 >>>>> = ******************************************************************** >>>>> This email and any attachments are confidential to the intended >>>>> recipient and may also be privileged. If you are not the intended >>>>> recipient please delete it from your system and notify the sender. >>>>> You should not copy it or use it for any purpose nor disclose or >>>>> distribute its contents to any other person. >>>>> = ******************************************************************** >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 From teco@inf-net.nl Fri Aug 16 13:27:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8BB21F9A43 for ; Fri, 16 Aug 2013 13:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX2Lfiz1Mazw for ; Fri, 16 Aug 2013 13:27:21 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82EEF21F9D0D for ; Fri, 16 Aug 2013 13:27:17 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id b47so1111572eek.17 for ; Fri, 16 Aug 2013 13:27:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=UA/8h83VyG7VY15v0HCBOTL2ba/m3U5Z5zyLRXUGRhc=; b=d4kY+cT2b35KHpNGFakCZPYY/s0BO4DPKOO8RIwh/1ZbxRh/mpifyP+N8QAo5FLX2+ SeqRkz32dNAeJ9rDlwJMKEb6hyNsIUm5m2/zWapxdsBHToeNXjYdAQnEaLTEUV4uQOqi LRznNNE1geJplAcmTtFwCvU4nNFU0e3ICKr3PdNAuvbUTIOjWHRtmNZIdMFVNARgcns4 npT9wQcFOfm7VbPGJotAvnz2ChtijZyqB6HN9OVyn3VpGuSQHzL4/PxNRXVwJdN4bDmC d1KF3h91UA1e/n/9CP7ziIeIFt9JX2yJrB/N2pTF97rgQjB907ycNLbar/Ig7ymGDVAI VjkA== X-Gm-Message-State: ALoCoQl4r6rwnMi7ttPcgD+FVfdrX9cHHJKMuttG+qb2ecRqXHEDozs670ZKu85RKx06PEtu+vKZ X-Received: by 10.15.98.129 with SMTP id bj1mr40664eeb.75.1376684831025; Fri, 16 Aug 2013 13:27:11 -0700 (PDT) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id d8sm5121736eeh.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 13:27:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> Date: Fri, 16 Aug 2013 22:27:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> To: Christopher Dearlove X-Mailer: Apple Mail (2.1508) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 20:27:33 -0000 If anyone in the future writes code that complies with std track RFC, = he/she may assume that it is compatible with any other implementation. = If an update of that RFC will break compatibility, that RFC shall be = obsoleted, I think.=20 RFC 791 was 1981. Wording on TOS: "provides an indication", "are to be = used to guide", "may". Remapping to DSCP is highly backwards compatible. Did I say I'm against? I just want to know the issues / problems. At = least they should be documented. Teco Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove = het volgende geschreven: > You can read this that there are minor issues, which I wouldn't = elevate to the level of problems. >=20 > Your comment on the inability to modify RFCs is just plain wrong. Was = RFC 791 obsoleted when the TOS bits function was changed? No. Many more = such examples could be given. >=20 > I'm actually not aware of anyone with an implementation who doesn't = support this. Just in case not obvious, that includes me. >=20 > Does anyone with an implementation have an issue? >=20 >=20 > On 16 Aug 2013, at 18:05, Teco Boot wrote: >=20 >> May I read that there are problems? >> If so, we cannot bring out a std track RFC followed up with something = that can not interoperate with it. Or we mark the to_be RFC as obsolete. = That's how it works. >>=20 >> Teco >>=20 >> PS1. you mentioned something about IESG and correctness... >> PS2: I understand the motivation. discussion could be how to deal = with it. >>=20 >> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: >>=20 >>> I think my starting point with such a discussion would be who has an = implementation? Yes, there are possible minor issues for implementations = (though it's also possible for an implementation to need no changes at = all). But the most pointless thing would be protecting (in a minor way) = hypothetical implementations while people actually with them want this. >>>=20 >>> (I'm not saying those with them have all said they want this. I'm = asking.) >>>=20 >>> -- =20 >>> Christopher Dearlove >>> christopher.dearlove@gmail.com (iPhone) >>> chris@mnemosyne.demon.co.uk (home) >>>=20 >>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>=20 >>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce = problems in a network with and without routers that implement this? >>>> If so, I think we need some discussion first. >>>>=20 >>>> Teco >>>>=20 >>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>>>=20 >>>>> OK, so to the WG - do we have consensus to adopt these documents = as working group docs?=20 >>>>>=20 >>>>> Regards, >>>>> Stan >>>>>=20 >>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >>>>>=20 >>>>>> I don't believe that the chairs have raised the WG adoption of = the IDs I presented at Berlin. >>>>>>=20 >>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>>>>>=20 >>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd = obvious have no problem with being adopted as a WG document, but it = needs at least one more revision, which we intend to do as an author = draft, so there isn't the same time pressure there. However of course we = would like discussion any time from now. >>>>>>=20 >>>>>> --=20 >>>>>> Christopher Dearlove >>>>>> Senior Principal Engineer, Communications Group >>>>>> Communications, Networks and Image Analysis Capability >>>>>> BAE Systems Advanced Technology Centre >>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>=20 >>>>>> BAE Systems (Operations) Limited >>>>>> Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>> Registered in England & Wales No: 1996687 >>>>>>=20 >>>>>>=20 >>>>>> = ******************************************************************** >>>>>> This email and any attachments are confidential to the intended >>>>>> recipient and may also be privileged. If you are not the intended >>>>>> recipient please delete it from your system and notify the = sender. >>>>>> You should not copy it or use it for any purpose nor disclose or >>>>>> distribute its contents to any other person. >>>>>> = ******************************************************************** >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From christopher.dearlove@gmail.com Fri Aug 16 13:37:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C7811E822A for ; Fri, 16 Aug 2013 13:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFKVzA7WvXvy for ; Fri, 16 Aug 2013 13:37:34 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EFF7211E8212 for ; Fri, 16 Aug 2013 13:37:32 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so863727wes.18 for ; Fri, 16 Aug 2013 13:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3FFRzOIcqybv2tIW7R5KDGTkhjNCpupE5z3FTn0U8YE=; b=yy51iqZBMJDs2KCpUH7gxGX2i9Kc+RLM42oy4NRxMIfcstnIILLjijIjTPJcGlJCan eACVCWmsWQ7Cp81znVhcWmgGwzstsxBk1tZFICCmymzmAvyu5FBGd90R8I3BhuWQxWzS 5BwD2KEA2PEZwyt1m4XDZTUOBxarSXAsJFW9pDftHcVr5hzM/HbeUGarHbAnnM7nCcav atnumlyA66I6VRrNhSeVMZ1ZA54Hs2RPaOuJ+DOy4vNfbQn0B/H+92qC3ycvH8SZ28KY hIWj9vEUMIRumAlZ6M8gBmK4nTOgLzoF10F1PSUY0u3LfuWwGq9G6CgbrUp2ooyKETO3 wdfw== X-Received: by 10.180.72.47 with SMTP id a15mr443326wiv.63.1376685451833; Fri, 16 Aug 2013 13:37:31 -0700 (PDT) Received: from [192.168.254.1] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id b13sm665012wic.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 13:37:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christopher Dearlove In-Reply-To: Date: Fri, 16 Aug 2013 21:37:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> To: Teco Boot X-Mailer: Apple Mail (2.1283) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 20:37:36 -0000 I think you are quite wrong on the obsoleted point. Especially when we = are talking changes to define what was previously undefined. Nothing = defined has changed. Which is just like the TOS change. But if you want to know what's changed, read the draft. I'd be interested in hearing from people with implementations. If the = bottom line is that there isn't anyone with an implementation who has a = problem, I think worries over a hypothetical unwritten implementation = are rather beside the point. Anyone coming to something new could always = check the "updated by" bit. On 16 Aug 2013, at 21:27, Teco Boot wrote: > If anyone in the future writes code that complies with std track RFC, = he/she may assume that it is compatible with any other implementation. = If an update of that RFC will break compatibility, that RFC shall be = obsoleted, I think.=20 >=20 > RFC 791 was 1981. Wording on TOS: "provides an indication", "are to be = used to guide", "may". Remapping to DSCP is highly backwards compatible. >=20 > Did I say I'm against? I just want to know the issues / problems. At = least they should be documented. >=20 > Teco >=20 >=20 > Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove = het volgende geschreven: >=20 >> You can read this that there are minor issues, which I wouldn't = elevate to the level of problems. >>=20 >> Your comment on the inability to modify RFCs is just plain wrong. Was = RFC 791 obsoleted when the TOS bits function was changed? No. Many more = such examples could be given. >>=20 >> I'm actually not aware of anyone with an implementation who doesn't = support this. Just in case not obvious, that includes me. >>=20 >> Does anyone with an implementation have an issue? >>=20 >>=20 >> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>=20 >>> May I read that there are problems? >>> If so, we cannot bring out a std track RFC followed up with = something that can not interoperate with it. Or we mark the to_be RFC as = obsolete. That's how it works. >>>=20 >>> Teco >>>=20 >>> PS1. you mentioned something about IESG and correctness... >>> PS2: I understand the motivation. discussion could be how to deal = with it. >>>=20 >>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: >>>=20 >>>> I think my starting point with such a discussion would be who has = an implementation? Yes, there are possible minor issues for = implementations (though it's also possible for an implementation to need = no changes at all). But the most pointless thing would be protecting (in = a minor way) hypothetical implementations while people actually with = them want this. >>>>=20 >>>> (I'm not saying those with them have all said they want this. I'm = asking.) >>>>=20 >>>> -- =20 >>>> Christopher Dearlove >>>> christopher.dearlove@gmail.com (iPhone) >>>> chris@mnemosyne.demon.co.uk (home) >>>>=20 >>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>=20 >>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce = problems in a network with and without routers that implement this? >>>>> If so, I think we need some discussion first. >>>>>=20 >>>>> Teco >>>>>=20 >>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>>>>=20 >>>>>> OK, so to the WG - do we have consensus to adopt these documents = as working group docs?=20 >>>>>>=20 >>>>>> Regards, >>>>>> Stan >>>>>>=20 >>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >>>>>>=20 >>>>>>> I don't believe that the chairs have raised the WG adoption of = the IDs I presented at Berlin. >>>>>>>=20 >>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>>>>>>=20 >>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd = obvious have no problem with being adopted as a WG document, but it = needs at least one more revision, which we intend to do as an author = draft, so there isn't the same time pressure there. However of course we = would like discussion any time from now. >>>>>>>=20 >>>>>>> --=20 >>>>>>> Christopher Dearlove >>>>>>> Senior Principal Engineer, Communications Group >>>>>>> Communications, Networks and Image Analysis Capability >>>>>>> BAE Systems Advanced Technology Centre >>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>=20 >>>>>>> BAE Systems (Operations) Limited >>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>> Registered in England & Wales No: 1996687 >>>>>>>=20 >>>>>>>=20 >>>>>>> = ******************************************************************** >>>>>>> This email and any attachments are confidential to the intended >>>>>>> recipient and may also be privileged. If you are not the = intended >>>>>>> recipient please delete it from your system and notify the = sender. >>>>>>> You should not copy it or use it for any purpose nor disclose or >>>>>>> distribute its contents to any other person. >>>>>>> = ******************************************************************** >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 From teco@inf-net.nl Fri Aug 16 13:58:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59AB11E8134 for ; Fri, 16 Aug 2013 13:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euunAUI+rFSY for ; Fri, 16 Aug 2013 13:58:21 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBD411E80FF for ; Fri, 16 Aug 2013 13:58:20 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id b47so1128860eek.31 for ; Fri, 16 Aug 2013 13:58:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=NL/JS7hnW54m6ytDbdxdCmdkOIm448DgMhyrSl1D8/8=; b=pNsaXlA+4NWKEOsgRxE20L7VdTMhL7tXFLfBWdjhgbW8sYmx3PW3FhQ9RcGGbnN7dA 4J0dx7ES8Epaew/E8x7pLS2BN0ZmW+rtfkeuO1izqPSMrwiyQhwV2ahpn2IXZfUap+3g N/UjZCmmSap4Z+XLlyQH/rjdb4guuj55wniJnPcn4BMgP2dk/gL9qW9lBBk5IwYs9BZX 8BW0Yn/0f9D0LdRS3tkUqLvGLwYDUocjLR6UmOvUzmUT9d6hwBKYR7AKl0tw/TVku9vV HY86TybXIdLwBQgMRLSqh9kLQS7cjpVD3W32cjrpNNBMxOS2Zgyu9QzYbx33UZBy9EsQ +9eg== X-Gm-Message-State: ALoCoQkZ9xqInuR4VVJ5byYHi86V2rJjUGTHWzS0CBtNdEdTD7bwDUfnGWgLyrTFyxXonM6ttCHJ X-Received: by 10.14.210.8 with SMTP id t8mr4649017eeo.39.1376686698244; Fri, 16 Aug 2013 13:58:18 -0700 (PDT) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id a1sm5333878eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 13:58:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Fri, 16 Aug 2013 22:58:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> To: Christopher Dearlove X-Mailer: Apple Mail (2.1508) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 20:58:26 -0000 I understand the change is documented. My concerns are on what happens when different implementations are in = same network. This has to be documented. Asking on mailing list is not = enough. Teco Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove = het volgende geschreven: > I think you are quite wrong on the obsoleted point. Especially when we = are talking changes to define what was previously undefined. Nothing = defined has changed. Which is just like the TOS change. >=20 > But if you want to know what's changed, read the draft. >=20 > I'd be interested in hearing from people with implementations. If the = bottom line is that there isn't anyone with an implementation who has a = problem, I think worries over a hypothetical unwritten implementation = are rather beside the point. Anyone coming to something new could always = check the "updated by" bit. >=20 >=20 > On 16 Aug 2013, at 21:27, Teco Boot wrote: >=20 >> If anyone in the future writes code that complies with std track RFC, = he/she may assume that it is compatible with any other implementation. = If an update of that RFC will break compatibility, that RFC shall be = obsoleted, I think.=20 >>=20 >> RFC 791 was 1981. Wording on TOS: "provides an indication", "are to = be used to guide", "may". Remapping to DSCP is highly backwards = compatible. >>=20 >> Did I say I'm against? I just want to know the issues / problems. At = least they should be documented. >>=20 >> Teco >>=20 >>=20 >> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove = het volgende geschreven: >>=20 >>> You can read this that there are minor issues, which I wouldn't = elevate to the level of problems. >>>=20 >>> Your comment on the inability to modify RFCs is just plain wrong. = Was RFC 791 obsoleted when the TOS bits function was changed? No. Many = more such examples could be given. >>>=20 >>> I'm actually not aware of anyone with an implementation who doesn't = support this. Just in case not obvious, that includes me. >>>=20 >>> Does anyone with an implementation have an issue? >>>=20 >>>=20 >>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>=20 >>>> May I read that there are problems? >>>> If so, we cannot bring out a std track RFC followed up with = something that can not interoperate with it. Or we mark the to_be RFC as = obsolete. That's how it works. >>>>=20 >>>> Teco >>>>=20 >>>> PS1. you mentioned something about IESG and correctness... >>>> PS2: I understand the motivation. discussion could be how to deal = with it. >>>>=20 >>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: >>>>=20 >>>>> I think my starting point with such a discussion would be who has = an implementation? Yes, there are possible minor issues for = implementations (though it's also possible for an implementation to need = no changes at all). But the most pointless thing would be protecting (in = a minor way) hypothetical implementations while people actually with = them want this. >>>>>=20 >>>>> (I'm not saying those with them have all said they want this. I'm = asking.) >>>>>=20 >>>>> -- =20 >>>>> Christopher Dearlove >>>>> christopher.dearlove@gmail.com (iPhone) >>>>> chris@mnemosyne.demon.co.uk (home) >>>>>=20 >>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>=20 >>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce = problems in a network with and without routers that implement this? >>>>>> If so, I think we need some discussion first. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>>>>>=20 >>>>>>> OK, so to the WG - do we have consensus to adopt these documents = as working group docs?=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>> Stan >>>>>>>=20 >>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >>>>>>>=20 >>>>>>>> I don't believe that the chairs have raised the WG adoption of = the IDs I presented at Berlin. >>>>>>>>=20 >>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>>>>>>>=20 >>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd = obvious have no problem with being adopted as a WG document, but it = needs at least one more revision, which we intend to do as an author = draft, so there isn't the same time pressure there. However of course we = would like discussion any time from now. >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Christopher Dearlove >>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>=20 >>>>>>>> BAE Systems (Operations) Limited >>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ******************************************************************** >>>>>>>> This email and any attachments are confidential to the intended >>>>>>>> recipient and may also be privileged. If you are not the = intended >>>>>>>> recipient please delete it from your system and notify the = sender. >>>>>>>> You should not copy it or use it for any purpose nor disclose = or >>>>>>>> distribute its contents to any other person. >>>>>>>> = ******************************************************************** >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>=20 >=20 From christopher.dearlove@gmail.com Fri Aug 16 14:16:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263CC11E8184 for ; Fri, 16 Aug 2013 14:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRuKcjRaHGmW for ; Fri, 16 Aug 2013 14:16:14 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8B11E815B for ; Fri, 16 Aug 2013 14:16:08 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so2062011wes.39 for ; Fri, 16 Aug 2013 14:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=S4FkPYFTuYj3C/IlTKafMdoTCn7uD9YK4MmsIcq0ivc=; b=zNCrsgbfaoKkUpnaHyfjq5yDqeg9ZnzgFIZXwnvatCMuo6QKexmmS6O0ceBPdTXmHy IIqvVXNI1357IWer+6vVt2pjxzNxxkX7UnR3LWdjud3K/pTntuzbu71gzpn/SQYRJLdk 5WXDz/F2Fa4LWMNO7GQkm3+e4zffFCOnfRqVFUiC1qt7uTvtXHCjXH/uUMdcFECs6ypW WONv2d0KQxnq4Skk5HTFzrO3nPl5ntBSmHvM4Zl3/G6EGEEeWBfr4h7Dr0/0S/MM7E3F /YyjSNFKdjrNId+eZ7hsYfarqVw+LG8H5H8CBd2asUooM7gh3DYeWzv9ELjACqxwWdyc M9Wg== X-Received: by 10.180.210.243 with SMTP id mx19mr607417wic.35.1376687766923; Fri, 16 Aug 2013 14:16:06 -0700 (PDT) Received: from [192.168.254.2] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id r6sm898813wiw.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 14:16:06 -0700 (PDT) References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> Mime-Version: 1.0 (1.0) In-Reply-To: <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: Christopher Dearlove Date: Fri, 16 Aug 2013 22:12:11 +0100 To: Teco Boot Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 21:16:15 -0000 Have you read the draft? --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 16 Aug 2013, at 21:58, Teco Boot wrote: > I understand the change is documented. > My concerns are on what happens when different implementations are in same= network. This has to be documented. Asking on mailing list is not enough. >=20 > Teco >=20 > Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove het volgende geschreven: >=20 >> I think you are quite wrong on the obsoleted point. Especially when we ar= e talking changes to define what was previously undefined. Nothing defined h= as changed. Which is just like the TOS change. >>=20 >> But if you want to know what's changed, read the draft. >>=20 >> I'd be interested in hearing from people with implementations. If the bot= tom line is that there isn't anyone with an implementation who has a problem= , I think worries over a hypothetical unwritten implementation are rather be= side the point. Anyone coming to something new could always check the "updat= ed by" bit. >>=20 >>=20 >> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>=20 >>> If anyone in the future writes code that complies with std track RFC, he= /she may assume that it is compatible with any other implementation. If an u= pdate of that RFC will break compatibility, that RFC shall be obsoleted, I t= hink.=20 >>>=20 >>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are to be u= sed to guide", "may". Remapping to DSCP is highly backwards compatible. >>>=20 >>> Did I say I'm against? I just want to know the issues / problems. At lea= st they should be documented. >>>=20 >>> Teco >>>=20 >>>=20 >>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove het volgende geschreven: >>>=20 >>>> You can read this that there are minor issues, which I wouldn't elevate= to the level of problems. >>>>=20 >>>> Your comment on the inability to modify RFCs is just plain wrong. Was R= FC 791 obsoleted when the TOS bits function was changed? No. Many more such e= xamples could be given. >>>>=20 >>>> I'm actually not aware of anyone with an implementation who doesn't sup= port this. Just in case not obvious, that includes me. >>>>=20 >>>> Does anyone with an implementation have an issue? >>>>=20 >>>>=20 >>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>=20 >>>>> May I read that there are problems? >>>>> If so, we cannot bring out a std track RFC followed up with something t= hat can not interoperate with it. Or we mark the to_be RFC as obsolete. That= 's how it works. >>>>>=20 >>>>> Teco >>>>>=20 >>>>> PS1. you mentioned something about IESG and correctness... >>>>> PS2: I understand the motivation. discussion could be how to deal with= it. >>>>>=20 >>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove het volgende geschreven: >>>>>=20 >>>>>> I think my starting point with such a discussion would be who has an i= mplementation? Yes, there are possible minor issues for implementations (tho= ugh it's also possible for an implementation to need no changes at all). But= the most pointless thing would be protecting (in a minor way) hypothetical i= mplementations while people actually with them want this. >>>>>>=20 >>>>>> (I'm not saying those with them have all said they want this. I'm ask= ing.) >>>>>>=20 >>>>>> -- =20 >>>>>> Christopher Dearlove >>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>=20 >>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>>=20 >>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce proble= ms in a network with and without routers that implement this? >>>>>>> If so, I think we need some discussion first. >>>>>>>=20 >>>>>>> Teco >>>>>>>=20 >>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) het volgende geschreven: >>>>>>>=20 >>>>>>>> OK, so to the WG - do we have consensus to adopt these documents as= working group docs?=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Stan >>>>>>>>=20 >>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" wrote: >>>>>>>>=20 >>>>>>>>> I don't believe that the chairs have raised the WG adoption of the= IDs I presented at Berlin. >>>>>>>>>=20 >>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and dr= aft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards Trac= k, and as minor updates to NHDP and OLSRv2, which we would like to progress a= s fast as possible. >>>>>>>>>=20 >>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious= have no problem with being adopted as a WG document, but it needs at least o= ne more revision, which we intend to do as an author draft, so there isn't t= he same time pressure there. However of course we would like discussion any t= ime from now. >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> Christopher Dearlove >>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>>=20 >>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ******************************************************************= ** >>>>>>>>> This email and any attachments are confidential to the intended >>>>>>>>> recipient and may also be privileged. If you are not the intended >>>>>>>>> recipient please delete it from your system and notify the sender.= >>>>>>>>> You should not copy it or use it for any purpose nor disclose or >>>>>>>>> distribute its contents to any other person. >>>>>>>>> ******************************************************************= ** >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >=20 From teco@inf-net.nl Fri Aug 16 14:36:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FB411E80EA for ; Fri, 16 Aug 2013 14:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZ5uIg8MY+iN for ; Fri, 16 Aug 2013 14:36:36 -0700 (PDT) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1E12621F9A2E for ; Fri, 16 Aug 2013 14:36:35 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id z15so1229973ead.5 for ; Fri, 16 Aug 2013 14:36:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Pe8EtujVHXAt/7XMIGj7KG9PBc8wa2VfUbi7EHJgyo8=; b=llN4M50k7zOeH1dggevU3DvZxYGqkoT1y6XWJbyh+oEvONVexeACUN6Oo/oyvI9juV 2w5UOQOIl2zza6sp/YlC8gX1qQqaeTjBcApxSxx5F/KSIS3La+0C/w1F3BVjKaGlIFvt 2TZJuIsaHXeQ22BWwxKbqnsYy1VLkaKVAOOY/2a4Xtfq6AIMIlBa0l1Z1Ux7zL2iwrDC LkoCOFhChj11eqELNEXhwt+i/hhALvRllpePeHTY0vTy4bK1WvCBloMABGU55OWStvBV YuilBtTNxADg0yW+RA2AFJm3aKgXfFKs5qRt1Rn5V/CFw5DuHh1/+E7N7jgF1bVBQmGD IOyQ== X-Gm-Message-State: ALoCoQnzyxHoGHUgK/lLklfRZaR8e5x/rb8wGoO3XLUZLvdKdWwAjdWQzwLRI7xEnAxu60QQftjz X-Received: by 10.14.176.8 with SMTP id a8mr5007790eem.12.1376688994669; Fri, 16 Aug 2013 14:36:34 -0700 (PDT) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id l47sm5449025eex.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 14:36:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Fri, 16 Aug 2013 23:36:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> To: Christopher Dearlove X-Mailer: Apple Mail (2.1508) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 21:36:41 -0000 Yes. Teco Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove = het volgende geschreven: > Have you read the draft? >=20 > --=20 > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) >=20 > On 16 Aug 2013, at 21:58, Teco Boot wrote: >=20 >> I understand the change is documented. >> My concerns are on what happens when different implementations are in = same network. This has to be documented. Asking on mailing list is not = enough. >>=20 >> Teco >>=20 >> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove = het volgende geschreven: >>=20 >>> I think you are quite wrong on the obsoleted point. Especially when = we are talking changes to define what was previously undefined. Nothing = defined has changed. Which is just like the TOS change. >>>=20 >>> But if you want to know what's changed, read the draft. >>>=20 >>> I'd be interested in hearing from people with implementations. If = the bottom line is that there isn't anyone with an implementation who = has a problem, I think worries over a hypothetical unwritten = implementation are rather beside the point. Anyone coming to something = new could always check the "updated by" bit. >>>=20 >>>=20 >>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>=20 >>>> If anyone in the future writes code that complies with std track = RFC, he/she may assume that it is compatible with any other = implementation. If an update of that RFC will break compatibility, that = RFC shall be obsoleted, I think.=20 >>>>=20 >>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are to = be used to guide", "may". Remapping to DSCP is highly backwards = compatible. >>>>=20 >>>> Did I say I'm against? I just want to know the issues / problems. = At least they should be documented. >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove = het volgende geschreven: >>>>=20 >>>>> You can read this that there are minor issues, which I wouldn't = elevate to the level of problems. >>>>>=20 >>>>> Your comment on the inability to modify RFCs is just plain wrong. = Was RFC 791 obsoleted when the TOS bits function was changed? No. Many = more such examples could be given. >>>>>=20 >>>>> I'm actually not aware of anyone with an implementation who = doesn't support this. Just in case not obvious, that includes me. >>>>>=20 >>>>> Does anyone with an implementation have an issue? >>>>>=20 >>>>>=20 >>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>=20 >>>>>> May I read that there are problems? >>>>>> If so, we cannot bring out a std track RFC followed up with = something that can not interoperate with it. Or we mark the to_be RFC as = obsolete. That's how it works. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>> PS1. you mentioned something about IESG and correctness... >>>>>> PS2: I understand the motivation. discussion could be how to deal = with it. >>>>>>=20 >>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: >>>>>>=20 >>>>>>> I think my starting point with such a discussion would be who = has an implementation? Yes, there are possible minor issues for = implementations (though it's also possible for an implementation to need = no changes at all). But the most pointless thing would be protecting (in = a minor way) hypothetical implementations while people actually with = them want this. >>>>>>>=20 >>>>>>> (I'm not saying those with them have all said they want this. = I'm asking.) >>>>>>>=20 >>>>>>> -- =20 >>>>>>> Christopher Dearlove >>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>=20 >>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>>>=20 >>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce = problems in a network with and without routers that implement this? >>>>>>>> If so, I think we need some discussion first. >>>>>>>>=20 >>>>>>>> Teco >>>>>>>>=20 >>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>>>>>>>=20 >>>>>>>>> OK, so to the WG - do we have consensus to adopt these = documents as working group docs?=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Stan >>>>>>>>>=20 >>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >>>>>>>>>=20 >>>>>>>>>> I don't believe that the chairs have raised the WG adoption = of the IDs I presented at Berlin. >>>>>>>>>>=20 >>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization = and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>>>>>>>>>=20 >>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd = obvious have no problem with being adopted as a WG document, but it = needs at least one more revision, which we intend to do as an author = draft, so there isn't the same time pressure there. However of course we = would like discussion any time from now. >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> Christopher Dearlove >>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>>>=20 >>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> = ******************************************************************** >>>>>>>>>> This email and any attachments are confidential to the = intended >>>>>>>>>> recipient and may also be privileged. If you are not the = intended >>>>>>>>>> recipient please delete it from your system and notify the = sender. >>>>>>>>>> You should not copy it or use it for any purpose nor disclose = or >>>>>>>>>> distribute its contents to any other person. >>>>>>>>>> = ******************************************************************** >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> manet mailing list >>>>>>>>> manet@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>=20 From hrogge@googlemail.com Fri Aug 16 14:41:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA9821F9F40 for ; Fri, 16 Aug 2013 14:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWUIv7rprmIl for ; Fri, 16 Aug 2013 14:41:40 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8721F964C for ; Fri, 16 Aug 2013 14:41:40 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id c1so1376512qcz.19 for ; Fri, 16 Aug 2013 14:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=61/N2L0pDGiFblRp6fJPfL6lcw+3vcodMZJHDUXdPHQ=; b=YrfRTmTSe/DpreKPUVrQLNZqaaeKutVPB8FMKgl+YpuQtOJ2gtb95hQupDd2rpUjpw T5B/RUJvdJGSmRLli/fZMdhG1cIDqe6upTwr4BLoHS+MMBB7HWmvFkvR6FfWuSjxil0+ o01r34b9SzV4PX6Sjg2z+qA/60h+wUocse7cuWFogsWw5xZlJ5enYhX09YmZCmz69VTO SaLZDLpS0nXW0gxW8G+b4x7O/UYlXrNzMDMSgxvE2ozfEXqCZLH6O6Qjb/DZywrfXf5B JZqOl8GWomtOl1DxO2xp/f3L/p8qXsnYGUpF3tlrwR/yiiA1OjeNP28v0tkR+4gSgstF Ht6Q== X-Received: by 10.224.19.133 with SMTP id a5mr5805365qab.54.1376689300053; Fri, 16 Aug 2013 14:41:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.203.7 with HTTP; Fri, 16 Aug 2013 14:41:19 -0700 (PDT) In-Reply-To: <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> From: Henning Rogge Date: Fri, 16 Aug 2013 23:41:19 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org List" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 21:41:42 -0000 If I understand the draft right we have the following situations: 1) an "old" implementation should interop with a "new" one without any extensions easily. 2) an "old" implementation might just drop messages from a "new" implementation which use an extension Henning Rogge On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: > Yes. > > Teco > > Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove het volgende geschreven: > >> Have you read the draft? >> >> -- >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >> >> On 16 Aug 2013, at 21:58, Teco Boot wrote: >> >>> I understand the change is documented. >>> My concerns are on what happens when different implementations are in s= ame network. This has to be documented. Asking on mailing list is not enoug= h. >>> >>> Teco >>> >>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove het volgende geschreven: >>> >>>> I think you are quite wrong on the obsoleted point. Especially when we= are talking changes to define what was previously undefined. Nothing defin= ed has changed. Which is just like the TOS change. >>>> >>>> But if you want to know what's changed, read the draft. >>>> >>>> I'd be interested in hearing from people with implementations. If the = bottom line is that there isn't anyone with an implementation who has a pro= blem, I think worries over a hypothetical unwritten implementation are rath= er beside the point. Anyone coming to something new could always check the = "updated by" bit. >>>> >>>> >>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>> >>>>> If anyone in the future writes code that complies with std track RFC,= he/she may assume that it is compatible with any other implementation. If = an update of that RFC will break compatibility, that RFC shall be obsoleted= , I think. >>>>> >>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are to b= e used to guide", "may". Remapping to DSCP is highly backwards compatible. >>>>> >>>>> Did I say I'm against? I just want to know the issues / problems. At = least they should be documented. >>>>> >>>>> Teco >>>>> >>>>> >>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove het volgende geschreven: >>>>> >>>>>> You can read this that there are minor issues, which I wouldn't elev= ate to the level of problems. >>>>>> >>>>>> Your comment on the inability to modify RFCs is just plain wrong. Wa= s RFC 791 obsoleted when the TOS bits function was changed? No. Many more s= uch examples could be given. >>>>>> >>>>>> I'm actually not aware of anyone with an implementation who doesn't = support this. Just in case not obvious, that includes me. >>>>>> >>>>>> Does anyone with an implementation have an issue? >>>>>> >>>>>> >>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>> >>>>>>> May I read that there are problems? >>>>>>> If so, we cannot bring out a std track RFC followed up with somethi= ng that can not interoperate with it. Or we mark the to_be RFC as obsolete.= That's how it works. >>>>>>> >>>>>>> Teco >>>>>>> >>>>>>> PS1. you mentioned something about IESG and correctness... >>>>>>> PS2: I understand the motivation. discussion could be how to deal w= ith it. >>>>>>> >>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove het volgende geschreven: >>>>>>> >>>>>>>> I think my starting point with such a discussion would be who has = an implementation? Yes, there are possible minor issues for implementations= (though it's also possible for an implementation to need no changes at all= ). But the most pointless thing would be protecting (in a minor way) hypoth= etical implementations while people actually with them want this. >>>>>>>> >>>>>>>> (I'm not saying those with them have all said they want this. I'm = asking.) >>>>>>>> >>>>>>>> -- >>>>>>>> Christopher Dearlove >>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>> >>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>>>> >>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce pro= blems in a network with and without routers that implement this? >>>>>>>>> If so, I think we need some discussion first. >>>>>>>>> >>>>>>>>> Teco >>>>>>>>> >>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) het volgende geschreven: >>>>>>>>> >>>>>>>>>> OK, so to the WG - do we have consensus to adopt these documents= as working group docs? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Stan >>>>>>>>>> >>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" wrote: >>>>>>>>>> >>>>>>>>>>> I don't believe that the chairs have raised the WG adoption of = the IDs I presented at Berlin. >>>>>>>>>>> >>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and= draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards = Track, and as minor updates to NHDP and OLSRv2, which we would like to prog= ress as fast as possible. >>>>>>>>>>> >>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvi= ous have no problem with being adopted as a WG document, but it needs at le= ast one more revision, which we intend to do as an author draft, so there i= sn't the same time pressure there. However of course we would like discussi= on any time from now. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Christopher Dearlove >>>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>>>> >>>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerosp= ace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ***************************************************************= ***** >>>>>>>>>>> This email and any attachments are confidential to the intended >>>>>>>>>>> recipient and may also be privileged. If you are not the intend= ed >>>>>>>>>>> recipient please delete it from your system and notify the send= er. >>>>>>>>>>> You should not copy it or use it for any purpose nor disclose o= r >>>>>>>>>>> distribute its contents to any other person. >>>>>>>>>>> ***************************************************************= ***** >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> manet mailing list >>>>>>>>>> manet@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> manet mailing list >>>>>>>>> manet@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From teco@inf-net.nl Sat Aug 17 00:37:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0652C21F9C0E for ; Sat, 17 Aug 2013 00:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85Sa0Hgi6wGg for ; Sat, 17 Aug 2013 00:37:00 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 710DC21F9C53 for ; Sat, 17 Aug 2013 00:36:58 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d17so1266134eek.14 for ; Sat, 17 Aug 2013 00:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BUYAAQf5MGY+y1fce4hcOsXwxiB8c5fjoFLtOvdFlA8=; b=VPVASZGRNlgdjWa3vaG0pE8Vm2n8BBa+Sux+YAN5WBonm2QWdIw2CuehirkFK44sWD vJp0Xv0jV7dg+v5FoiORCLvIXvNL/COaspA7RI+OPKWU8CQONgqhfxI6NmReUc2NDp5H JLbVo16tPgdGtHUWMwts+MKclcg1TIwj3LkVDd1Lj/BVf3Q0RUpiaiBRKPYDki/UHzGh Q+5vYglROYV1XCDPQhfYXly9x9zkHkSO2gqRdh05osGdswJI9s7Ov2nbaaE6LhM9hCqi Os3z1Dbhu9ZMlJ2PatjBiZboqweUeZC5mgM1nc1i8McpjA93oKIDu5Dcb/mD0qcydY1V RFgA== X-Gm-Message-State: ALoCoQnizL7JkI1LD5a8MCbwI36dkAQfpicJqkhTafcWQpQdHm6oIdEplrWyscOiip3ovOUSWdTa X-Received: by 10.14.122.69 with SMTP id s45mr379943eeh.58.1376725015764; Sat, 17 Aug 2013 00:36:55 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id a1sm1884463eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Aug 2013 00:36:54 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Sat, 17 Aug 2013 09:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1508) Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org List" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 07:37:05 -0000 Can I read this as: 1) an implementations that did not implement this new specification = might drop these new messages and therefore is not compatible 2) an implementations that did not implement this new specification = might accept these new messages and therefore is compatible "old" of "new" is not important. It is about stability of the standard. = We have to stop incremental changes that are not backwards compatible. = Or step to new version or similar tag. Teco Op 16 aug. 2013, om 23:41 heeft Henning Rogge = het volgende geschreven: > If I understand the draft right we have the following situations: >=20 > 1) an "old" implementation should interop with a "new" one without any > extensions easily. > 2) an "old" implementation might just drop messages from a "new" > implementation which use an extension >=20 > Henning Rogge >=20 > On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >> Yes. >>=20 >> Teco >>=20 >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove = het volgende geschreven: >>=20 >>> Have you read the draft? >>>=20 >>> -- >>> Christopher Dearlove >>> christopher.dearlove@gmail.com (iPhone) >>> chris@mnemosyne.demon.co.uk (home) >>>=20 >>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>>=20 >>>> I understand the change is documented. >>>> My concerns are on what happens when different implementations are = in same network. This has to be documented. Asking on mailing list is = not enough. >>>>=20 >>>> Teco >>>>=20 >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove = het volgende geschreven: >>>>=20 >>>>> I think you are quite wrong on the obsoleted point. Especially = when we are talking changes to define what was previously undefined. = Nothing defined has changed. Which is just like the TOS change. >>>>>=20 >>>>> But if you want to know what's changed, read the draft. >>>>>=20 >>>>> I'd be interested in hearing from people with implementations. If = the bottom line is that there isn't anyone with an implementation who = has a problem, I think worries over a hypothetical unwritten = implementation are rather beside the point. Anyone coming to something = new could always check the "updated by" bit. >>>>>=20 >>>>>=20 >>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>>>=20 >>>>>> If anyone in the future writes code that complies with std track = RFC, he/she may assume that it is compatible with any other = implementation. If an update of that RFC will break compatibility, that = RFC shall be obsoleted, I think. >>>>>>=20 >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are = to be used to guide", "may". Remapping to DSCP is highly backwards = compatible. >>>>>>=20 >>>>>> Did I say I'm against? I just want to know the issues / problems. = At least they should be documented. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>=20 >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove = het volgende geschreven: >>>>>>=20 >>>>>>> You can read this that there are minor issues, which I wouldn't = elevate to the level of problems. >>>>>>>=20 >>>>>>> Your comment on the inability to modify RFCs is just plain = wrong. Was RFC 791 obsoleted when the TOS bits function was changed? No. = Many more such examples could be given. >>>>>>>=20 >>>>>>> I'm actually not aware of anyone with an implementation who = doesn't support this. Just in case not obvious, that includes me. >>>>>>>=20 >>>>>>> Does anyone with an implementation have an issue? >>>>>>>=20 >>>>>>>=20 >>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>>>=20 >>>>>>>> May I read that there are problems? >>>>>>>> If so, we cannot bring out a std track RFC followed up with = something that can not interoperate with it. Or we mark the to_be RFC as = obsolete. That's how it works. >>>>>>>>=20 >>>>>>>> Teco >>>>>>>>=20 >>>>>>>> PS1. you mentioned something about IESG and correctness... >>>>>>>> PS2: I understand the motivation. discussion could be how to = deal with it. >>>>>>>>=20 >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: >>>>>>>>=20 >>>>>>>>> I think my starting point with such a discussion would be who = has an implementation? Yes, there are possible minor issues for = implementations (though it's also possible for an implementation to need = no changes at all). But the most pointless thing would be protecting (in = a minor way) hypothetical implementations while people actually with = them want this. >>>>>>>>>=20 >>>>>>>>> (I'm not saying those with them have all said they want this. = I'm asking.) >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Christopher Dearlove >>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>>=20 >>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>>>>>=20 >>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce = problems in a network with and without routers that implement this? >>>>>>>>>> If so, I think we need some discussion first. >>>>>>>>>>=20 >>>>>>>>>> Teco >>>>>>>>>>=20 >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>>>>>>>>>=20 >>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these = documents as working group docs? >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Stan >>>>>>>>>>>=20 >>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I don't believe that the chairs have raised the WG adoption = of the IDs I presented at Berlin. >>>>>>>>>>>>=20 >>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization = and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>>>>>>>>>>>=20 >>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd = obvious have no problem with being adopted as a WG document, but it = needs at least one more revision, which we intend to do as an author = draft, so there isn't the same time pressure there. However of course we = would like discussion any time from now. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK >>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>>>>>=20 >>>>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> = ******************************************************************** >>>>>>>>>>>> This email and any attachments are confidential to the = intended >>>>>>>>>>>> recipient and may also be privileged. If you are not the = intended >>>>>>>>>>>> recipient please delete it from your system and notify the = sender. >>>>>>>>>>>> You should not copy it or use it for any purpose nor = disclose or >>>>>>>>>>>> distribute its contents to any other person. >>>>>>>>>>>> = ******************************************************************** >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> manet mailing list >>>>>>>>>>> manet@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> manet mailing list >>>>>>>>>> manet@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan From jrjiang@csie.ncu.edu.tw Mon Aug 19 02:07:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75E911E8217 for ; Mon, 19 Aug 2013 02:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTgKfHudb7QD for ; Mon, 19 Aug 2013 02:07:36 -0700 (PDT) Received: from relay.csie.ncu.edu.tw (relay.csie.ncu.edu.tw [140.115.50.18]) by ietfa.amsl.com (Postfix) with ESMTP id E504A11E8215 for ; Mon, 19 Aug 2013 02:07:35 -0700 (PDT) Received: by relay.csie.ncu.edu.tw (Postfix, from userid 11260) id AF3E2FD21A; Mon, 19 Aug 2013 17:07:35 +0800 (CST) Received: from relay.csie.ncu.edu.tw (localhost [127.0.0.1]) by relay.csie.ncu.edu.tw (Postfix) with ESMTP id 637D9FD20C for ; Mon, 19 Aug 2013 17:07:35 +0800 (CST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) (Authenticated sender: jrjiang) by relay.csie.ncu.edu.tw (Postfix) with ESMTPSA id BFF21FD1F0 for ; Mon, 19 Aug 2013 17:07:34 +0800 (CST) Received: by mail-oa0-f45.google.com with SMTP id m1so5497066oag.18 for ; Mon, 19 Aug 2013 02:07:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EQgfc6yiOZac3h3acYotYei9NNEfe9yhUQoU3DYiFCw=; b=YZrKqzuZ6PTI8oHOaGVI3hWYmO7aF11waPRzmddxyvY2BfWHra1yDnbIozaDkKMkRH 6/0Ro1J/Gw+ixXM3gzabham0ypdjmUqAgNVDi49TT90GY/V6vpZvDQLRVKjHQB43jKfg nveiJSjOYsWDCdm1ptmw+OnCphCAR8Awt5hYrqnFe/V3nDpHg5bKgrIklnOzMrIa0PNA 5Td0w29Kn+YMJqIv1trLQUE7/9Tu2aIWh7LZAfZnhBYhvGie09udLTto/wQtzAM8wlr8 57cX3QYltRSmub3QgjpB++cSu+43WzPWzCH0Ik6hfrebQYy9n+MMBF+IO7WNuyini5y5 j3MQ== MIME-Version: 1.0 X-Received: by 10.182.226.199 with SMTP id ru7mr11971619obc.12.1376903250835; Mon, 19 Aug 2013 02:07:30 -0700 (PDT) Received: by 10.76.35.129 with HTTP; Mon, 19 Aug 2013 02:07:30 -0700 (PDT) Date: Mon, 19 Aug 2013 17:07:30 +0800 Message-ID: From: "J.-R. Jiang" To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a11c309aa28033804e449455a X-Virus-Scanned: ClamAV using ClamSMTP X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 Subject: [manet] New Deadline for IoTT 2013 (International Workshop on Internet of Things Technologies) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 09:12:30 -0000 --001a11c309aa28033804e449455a Content-Type: text/plain; charset=ISO-8859-1 Dear Colleagues, Please find the attached CFP for the International Workshop on Internet of Things Technologies (http://acnlab.csie.ncu.edu.tw/IoTT2013/) to be held in Seoul, Korea, on Dec. 15, 2013, in conjunction with the 19th IEEE International Conference on Parallel and Distributed Systems (ICPADS 2013) ( http://aces.snu.ac.kr/icpads13/Home.html) sponsored by IEEE and IEEE Computer Society. Submission Deadline August 30, 2013 (extended) Please consider submitting to this workshop, whose main focus is on the latest cutting-edge research of IoT Technologies. Regards, Workshop Chair: Jehn-Ruey Jiang National Central University, Taiwan Call for Papers IoTT 2013 The 1st International Workshop on Internet of Things Technologies in conjunction with The 19th IEEE International Conference on Parallel and Distributed Systems (ICPADS 2013) December 15-18, 2013 Seoul, Korea PURPOSE AND SCOPE The concept of the Internet of Things (IoT) is to connect anything at anytime and anywhere with an Internet-like structure. The IoT stresses on the machine type communication or Machine-to-Machine (M2M) communication, by which all devices, like home appliances, cars, vending machines, industrial instruments, and data collecting sensors, are connected together to provide service without human intervention. IoT technologies are shaping our daily lives; many IoT applications are booming, including logistics management, intelligent transportation, home automation, personal healthcare, and so on. There are many IoT-enabling technologies, such as RFID-capable, Bluetooth-capable, and Zigbee-capable devices from the device domain aspects, as well as the 3GPP Long Term Evolution/Long Term Evolution-advance (3GPP LTE/LTE-A) networks, Wireless Local Area Networks (WLANs), Wireless Sensor Networks (WSNs), and Vehicular Ad-hoc Networks (VANETs) from the network domain aspect. Many excellent studies related to IoT technologies have been made in recent years. However, some open issues are yet to be examined and discussed for realizing the IoT world. The purpose of IoTT 2013 is to solicit original new ideas on general IoT issues as well as on the design, development and deployment issues of both device-domain and network-domain IoT technologies. The workshop aims to facilitate discussions and idea exchanges by both academics and practitioners. TOPICS OF INTEREST Topics of interest include, but are not limited to: - IoT architectures, protocols, and algorithms - IoT device domain technologies (RFID, Bluetooth, Zigbee) - IoT network domain technologies (GSM, UMTS, LTE/LTE-A, WSN, VANET) - Performance evaluation of IoT technologies - Data management in IoT - Localization in IoT - Security, trust, and privacy issues in IoT - IoT tagging things technology and applications - IoT sensing things technology and applications - IoT shrinking things technology and applications - IoT thinking things technology and applications IMPORTANT DATES Submission: August 30, 2013 Notification: September 20, 2013 Author Registration: September 30, 2013 Camera ready: October 7, 2013 PAPER SUBMISSION Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 6 double-columned, single-spaced pages, to the workshop web site (http://acnlab.csie.ncu.edu.tw/IoTT2013/). Submitted papers should be in accordance with IEEE Computer Society guidelines (http://www.computer.org/portal/web/cscps/formatting), and will be refereed by reviewers in terms of relevance, originality, contribution, correctness, and presentation. All accepted papers will be included in IEEE Xplore and indexed by EI. Program Chair Jehn-Ruey Jiang --001a11c309aa28033804e449455a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Colleagues,

Please find the attached CFP for the=A0International Workshop on= Internet of Things Technologies (http://acnlab.csie.ncu.edu.tw/IoTT2013/)= =A0to be held in Seoul, Korea,=A0on Dec. 15, 2013,=A0in conjunctio= n with the 19th IEEE International Conference on Paral= lel and Distributed Systems (ICPADS 2013) (http://aces.snu.ac.kr/icpads13/Home.htm= l) sponsored by=A0=A0IEEE and IEEE Computer Society.

Submission Deadline
August 30, 2013=A0 (e= xtended)

Please consider submitting to this workshop, whose = main focus is on the latest cutting-edge research of IoT Technologies.

Regards,
Workshop Cha= ir:=A0Jehn-Ruey Jiang <jrjiang@csie.ncu.edu.tw>
National Central University, Taiwan
=

Call for Pap= ers
IoTT 2013=
The 1st Inte= rnational Workshop on Internet of Things Technologies
in conjunction with
The 19th IEEE Inte= rnational Conference on Parallel and Distributed Systems (ICPADS 2013)=A0
December 15-18, 2013
Seoul, Korea

=
PURPOSE AND SCOPE
=A0
The concept of the Internet of Things (IoT) is to connect any= thing at anytime and anywhere with an Internet-like structure. The IoT stre= sses on the machine type communication or Machine-to-Machine (M2M) communic= ation, by which all devices, like home appliances, cars, vending machines, = industrial instruments, and data collecting sensors, are connected together= to provide service without human intervention. IoT technologies are shapin= g our daily lives; many IoT applications are booming, including logistics m= anagement, intelligent transportation, home automation, personal healthcare= , and so on.

There are many IoT-enabling technolog= ies, such as RFID-capable, Bluetooth-capable, and Zigbee-capable devices fr= om the device domain aspects, as well as the 3GPP Long Term Evolution/Long = Term Evolution-advance (3GPP LTE/LTE-A) networks, Wireless Local Area Netwo= rks (WLANs), Wireless Sensor Networks (WSNs), and Vehicular Ad-hoc Networks= (VANETs) from the network domain aspect. Many excellent studies related to= IoT technologies have been made in recent years. However, some open issues= are yet to be examined and discussed for realizing the IoT world.

The purpos= e of IoTT 2013 is to solicit original new ideas on general IoT issues as we= ll as on the design, development and deployment issues of both device-domai= n and network-domain IoT technologies. The workshop aims to facilitate disc= ussions and idea exchanges by both academics and practitioners.=A0


TOPICS OF INTEREST
=A0<= /font>
Topics of inter= est include, but are not limited to:
  • IoT architectures, protocols, and algorithms
  • IoT device domain technologies (RFID= , Bluetooth, Zigbee)
  • IoT network domain technolo= gies (GSM, UMTS, LTE/LTE-A, WSN, VANET)
  • Performance evaluation of IoT technologies
  • Data management in IoT
  • Localization in IoT
  • Security, trust, and privacy issues in IoT
  • IoT tagging things technolo= gy and applications
  • IoT sensing things technology and applications
  • IoT shrinking things technology and applications
  • IoT thinking things techn= ology and applications
=A0
IMPORTANT DATES
=A0
Submission: =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0August 30, 2013
Notification: =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 September 20, 2013
Author Registration: =A0 =A0 =A0 =A0Septemb= er 30, 2013
Camera ready: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October 7, 20= 13
=A0
PAPER SUBMISSION=A0

Authors are invited to submit an electronic versio= n of original, unpublished manuscripts, not to exceed 6 double-columned, si= ngle-spaced pages, to the workshop web site (http://acnlab.csie.ncu.edu.tw/IoTT2= 013/). Submitted papers should be in accordance with IEEE Computer Soci= ety guidelines (http://www.computer.org/portal/web/cscps/formatting<= /a>), and will be refereed by reviewers in terms of relevance, originality,= contribution, correctness, and presentation. All accepted papers will be i= ncluded in IEEE Xplore and indexed by EI.

Program Chair


--001a11c309aa28033804e449455a-- From chris.dearlove@baesystems.com Tue Aug 27 02:40:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9750521E8050 for ; Tue, 27 Aug 2013 02:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7883+ULwQWU for ; Tue, 27 Aug 2013 02:40:15 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1219411E811F for ; Tue, 27 Aug 2013 02:40:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,967,1367967600"; d="scan'208";a="309329577" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 27 Aug 2013 10:40:13 +0100 X-IronPort-AV: E=Sophos;i="4.89,967,1367967600"; d="scan'208";a="26594145" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 27 Aug 2013 10:40:13 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.167]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Tue, 27 Aug 2013 10:40:13 +0100 From: "Dearlove, Christopher (UK)" To: Teco Boot , Henning Rogge Thread-Topic: [manet] IDs presemted in Berlin Thread-Index: Ac6af5Fq3se/1MLIS0GTdRoITUFK2gAQNj+A//+hu4CAAAwzgIAABjKAgAACSICAADX0AIAAAuWAgAAFzACAAAPmgIAABsyAgAABV4CAAKZkgP/wFrpw Date: Tue, 27 Aug 2013 09:40:13 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> In-Reply-To: <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christopher Dearlove , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 09:40:19 -0000 I thought I'd replied to this, but can't see on list. I think your characte= risation of this whole issue is wrong. Currently, there is no specification what to do when seeing an unknown valu= e. This defines one. Of course with no specification, people can do anythin= g (including dropping the message). That's undesirable, let's fix it. As for the sacrosanctness of the specification, let's be real. How many imp= lementations actually are there yet? Is there anyone with one who finds thi= s other than a positive thing? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 17 August 2013 08:37 To: Henning Rogge Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org List; = Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen (thomas@thoma= sclausen.org); Stan Ratliff (sratliff) Subject: Re: [manet] IDs presemted in Berlin ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Can I read this as: 1) an implementations that did not implement this new specification might d= rop these new messages and therefore is not compatible 2) an implementations that did not implement this new specification might a= ccept these new messages and therefore is compatible "old" of "new" is not important. It is about stability of the standard. We = have to stop incremental changes that are not backwards compatible. Or step= to new version or similar tag. Teco Op 16 aug. 2013, om 23:41 heeft Henning Rogge het v= olgende geschreven: > If I understand the draft right we have the following situations: >=20 > 1) an "old" implementation should interop with a "new" one without any > extensions easily. > 2) an "old" implementation might just drop messages from a "new" > implementation which use an extension >=20 > Henning Rogge >=20 > On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >> Yes. >>=20 >> Teco >>=20 >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove het volgende geschreven: >>=20 >>> Have you read the draft? >>>=20 >>> -- >>> Christopher Dearlove >>> christopher.dearlove@gmail.com (iPhone) >>> chris@mnemosyne.demon.co.uk (home) >>>=20 >>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>>=20 >>>> I understand the change is documented. >>>> My concerns are on what happens when different implementations are in = same network. This has to be documented. Asking on mailing list is not enou= gh. >>>>=20 >>>> Teco >>>>=20 >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove het volgende geschreven: >>>>=20 >>>>> I think you are quite wrong on the obsoleted point. Especially when w= e are talking changes to define what was previously undefined. Nothing defi= ned has changed. Which is just like the TOS change. >>>>>=20 >>>>> But if you want to know what's changed, read the draft. >>>>>=20 >>>>> I'd be interested in hearing from people with implementations. If the= bottom line is that there isn't anyone with an implementation who has a pr= oblem, I think worries over a hypothetical unwritten implementation are rat= her beside the point. Anyone coming to something new could always check the= "updated by" bit. >>>>>=20 >>>>>=20 >>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>>>=20 >>>>>> If anyone in the future writes code that complies with std track RFC= , he/she may assume that it is compatible with any other implementation. If= an update of that RFC will break compatibility, that RFC shall be obsolete= d, I think. >>>>>>=20 >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are to = be used to guide", "may". Remapping to DSCP is highly backwards compatible. >>>>>>=20 >>>>>> Did I say I'm against? I just want to know the issues / problems. At= least they should be documented. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>=20 >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove het volgende geschreven: >>>>>>=20 >>>>>>> You can read this that there are minor issues, which I wouldn't ele= vate to the level of problems. >>>>>>>=20 >>>>>>> Your comment on the inability to modify RFCs is just plain wrong. W= as RFC 791 obsoleted when the TOS bits function was changed? No. Many more = such examples could be given. >>>>>>>=20 >>>>>>> I'm actually not aware of anyone with an implementation who doesn't= support this. Just in case not obvious, that includes me. >>>>>>>=20 >>>>>>> Does anyone with an implementation have an issue? >>>>>>>=20 >>>>>>>=20 >>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>>>=20 >>>>>>>> May I read that there are problems? >>>>>>>> If so, we cannot bring out a std track RFC followed up with someth= ing that can not interoperate with it. Or we mark the to_be RFC as obsolete= . That's how it works. >>>>>>>>=20 >>>>>>>> Teco >>>>>>>>=20 >>>>>>>> PS1. you mentioned something about IESG and correctness... >>>>>>>> PS2: I understand the motivation. discussion could be how to deal = with it. >>>>>>>>=20 >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove het volgende geschreven: >>>>>>>>=20 >>>>>>>>> I think my starting point with such a discussion would be who has= an implementation? Yes, there are possible minor issues for implementation= s (though it's also possible for an implementation to need no changes at al= l). But the most pointless thing would be protecting (in a minor way) hypot= hetical implementations while people actually with them want this. >>>>>>>>>=20 >>>>>>>>> (I'm not saying those with them have all said they want this. I'm= asking.) >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Christopher Dearlove >>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>>=20 >>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>>>>>=20 >>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce pr= oblems in a network with and without routers that implement this? >>>>>>>>>> If so, I think we need some discussion first. >>>>>>>>>>=20 >>>>>>>>>> Teco >>>>>>>>>>=20 >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) het volgende geschreven: >>>>>>>>>>=20 >>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these document= s as working group docs? >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Stan >>>>>>>>>>>=20 >>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I don't believe that the chairs have raised the WG adoption of= the IDs I presented at Berlin. >>>>>>>>>>>>=20 >>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization an= d draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards= Track, and as minor updates to NHDP and OLSRv2, which we would like to pro= gress as fast as possible. >>>>>>>>>>>>=20 >>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd obv= ious have no problem with being adopted as a WG document, but it needs at l= east one more revision, which we intend to do as an author draft, so there = isn't the same time pressure there. However of course we would like discuss= ion any time from now. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>>>>>=20 >>>>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aeros= pace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> **************************************************************= ****** >>>>>>>>>>>> This email and any attachments are confidential to the intende= d >>>>>>>>>>>> recipient and may also be privileged. If you are not the inten= ded >>>>>>>>>>>> recipient please delete it from your system and notify the sen= der. >>>>>>>>>>>> You should not copy it or use it for any purpose nor disclose = or >>>>>>>>>>>> distribute its contents to any other person. >>>>>>>>>>>> **************************************************************= ****** >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> manet mailing list >>>>>>>>>>> manet@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> manet mailing list >>>>>>>>>> manet@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan From abdussalambaryun@gmail.com Tue Aug 27 03:06:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C186211E810B for ; Tue, 27 Aug 2013 03:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4veMNmCnNI9 for ; Tue, 27 Aug 2013 03:06:55 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5E811E80FA for ; Tue, 27 Aug 2013 03:06:55 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so4595925pad.5 for ; Tue, 27 Aug 2013 03:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HSx29zIixdEA2zkFr5fcR0hhfQY2lqFgQZSUFmUc6e4=; b=wtScbq1AfEHIaiukUGc3s6SrEAACoe5trKBI1ZtqZDWqv4whDou7vEGxuZQXJCZ/Tf YWj4yQ0jA5i6m7vjVyq3ESYKoTZ3lY7M+pAoh6ecPzzLZamaTGED0xcNXkUFgYf7jONd OrhlS60nEOUaj1SjYv/kRCOrKHAA/0KdIf1Kr2VLnhSJ6q79zARA0mXnTJ6b9JWKquHo /0YlXOkLSq+XC6t1nRgo6secsZPSBorsQxNdUL+oaCsGJHlZQDRYHLN373/8UfPg3IDL 2W4RLBHaQia83ns0EBGJeJwjxTCHAxWWljbkGF1ywf+/JtrixSF0JlZR9D//n5vBaQmn 8x9A== MIME-Version: 1.0 X-Received: by 10.66.175.133 with SMTP id ca5mr19790820pac.40.1377598013873; Tue, 27 Aug 2013 03:06:53 -0700 (PDT) Received: by 10.68.195.168 with HTTP; Tue, 27 Aug 2013 03:06:53 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> Date: Tue, 27 Aug 2013 20:06:53 +1000 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=047d7bdca3fe42a3c104e4eb08a2 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 10:06:57 -0000 --047d7bdca3fe42a3c104e4eb08a2 Content-Type: text/plain; charset=ISO-8859-1 Hi Co-Chair, I don't agree to adopt any draft only after reviewed by WG and getting answers/discussions of all questions of the WG related. If that is done then I have no objection. AB On Sat, Aug 17, 2013 at 1:37 AM, Stan Ratliff (sratliff) wrote: > OK, so to the WG - do we have consensus to adopt these documents as > working group docs? > > Regards, > Stan > > On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" < > chris.dearlove@baesystems.com> wrote: > > > I don't believe that the chairs have raised the WG adoption of the IDs I > presented at Berlin. > > > > Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and > draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards > Track, and as minor updates to NHDP and OLSRv2, which we would like to > progress as fast as possible. > > > > The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious have > no problem with being adopted as a WG document, but it needs at least one > more revision, which we intend to do as an author draft, so there isn't the > same time pressure there. However of course we would like discussion any > time from now. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7bdca3fe42a3c104e4eb08a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Co-Chair,

I don't agree to= adopt any draft only after reviewed by WG and getting answers/discussions = of all questions of the WG related. If that is done then I have no objectio= n.

AB

On Sat, Aug 17, 2013 at 1:37 AM, Stan Ratl= iff (sratliff) <sratliff@cisco.com> wrote:
OK, so to the WG - do we have consensus to a= dopt these documents as working group docs?

Regards,
Stan

On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com= > wrote:

> I don't believe that the chairs have raised the WG adoption of the= IDs I presented at Berlin.
>
> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and draft-= dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards Track, = and as minor updates to NHDP and OLSRv2, which we would like to progress as= fast as possible.
>
> The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious= have no problem with being adopted as a WG document, but it needs at least= one more revision, which we intend to do as an author draft, so there isn&= #39;t the same time pressure there. However of course we would like discuss= ion any time from now.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44= 1245 242194 | =A0Fax: +44 1245 242124
> chris.dearlove@baesys= tems.com | http= ://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> ******************************************************************** > This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ******************************************************************** >

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7bdca3fe42a3c104e4eb08a2-- From teco@inf-net.nl Tue Aug 27 04:03:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D4B11E820E for ; Tue, 27 Aug 2013 04:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvx7mANBCETv for ; Tue, 27 Aug 2013 04:03:11 -0700 (PDT) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7211E825A for ; Tue, 27 Aug 2013 04:03:08 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id a15so2191144eae.9 for ; Tue, 27 Aug 2013 04:03:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3KBdOcO+su2bD9hZAmKiXWS2MGD+wP0gveIrFlFSKts=; b=QcHXUdMlA2w7UjkzQSft2KKYWtQzKkTDDiZxHmeUVtmu0OrpS+4W/9pdap9CopDyy1 nw9HSq50slFXETQr1ytq5gtoUlYgotNPrMqz8X3ArhKZkNZ9mMZAyV2Lwl8SkevEplUC vQ/eo2kmPmnizcb0LzKEeOf0Pmgt4Kx/KAEdXTyZ1Dm966RdnT4rJm5Cf+MaSOTS34n3 tOUDYmuDONywCkSlEw8099ZFVIkz23zWOWcyuK6qx2EIAG5cTEJvz6BWh+wB7tHAEhOb UTeFL1Zl5aNdrHXTXKN9bknFfJLZ2vPY5h6v7GmPx07wQdIOvCxnhJdl1hDPLM8F2Skn WwLg== X-Gm-Message-State: ALoCoQk9RBD3K4TGRlRSX8qOIbMDLzIF2a3/ML2hsEXrxoTWLyf2vhAQqVYv13XXgsO5dbBw39vX X-Received: by 10.15.22.138 with SMTP id f10mr138807eeu.126.1377601387978; Tue, 27 Aug 2013 04:03:07 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id k7sm28271077eeg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 04:03:07 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Tue, 27 Aug 2013 13:03:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1508) Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , Christopher Dearlove , "manet@ietf.org List" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 11:03:15 -0000 My concerns are about struggle getting away from experimental status. If the intention is that the RFC have to implement something what was = not written down that well, I think an errata would work. Then the new = draft just has to specify how to use it. If the new RFC breaks compatibility, I wonder if this is worth the = effort. Teco Op 27 aug. 2013, om 11:40 heeft "Dearlove, Christopher (UK)" = het volgende geschreven: > I thought I'd replied to this, but can't see on list. I think your = characterisation of this whole issue is wrong. >=20 > Currently, there is no specification what to do when seeing an unknown = value. This defines one. Of course with no specification, people can do = anything (including dropping the message). That's undesirable, let's fix = it. >=20 > As for the sacrosanctness of the specification, let's be real. How = many implementations actually are there yet? Is there anyone with one = who finds this other than a positive thing? >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: 17 August 2013 08:37 > To: Henning Rogge > Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org = List; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen = (thomas@thomasclausen.org); Stan Ratliff (sratliff) > Subject: Re: [manet] IDs presemted in Berlin >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Can I read this as: >=20 > 1) an implementations that did not implement this new specification = might drop these new messages and therefore is not compatible > 2) an implementations that did not implement this new specification = might accept these new messages and therefore is compatible >=20 > "old" of "new" is not important. It is about stability of the = standard. We have to stop incremental changes that are not backwards = compatible. Or step to new version or similar tag. >=20 > Teco >=20 > Op 16 aug. 2013, om 23:41 heeft Henning Rogge = het volgende geschreven: >=20 >> If I understand the draft right we have the following situations: >>=20 >> 1) an "old" implementation should interop with a "new" one without = any >> extensions easily. >> 2) an "old" implementation might just drop messages from a "new" >> implementation which use an extension >>=20 >> Henning Rogge >>=20 >> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >>> Yes. >>>=20 >>> Teco >>>=20 >>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove = het volgende geschreven: >>>=20 >>>> Have you read the draft? >>>>=20 >>>> -- >>>> Christopher Dearlove >>>> christopher.dearlove@gmail.com (iPhone) >>>> chris@mnemosyne.demon.co.uk (home) >>>>=20 >>>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>>>=20 >>>>> I understand the change is documented. >>>>> My concerns are on what happens when different implementations are = in same network. This has to be documented. Asking on mailing list is = not enough. >>>>>=20 >>>>> Teco >>>>>=20 >>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove = het volgende geschreven: >>>>>=20 >>>>>> I think you are quite wrong on the obsoleted point. Especially = when we are talking changes to define what was previously undefined. = Nothing defined has changed. Which is just like the TOS change. >>>>>>=20 >>>>>> But if you want to know what's changed, read the draft. >>>>>>=20 >>>>>> I'd be interested in hearing from people with implementations. If = the bottom line is that there isn't anyone with an implementation who = has a problem, I think worries over a hypothetical unwritten = implementation are rather beside the point. Anyone coming to something = new could always check the "updated by" bit. >>>>>>=20 >>>>>>=20 >>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>>>>=20 >>>>>>> If anyone in the future writes code that complies with std track = RFC, he/she may assume that it is compatible with any other = implementation. If an update of that RFC will break compatibility, that = RFC shall be obsoleted, I think. >>>>>>>=20 >>>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are = to be used to guide", "may". Remapping to DSCP is highly backwards = compatible. >>>>>>>=20 >>>>>>> Did I say I'm against? I just want to know the issues / = problems. At least they should be documented. >>>>>>>=20 >>>>>>> Teco >>>>>>>=20 >>>>>>>=20 >>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove = het volgende geschreven: >>>>>>>=20 >>>>>>>> You can read this that there are minor issues, which I wouldn't = elevate to the level of problems. >>>>>>>>=20 >>>>>>>> Your comment on the inability to modify RFCs is just plain = wrong. Was RFC 791 obsoleted when the TOS bits function was changed? No. = Many more such examples could be given. >>>>>>>>=20 >>>>>>>> I'm actually not aware of anyone with an implementation who = doesn't support this. Just in case not obvious, that includes me. >>>>>>>>=20 >>>>>>>> Does anyone with an implementation have an issue? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>> May I read that there are problems? >>>>>>>>> If so, we cannot bring out a std track RFC followed up with = something that can not interoperate with it. Or we mark the to_be RFC as = obsolete. That's how it works. >>>>>>>>>=20 >>>>>>>>> Teco >>>>>>>>>=20 >>>>>>>>> PS1. you mentioned something about IESG and correctness... >>>>>>>>> PS2: I understand the motivation. discussion could be how to = deal with it. >>>>>>>>>=20 >>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: >>>>>>>>>=20 >>>>>>>>>> I think my starting point with such a discussion would be who = has an implementation? Yes, there are possible minor issues for = implementations (though it's also possible for an implementation to need = no changes at all). But the most pointless thing would be protecting (in = a minor way) hypothetical implementations while people actually with = them want this. >>>>>>>>>>=20 >>>>>>>>>> (I'm not saying those with them have all said they want this. = I'm asking.) >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Christopher Dearlove >>>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>>>=20 >>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>>>>>>=20 >>>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension = introduce problems in a network with and without routers that implement = this? >>>>>>>>>>> If so, I think we need some discussion first. >>>>>>>>>>>=20 >>>>>>>>>>> Teco >>>>>>>>>>>=20 >>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>>>>>>>>>>=20 >>>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these = documents as working group docs? >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Stan >>>>>>>>>>>>=20 >>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> I don't believe that the chairs have raised the WG = adoption of the IDs I presented at Berlin. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Two of these, = draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd = obvious have no problem with being adopted as a WG document, but it = needs at least one more revision, which we intend to do as an author = draft, so there isn't the same time pressure there. However of course we = would like discussion any time from now. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK >>>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = ******************************************************************** >>>>>>>>>>>>> This email and any attachments are confidential to the = intended >>>>>>>>>>>>> recipient and may also be privileged. If you are not the = intended >>>>>>>>>>>>> recipient please delete it from your system and notify the = sender. >>>>>>>>>>>>> You should not copy it or use it for any purpose nor = disclose or >>>>>>>>>>>>> distribute its contents to any other person. >>>>>>>>>>>>> = ******************************************************************** >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> manet mailing list >>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> manet mailing list >>>>>>>>>>> manet@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> --=20 >> We began as wanderers, and we are wanderers still. We have lingered >> long enough on the shores of the cosmic ocean. We are ready at last = to >> set sail for the stars - Carl Sagan >=20 >=20 From chris.dearlove@baesystems.com Tue Aug 27 05:16:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F34921E804D for ; Tue, 27 Aug 2013 05:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMAVIWeO9wz4 for ; Tue, 27 Aug 2013 05:16:07 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id D247311E82DE for ; Tue, 27 Aug 2013 05:16:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,968,1367967600"; d="scan'208";a="309396397" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 27 Aug 2013 13:16:02 +0100 X-IronPort-AV: E=Sophos;i="4.89,968,1367967600"; d="scan'208";a="26627161" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 27 Aug 2013 13:16:01 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.167]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Tue, 27 Aug 2013 13:16:01 +0100 From: "Dearlove, Christopher (UK)" To: Teco Boot Thread-Topic: [manet] IDs presemted in Berlin Thread-Index: Ac6af5Fq3se/1MLIS0GTdRoITUFK2gAQNj+A//+hu4CAAAwzgIAABjKAgAACSICAADX0AIAAAuWAgAAFzACAAAPmgIAABsyAgAABV4CAAKZkgP/wFrpwgB/aMgD//9u/EA== Date: Tue, 27 Aug 2013 12:16:01 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , Christopher Dearlove , "manet@ietf.org List" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 12:16:11 -0000 The point of the new draft is to enable extensions more cleanly, and that's= used in the multitopology draft, it's not just change for change's sake. (= But neither do I expect MT is the only case.) It's not errata, so that is not an appropriate approach. (One might slip in= part of it as errata, though even that would not be appropriate in my view= .) Some of us who have implementations think this is worth the effort, or we w= ouldn't be doing this. Do you, or are you just second guessing those who do= ? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 27 August 2013 12:03 To: Dearlove, Christopher (UK) Cc: Henning Rogge; Christopher Dearlove; manet@ietf.org List; Joe Macker (j= oseph.macker@nrl.navy.mil); Thomas Heide Clausen (thomas@thomasclausen.org)= ; Stan Ratliff (sratliff) Subject: Re: [manet] IDs presemted in Berlin ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- My concerns are about struggle getting away from experimental status. If the intention is that the RFC have to implement something what was not w= ritten down that well, I think an errata would work. Then the new draft jus= t has to specify how to use it. If the new RFC breaks compatibility, I wonder if this is worth the effort. Teco Op 27 aug. 2013, om 11:40 heeft "Dearlove, Christopher (UK)" het volgende geschreven: > I thought I'd replied to this, but can't see on list. I think your charac= terisation of this whole issue is wrong. >=20 > Currently, there is no specification what to do when seeing an unknown va= lue. This defines one. Of course with no specification, people can do anyth= ing (including dropping the message). That's undesirable, let's fix it. >=20 > As for the sacrosanctness of the specification, let's be real. How many i= mplementations actually are there yet? Is there anyone with one who finds t= his other than a positive thing? >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: 17 August 2013 08:37 > To: Henning Rogge > Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org List= ; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen (thomas@tho= masclausen.org); Stan Ratliff (sratliff) > Subject: Re: [manet] IDs presemted in Berlin >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Can I read this as: >=20 > 1) an implementations that did not implement this new specification might= drop these new messages and therefore is not compatible > 2) an implementations that did not implement this new specification might= accept these new messages and therefore is compatible >=20 > "old" of "new" is not important. It is about stability of the standard. W= e have to stop incremental changes that are not backwards compatible. Or st= ep to new version or similar tag. >=20 > Teco >=20 > Op 16 aug. 2013, om 23:41 heeft Henning Rogge het= volgende geschreven: >=20 >> If I understand the draft right we have the following situations: >>=20 >> 1) an "old" implementation should interop with a "new" one without any >> extensions easily. >> 2) an "old" implementation might just drop messages from a "new" >> implementation which use an extension >>=20 >> Henning Rogge >>=20 >> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >>> Yes. >>>=20 >>> Teco >>>=20 >>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove het volgende geschreven: >>>=20 >>>> Have you read the draft? >>>>=20 >>>> -- >>>> Christopher Dearlove >>>> christopher.dearlove@gmail.com (iPhone) >>>> chris@mnemosyne.demon.co.uk (home) >>>>=20 >>>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>>>=20 >>>>> I understand the change is documented. >>>>> My concerns are on what happens when different implementations are in= same network. This has to be documented. Asking on mailing list is not eno= ugh. >>>>>=20 >>>>> Teco >>>>>=20 >>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove het volgende geschreven: >>>>>=20 >>>>>> I think you are quite wrong on the obsoleted point. Especially when = we are talking changes to define what was previously undefined. Nothing def= ined has changed. Which is just like the TOS change. >>>>>>=20 >>>>>> But if you want to know what's changed, read the draft. >>>>>>=20 >>>>>> I'd be interested in hearing from people with implementations. If th= e bottom line is that there isn't anyone with an implementation who has a p= roblem, I think worries over a hypothetical unwritten implementation are ra= ther beside the point. Anyone coming to something new could always check th= e "updated by" bit. >>>>>>=20 >>>>>>=20 >>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>>>>=20 >>>>>>> If anyone in the future writes code that complies with std track RF= C, he/she may assume that it is compatible with any other implementation. I= f an update of that RFC will break compatibility, that RFC shall be obsolet= ed, I think. >>>>>>>=20 >>>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are to= be used to guide", "may". Remapping to DSCP is highly backwards compatible= . >>>>>>>=20 >>>>>>> Did I say I'm against? I just want to know the issues / problems. A= t least they should be documented. >>>>>>>=20 >>>>>>> Teco >>>>>>>=20 >>>>>>>=20 >>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove het volgende geschreven: >>>>>>>=20 >>>>>>>> You can read this that there are minor issues, which I wouldn't el= evate to the level of problems. >>>>>>>>=20 >>>>>>>> Your comment on the inability to modify RFCs is just plain wrong. = Was RFC 791 obsoleted when the TOS bits function was changed? No. Many more= such examples could be given. >>>>>>>>=20 >>>>>>>> I'm actually not aware of anyone with an implementation who doesn'= t support this. Just in case not obvious, that includes me. >>>>>>>>=20 >>>>>>>> Does anyone with an implementation have an issue? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>> May I read that there are problems? >>>>>>>>> If so, we cannot bring out a std track RFC followed up with somet= hing that can not interoperate with it. Or we mark the to_be RFC as obsolet= e. That's how it works. >>>>>>>>>=20 >>>>>>>>> Teco >>>>>>>>>=20 >>>>>>>>> PS1. you mentioned something about IESG and correctness... >>>>>>>>> PS2: I understand the motivation. discussion could be how to deal= with it. >>>>>>>>>=20 >>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove het volgende geschreven: >>>>>>>>>=20 >>>>>>>>>> I think my starting point with such a discussion would be who ha= s an implementation? Yes, there are possible minor issues for implementatio= ns (though it's also possible for an implementation to need no changes at a= ll). But the most pointless thing would be protecting (in a minor way) hypo= thetical implementations while people actually with them want this. >>>>>>>>>>=20 >>>>>>>>>> (I'm not saying those with them have all said they want this. I'= m asking.) >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Christopher Dearlove >>>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>>>=20 >>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>>>>>>=20 >>>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce p= roblems in a network with and without routers that implement this? >>>>>>>>>>> If so, I think we need some discussion first. >>>>>>>>>>>=20 >>>>>>>>>>> Teco >>>>>>>>>>>=20 >>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) het volgende geschreven: >>>>>>>>>>>=20 >>>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these documen= ts as working group docs? >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Stan >>>>>>>>>>>>=20 >>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> I don't believe that the chairs have raised the WG adoption o= f the IDs I presented at Berlin. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization a= nd draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standard= s Track, and as minor updates to NHDP and OLSRv2, which we would like to pr= ogress as fast as possible. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd ob= vious have no problem with being adopted as a WG document, but it needs at = least one more revision, which we intend to do as an author draft, so there= isn't the same time pressure there. However of course we would like discus= sion any time from now. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aero= space Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *************************************************************= ******* >>>>>>>>>>>>> This email and any attachments are confidential to the intend= ed >>>>>>>>>>>>> recipient and may also be privileged. If you are not the inte= nded >>>>>>>>>>>>> recipient please delete it from your system and notify the se= nder. >>>>>>>>>>>>> You should not copy it or use it for any purpose nor disclose= or >>>>>>>>>>>>> distribute its contents to any other person. >>>>>>>>>>>>> *************************************************************= ******* >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> manet mailing list >>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> manet mailing list >>>>>>>>>>> manet@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> --=20 >> We began as wanderers, and we are wanderers still. We have lingered >> long enough on the shores of the cosmic ocean. We are ready at last to >> set sail for the stars - Carl Sagan >=20 >=20 From teco@inf-net.nl Tue Aug 27 08:08:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F4311E8313 for ; Tue, 27 Aug 2013 08:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE7WQL95U4uQ for ; Tue, 27 Aug 2013 08:08:43 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD21511E819D for ; Tue, 27 Aug 2013 08:08:42 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id b47so2351286eek.3 for ; Tue, 27 Aug 2013 08:08:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QryrCy9dVYUO3YhkyWs3pKJ3MEtyTA8N6Q7Dd52hJII=; b=PCHyX2ax2iCk8QC/KdJXpXO1hvQRQJDMA6XAmQQKuVIVBHilteba7duCa8NpCNu54D OJ1stU+lpIAguT4TDvfIs4LZp7yawvldRpo+8USaqdSascOV/93HX7AHhnFz5sbYCZ+H +PTNloc7a0NXV2DqnOwg0VTpo3OogFoJsS9cKlCM+4tbtALWqa0cTF0HWUAsGBbOz6ZE I4M49S0iv4DvJBzULqD8hy8wlWVSnEb6Z+9+tWUogtQQ5NGjiVhh1N1Sm6Sr9gTBhTGo yGGdjpPq0kpyvKWR8rt7FPuAkHp3I8vHPrxWdkzD1FvHPZ4cLuj1K41t2CL1d/fqnqWx QH5Q== X-Gm-Message-State: ALoCoQm8576Ja9AnOERR485rTKWgetAxqMhZLbuaZQNlHvn5vZd265HMICA7GY6SbfsTSHXkyuo0 X-Received: by 10.14.176.8 with SMTP id a8mr35566243eem.12.1377616121571; Tue, 27 Aug 2013 08:08:41 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id r48sm29906863eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 08:08:40 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Tue, 27 Aug 2013 17:08:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <95BCADF8-7B0C-449D-A689-B2A13F777C36@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1508) Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , Christopher Dearlove , "manet@ietf.org List" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 15:08:48 -0000 I'm mainly on the user side of the table. I want to be sure stuff that = is compliant with an RFC is compatible with whatever other = implementation. That's why we have RFCs, isn't it? Teco Op 27 aug. 2013, om 14:16 heeft "Dearlove, Christopher (UK)" = het volgende geschreven: > The point of the new draft is to enable extensions more cleanly, and = that's used in the multitopology draft, it's not just change for = change's sake. (But neither do I expect MT is the only case.) >=20 > It's not errata, so that is not an appropriate approach. (One might = slip in part of it as errata, though even that would not be appropriate = in my view.) >=20 > Some of us who have implementations think this is worth the effort, or = we wouldn't be doing this. Do you, or are you just second guessing those = who do? >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: 27 August 2013 12:03 > To: Dearlove, Christopher (UK) > Cc: Henning Rogge; Christopher Dearlove; manet@ietf.org List; Joe = Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen = (thomas@thomasclausen.org); Stan Ratliff (sratliff) > Subject: Re: [manet] IDs presemted in Berlin >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > My concerns are about struggle getting away from experimental status. >=20 > If the intention is that the RFC have to implement something what was = not written down that well, I think an errata would work. Then the new = draft just has to specify how to use it. >=20 > If the new RFC breaks compatibility, I wonder if this is worth the = effort. >=20 > Teco >=20 > Op 27 aug. 2013, om 11:40 heeft "Dearlove, Christopher (UK)" = het volgende geschreven: >=20 >> I thought I'd replied to this, but can't see on list. I think your = characterisation of this whole issue is wrong. >>=20 >> Currently, there is no specification what to do when seeing an = unknown value. This defines one. Of course with no specification, people = can do anything (including dropping the message). That's undesirable, = let's fix it. >>=20 >> As for the sacrosanctness of the specification, let's be real. How = many implementations actually are there yet? Is there anyone with one = who finds this other than a positive thing? >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: Teco Boot [mailto:teco@inf-net.nl]=20 >> Sent: 17 August 2013 08:37 >> To: Henning Rogge >> Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org = List; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen = (thomas@thomasclausen.org); Stan Ratliff (sratliff) >> Subject: Re: [manet] IDs presemted in Berlin >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Can I read this as: >>=20 >> 1) an implementations that did not implement this new specification = might drop these new messages and therefore is not compatible >> 2) an implementations that did not implement this new specification = might accept these new messages and therefore is compatible >>=20 >> "old" of "new" is not important. It is about stability of the = standard. We have to stop incremental changes that are not backwards = compatible. Or step to new version or similar tag. >>=20 >> Teco >>=20 >> Op 16 aug. 2013, om 23:41 heeft Henning Rogge = het volgende geschreven: >>=20 >>> If I understand the draft right we have the following situations: >>>=20 >>> 1) an "old" implementation should interop with a "new" one without = any >>> extensions easily. >>> 2) an "old" implementation might just drop messages from a "new" >>> implementation which use an extension >>>=20 >>> Henning Rogge >>>=20 >>> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >>>> Yes. >>>>=20 >>>> Teco >>>>=20 >>>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove = het volgende geschreven: >>>>=20 >>>>> Have you read the draft? >>>>>=20 >>>>> -- >>>>> Christopher Dearlove >>>>> christopher.dearlove@gmail.com (iPhone) >>>>> chris@mnemosyne.demon.co.uk (home) >>>>>=20 >>>>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>>>>=20 >>>>>> I understand the change is documented. >>>>>> My concerns are on what happens when different implementations = are in same network. This has to be documented. Asking on mailing list = is not enough. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove = het volgende geschreven: >>>>>>=20 >>>>>>> I think you are quite wrong on the obsoleted point. Especially = when we are talking changes to define what was previously undefined. = Nothing defined has changed. Which is just like the TOS change. >>>>>>>=20 >>>>>>> But if you want to know what's changed, read the draft. >>>>>>>=20 >>>>>>> I'd be interested in hearing from people with implementations. = If the bottom line is that there isn't anyone with an implementation who = has a problem, I think worries over a hypothetical unwritten = implementation are rather beside the point. Anyone coming to something = new could always check the "updated by" bit. >>>>>>>=20 >>>>>>>=20 >>>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>>>>>=20 >>>>>>>> If anyone in the future writes code that complies with std = track RFC, he/she may assume that it is compatible with any other = implementation. If an update of that RFC will break compatibility, that = RFC shall be obsoleted, I think. >>>>>>>>=20 >>>>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", = "are to be used to guide", "may". Remapping to DSCP is highly backwards = compatible. >>>>>>>>=20 >>>>>>>> Did I say I'm against? I just want to know the issues / = problems. At least they should be documented. >>>>>>>>=20 >>>>>>>> Teco >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove = het volgende geschreven: >>>>>>>>=20 >>>>>>>>> You can read this that there are minor issues, which I = wouldn't elevate to the level of problems. >>>>>>>>>=20 >>>>>>>>> Your comment on the inability to modify RFCs is just plain = wrong. Was RFC 791 obsoleted when the TOS bits function was changed? No. = Many more such examples could be given. >>>>>>>>>=20 >>>>>>>>> I'm actually not aware of anyone with an implementation who = doesn't support this. Just in case not obvious, that includes me. >>>>>>>>>=20 >>>>>>>>> Does anyone with an implementation have an issue? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>>>>>=20 >>>>>>>>>> May I read that there are problems? >>>>>>>>>> If so, we cannot bring out a std track RFC followed up with = something that can not interoperate with it. Or we mark the to_be RFC as = obsolete. That's how it works. >>>>>>>>>>=20 >>>>>>>>>> Teco >>>>>>>>>>=20 >>>>>>>>>> PS1. you mentioned something about IESG and correctness... >>>>>>>>>> PS2: I understand the motivation. discussion could be how to = deal with it. >>>>>>>>>>=20 >>>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: >>>>>>>>>>=20 >>>>>>>>>>> I think my starting point with such a discussion would be = who has an implementation? Yes, there are possible minor issues for = implementations (though it's also possible for an implementation to need = no changes at all). But the most pointless thing would be protecting (in = a minor way) hypothetical implementations while people actually with = them want this. >>>>>>>>>>>=20 >>>>>>>>>>> (I'm not saying those with them have all said they want = this. I'm asking.) >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Christopher Dearlove >>>>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>>>>=20 >>>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension = introduce problems in a network with and without routers that implement = this? >>>>>>>>>>>> If so, I think we need some discussion first. >>>>>>>>>>>>=20 >>>>>>>>>>>> Teco >>>>>>>>>>>>=20 >>>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: >>>>>>>>>>>>=20 >>>>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these = documents as working group docs? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Stan >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I don't believe that the chairs have raised the WG = adoption of the IDs I presented at Berlin. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Two of these, = draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, = we'd obvious have no problem with being adopted as a WG document, but it = needs at least one more revision, which we intend to do as an author = draft, so there isn't the same time pressure there. However of course we = would like discussion any time from now. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 = 8HN, UK >>>>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> = ******************************************************************** >>>>>>>>>>>>>> This email and any attachments are confidential to the = intended >>>>>>>>>>>>>> recipient and may also be privileged. If you are not the = intended >>>>>>>>>>>>>> recipient please delete it from your system and notify = the sender. >>>>>>>>>>>>>> You should not copy it or use it for any purpose nor = disclose or >>>>>>>>>>>>>> distribute its contents to any other person. >>>>>>>>>>>>>> = ******************************************************************** >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> manet mailing list >>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>> --=20 >>> We began as wanderers, and we are wanderers still. We have lingered >>> long enough on the shores of the cosmic ocean. We are ready at last = to >>> set sail for the stars - Carl Sagan >>=20 >>=20 >=20 >=20 From ulrich@herberg.name Tue Aug 27 19:05:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5375921F9E36 for ; Tue, 27 Aug 2013 19:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS4SBYJdMPOA for ; Tue, 27 Aug 2013 19:05:52 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2C221F9E28 for ; Tue, 27 Aug 2013 19:05:51 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so3532383vbh.26 for ; Tue, 27 Aug 2013 19:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qZvNeFPnaOS1aSb5LWlSE6GYWmS1DKLEdbFq04COxXI=; b=LNIhhApteE+5Hmc/U2uPUrraUHYI8fjzXDeLDppXW3c2moA6r8S5SPl+USGM8wfQl8 pHHEaClac/yn2HHYLg1A8i5nk5wv6tINL0rpaenAkpiaJRFxbxhadJSfFReVPGpA9JfL Fd5qQ2vrc+oZR6oaF0fxcgDPSOnzAc22csiBg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qZvNeFPnaOS1aSb5LWlSE6GYWmS1DKLEdbFq04COxXI=; b=GYaaUScS+4fojI3JsqDGgeLgv2ED86stz5+JUdcC12MO1aGj42XtH1eIXQdX3JSXXo Q/vMfCP81tOFpJ9O0irHHmo0UlIddMIXBq2adYGR+0WKMkolF85JVWRwYpXPBQgeW3xS 7AHYPaaUOFxZPQCQ+bZFKCh3KUzcepmvRS/NO7q+ty15Ru1FchlLeiqrF3AAiGtOc+Xp QjvMnoy1+vEnweYE+omMl+UfeyHZ2eJkd86sSKiOfx44KYVAv0qE73d4DMiVHyrg3YAD ngFbQwglu3oIgZcjowHbJ+LlxMIv04zB89aZAaG3jzZjdhx4IxyZ1/RJ9UAZmNC/7ASa fjMw== X-Gm-Message-State: ALoCoQlpEqbL+RBLtr9fsz/QHqja3RjBuUUR7WA0f+CAXvbDS9BWcT/aFIezHdXVNXqFfNPhGd6z MIME-Version: 1.0 X-Received: by 10.220.91.16 with SMTP id k16mr10309024vcm.21.1377655549867; Tue, 27 Aug 2013 19:05:49 -0700 (PDT) Received: by 10.220.168.8 with HTTP; Tue, 27 Aug 2013 19:05:49 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> Date: Tue, 27 Aug 2013 19:05:49 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=047d7b343f1aac494a04e4f86d86 Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , Christopher Dearlove , "manet@ietf.org List" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 02:05:54 -0000 --047d7b343f1aac494a04e4f86d86 Content-Type: text/plain; charset=ISO-8859-1 I don't see any issues with the approach of the TLV extension draft. Like Chris said, it specifies a behavior that was previously unspecified (and thus undefined). On the procedural question, the IETF has introduced "updates RFCxxxx" for a good reason, and I think this particular case is such a case. Ulrich On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > I thought I'd replied to this, but can't see on list. I think your > characterisation of this whole issue is wrong. > > Currently, there is no specification what to do when seeing an unknown > value. This defines one. Of course with no specification, people can do > anything (including dropping the message). That's undesirable, let's fix it. > > As for the sacrosanctness of the specification, let's be real. How many > implementations actually are there yet? Is there anyone with one who finds > this other than a positive thing? > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 17 August 2013 08:37 > To: Henning Rogge > Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.orgList; Joe Macker ( > joseph.macker@nrl.navy.mil); Thomas Heide Clausen ( > thomas@thomasclausen.org); Stan Ratliff (sratliff) > Subject: Re: [manet] IDs presemted in Berlin > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Can I read this as: > > 1) an implementations that did not implement this new specification might > drop these new messages and therefore is not compatible > 2) an implementations that did not implement this new specification might > accept these new messages and therefore is compatible > > "old" of "new" is not important. It is about stability of the standard. We > have to stop incremental changes that are not backwards compatible. Or step > to new version or similar tag. > > Teco > > Op 16 aug. 2013, om 23:41 heeft Henning Rogge het > volgende geschreven: > > > If I understand the draft right we have the following situations: > > > > 1) an "old" implementation should interop with a "new" one without any > > extensions easily. > > 2) an "old" implementation might just drop messages from a "new" > > implementation which use an extension > > > > Henning Rogge > > > > On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: > >> Yes. > >> > >> Teco > >> > >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove < > christopher.dearlove@gmail.com> het volgende geschreven: > >> > >>> Have you read the draft? > >>> > >>> -- > >>> Christopher Dearlove > >>> christopher.dearlove@gmail.com (iPhone) > >>> chris@mnemosyne.demon.co.uk (home) > >>> > >>> On 16 Aug 2013, at 21:58, Teco Boot wrote: > >>> > >>>> I understand the change is documented. > >>>> My concerns are on what happens when different implementations are in > same network. This has to be documented. Asking on mailing list is not > enough. > >>>> > >>>> Teco > >>>> > >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove < > christopher.dearlove@gmail.com> het volgende geschreven: > >>>> > >>>>> I think you are quite wrong on the obsoleted point. Especially when > we are talking changes to define what was previously undefined. Nothing > defined has changed. Which is just like the TOS change. > >>>>> > >>>>> But if you want to know what's changed, read the draft. > >>>>> > >>>>> I'd be interested in hearing from people with implementations. If > the bottom line is that there isn't anyone with an implementation who has a > problem, I think worries over a hypothetical unwritten implementation are > rather beside the point. Anyone coming to something new could always check > the "updated by" bit. > >>>>> > >>>>> > >>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: > >>>>> > >>>>>> If anyone in the future writes code that complies with std track > RFC, he/she may assume that it is compatible with any other implementation. > If an update of that RFC will break compatibility, that RFC shall be > obsoleted, I think. > >>>>>> > >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are to > be used to guide", "may". Remapping to DSCP is highly backwards compatible. > >>>>>> > >>>>>> Did I say I'm against? I just want to know the issues / problems. > At least they should be documented. > >>>>>> > >>>>>> Teco > >>>>>> > >>>>>> > >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove < > christopher.dearlove@gmail.com> het volgende geschreven: > >>>>>> > >>>>>>> You can read this that there are minor issues, which I wouldn't > elevate to the level of problems. > >>>>>>> > >>>>>>> Your comment on the inability to modify RFCs is just plain wrong. > Was RFC 791 obsoleted when the TOS bits function was changed? No. Many more > such examples could be given. > >>>>>>> > >>>>>>> I'm actually not aware of anyone with an implementation who > doesn't support this. Just in case not obvious, that includes me. > >>>>>>> > >>>>>>> Does anyone with an implementation have an issue? > >>>>>>> > >>>>>>> > >>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: > >>>>>>> > >>>>>>>> May I read that there are problems? > >>>>>>>> If so, we cannot bring out a std track RFC followed up with > something that can not interoperate with it. Or we mark the to_be RFC as > obsolete. That's how it works. > >>>>>>>> > >>>>>>>> Teco > >>>>>>>> > >>>>>>>> PS1. you mentioned something about IESG and correctness... > >>>>>>>> PS2: I understand the motivation. discussion could be how to deal > with it. > >>>>>>>> > >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove < > christopher.dearlove@gmail.com> het volgende geschreven: > >>>>>>>> > >>>>>>>>> I think my starting point with such a discussion would be who > has an implementation? Yes, there are possible minor issues for > implementations (though it's also possible for an implementation to need no > changes at all). But the most pointless thing would be protecting (in a > minor way) hypothetical implementations while people actually with them > want this. > >>>>>>>>> > >>>>>>>>> (I'm not saying those with them have all said they want this. > I'm asking.) > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Christopher Dearlove > >>>>>>>>> christopher.dearlove@gmail.com (iPhone) > >>>>>>>>> chris@mnemosyne.demon.co.uk (home) > >>>>>>>>> > >>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: > >>>>>>>>> > >>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce > problems in a network with and without routers that implement this? > >>>>>>>>>> If so, I think we need some discussion first. > >>>>>>>>>> > >>>>>>>>>> Teco > >>>>>>>>>> > >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) < > sratliff@cisco.com> het volgende geschreven: > >>>>>>>>>> > >>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these > documents as working group docs? > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Stan > >>>>>>>>>>> > >>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" < > chris.dearlove@baesystems.com> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> I don't believe that the chairs have raised the WG adoption > of the IDs I presented at Berlin. > >>>>>>>>>>>> > >>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization > and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for > Standards Track, and as minor updates to NHDP and OLSRv2, which we would > like to progress as fast as possible. > >>>>>>>>>>>> > >>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd > obvious have no problem with being adopted as a WG document, but it needs > at least one more revision, which we intend to do as an author draft, so > there isn't the same time pressure there. However of course we would like > discussion any time from now. > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Christopher Dearlove > >>>>>>>>>>>> Senior Principal Engineer, Communications Group > >>>>>>>>>>>> Communications, Networks and Image Analysis Capability > >>>>>>>>>>>> BAE Systems Advanced Technology Centre > >>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com > >>>>>>>>>>>> > >>>>>>>>>>>> BAE Systems (Operations) Limited > >>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough > Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > >>>>>>>>>>>> Registered in England & Wales No: 1996687 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > ******************************************************************** > >>>>>>>>>>>> This email and any attachments are confidential to the > intended > >>>>>>>>>>>> recipient and may also be privileged. If you are not the > intended > >>>>>>>>>>>> recipient please delete it from your system and notify the > sender. > >>>>>>>>>>>> You should not copy it or use it for any purpose nor disclose > or > >>>>>>>>>>>> distribute its contents to any other person. > >>>>>>>>>>>> > ******************************************************************** > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> manet mailing list > >>>>>>>>>>> manet@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> manet mailing list > >>>>>>>>>> manet@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > > > > > -- > > We began as wanderers, and we are wanderers still. We have lingered > > long enough on the shores of the cosmic ocean. We are ready at last to > > set sail for the stars - Carl Sagan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b343f1aac494a04e4f86d86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't see any issues with the approach of the T= LV extension draft. Like Chris said, it specifies a behavior that was previ= ously unspecified (and thus undefined).
On the procedural que= stion, the IETF has introduced "updates RFCxxxx" for a good reaso= n, and I think this particular case is such a case.

Ulrich


On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:
I thought I'd replied to this, but can&#= 39;t see on list. I think your characterisation of this whole issue is wron= g.

Currently, there is no specification what to do when seeing an unknown valu= e. This defines one. Of course with no specification, people can do anythin= g (including dropping the message). That's undesirable, let's fix i= t.

As for the sacrosanctness of the specification, let's be real. How many= implementations actually are there yet? Is there anyone with one who finds= this other than a positive thing?

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://ww= w.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Teco Boot [mailto:teco@inf-net.nl<= /a>]
Sent: 17 August 2013 08:37
To: Henning Rogge
Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org List; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen = (thomas@thomasclausen.org);= Stan Ratliff (sratliff)
Subject: Re: [manet] IDs presemted in Berlin

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Can I read this as:

1) an implementations that did not implement this new specification might d= rop these new messages and therefore is not compatible
2) an implementations that did not implement this new specification might a= ccept these new messages and therefore is compatible

"old" of "new" is not important. It is about stability = of the standard. We have to stop incremental changes that are not backwards= compatible. Or step to new version or similar tag.

Teco

Op 16 aug. 2013, om 23:41 heeft Henning Rogge <hrogge@googlemail.com> het volgende geschreven:

> If I understand the draft right we have the following situations:
>
> 1) an "old" implementation should interop with a "new&q= uot; one without any
> extensions easily.
> 2) an "old" implementation might just drop messages from a &= quot;new"
> implementation which use an extension
>
> Henning Rogge
>
> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot <teco@inf-net.nl> wrote:
>> Yes.
>>
>> Teco
>>
>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove <christopher.dearlove@gmail.com> het volgende geschreven:
>>
>>> Have you read the draft?
>>>
>>> --
>>> Christopher Dearlove
>>> christopher.= dearlove@gmail.com (iPhone)
>>> chris@mnemosyne= .demon.co.uk (home)
>>>
>>> On 16 Aug 2013, at 21:58, Teco Boot <teco@inf-net.nl> wrote:
>>>
>>>> I understand the change is documented.
>>>> My concerns are on what happens when different implementat= ions are in same network. This has to be documented. Asking on mailing list= is not enough.
>>>>
>>>> Teco
>>>>
>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove <<= a href=3D"mailto:christopher.dearlove@gmail.com">christopher.dearlove@gmail= .com> het volgende geschreven:
>>>>
>>>>> I think you are quite wrong on the obsoleted point. Es= pecially when we are talking changes to define what was previously undefine= d. Nothing defined has changed. Which is just like the TOS change.
>>>>>
>>>>> But if you want to know what's changed, read the d= raft.
>>>>>
>>>>> I'd be interested in hearing from people with impl= ementations. If the bottom line is that there isn't anyone with an impl= ementation who has a problem, I think worries over a hypothetical unwritten= implementation are rather beside the point. Anyone coming to something new= could always check the "updated by" bit.
>>>>>
>>>>>
>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote:
>>>>>
>>>>>> If anyone in the future writes code that complies = with std track RFC, he/she may assume that it is compatible with any other = implementation. If an update of that RFC will break compatibility, that RFC= shall be obsoleted, I think.
>>>>>>
>>>>>> RFC 791 was 1981. Wording on TOS: "provides a= n indication", "are to be used to guide", "may". R= emapping to DSCP is highly backwards compatible.
>>>>>>
>>>>>> Did I say I'm against? I just want to know the= issues / problems. At least they should be documented.
>>>>>>
>>>>>> Teco
>>>>>>
>>>>>>
>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlo= ve <christopher.dearlo= ve@gmail.com> het volgende geschreven:
>>>>>>
>>>>>>> You can read this that there are minor issues,= which I wouldn't elevate to the level of problems.
>>>>>>>
>>>>>>> Your comment on the inability to modify RFCs i= s just plain wrong. Was RFC 791 obsoleted when the TOS bits function was ch= anged? No. Many more such examples could be given.
>>>>>>>
>>>>>>> I'm actually not aware of anyone with an i= mplementation who doesn't support this. Just in case not obvious, that = includes me.
>>>>>>>
>>>>>>> Does anyone with an implementation have an iss= ue?
>>>>>>>
>>>>>>>
>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote:
>>>>>>>
>>>>>>>> May I read that there are problems?
>>>>>>>> If so, we cannot bring out a std track RFC= followed up with something that can not interoperate with it. Or we mark t= he to_be RFC as obsolete. That's how it works.
>>>>>>>>
>>>>>>>> Teco
>>>>>>>>
>>>>>>>> PS1. you mentioned something about IESG an= d correctness...
>>>>>>>> PS2: I understand the motivation. discussi= on could be how to deal with it.
>>>>>>>>
>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christophe= r Dearlove <christophe= r.dearlove@gmail.com> het volgende geschreven:
>>>>>>>>
>>>>>>>>> I think my starting point with such a = discussion would be who has an implementation? Yes, there are possible mino= r issues for implementations (though it's also possible for an implemen= tation to need no changes at all). But the most pointless thing would be pr= otecting (in a minor way) hypothetical implementations while people actuall= y with them want this.
>>>>>>>>>
>>>>>>>>> (I'm not saying those with them ha= ve all said they want this. I'm asking.)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Christopher Dearlove
>>>>>>>>> christopher.dearlove@gmail.com (iPhone)
>>>>>>>>> chris@mnemosyne.demon.co.uk (home)
>>>>>>>>>
>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot &l= t;teco@inf-net.nl> wrote:
>>>>>>>>>
>>>>>>>>>> Does draft-dearlove-manet-nhdp-ols= rv2-tlv-extension introduce problems in a network with and without routers = that implement this?
>>>>>>>>>> If so, I think we need some discus= sion first.
>>>>>>>>>>
>>>>>>>>>> Teco
>>>>>>>>>>
>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft St= an Ratliff (sratliff) <sratliff@ci= sco.com> het volgende geschreven:
>>>>>>>>>>
>>>>>>>>>>> OK, so to the WG - do we have = consensus to adopt these documents as working group docs?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Stan
>>>>>>>>>>>
>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, &= quot;Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I don't believe that t= he chairs have raised the WG adoption of the IDs I presented at Berlin.
>>>>>>>>>>>>
>>>>>>>>>>>> Two of these, draft-dearlo= ve-manet-olsrv2-rmpr-optimization and draft-dearlove-manet-nhdp-olsrv2-tlv-= extension are intended for Standards Track, and as minor updates to NHDP an= d OLSRv2, which we would like to progress as fast as possible.
>>>>>>>>>>>>
>>>>>>>>>>>> The third, draft-dearlove-= manet-olsrv2-multitopology, we'd obvious have no problem with being ado= pted as a WG document, but it needs at least one more revision, which we in= tend to do as an author draft, so there isn't the same time pressure th= ere. However of course we would like discussion any time from now.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Christopher Dearlove
>>>>>>>>>>>> Senior Principal Engineer,= Communications Group
>>>>>>>>>>>> Communications, Networks a= nd Image Analysis Capability
>>>>>>>>>>>> BAE Systems Advanced Techn= ology Centre
>>>>>>>>>>>> West Hanningfield Road, Gr= eat Baddow, Chelmsford, CM2 8HN, UK
>>>>>>>>>>>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
>>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com
>>>>>>>>>>>>
>>>>>>>>>>>> BAE Systems (Operations) L= imited
>>>>>>>>>>>> Registered Office: Warwick= House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6= YU, UK
>>>>>>>>>>>> Registered in England &= ; Wales No: 1996687
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> **************************= ******************************************
>>>>>>>>>>>> This email and any attachm= ents are confidential to the intended
>>>>>>>>>>>> recipient and may also be = privileged. If you are not the intended
>>>>>>>>>>>> recipient please delete it= from your system and notify the sender.
>>>>>>>>>>>> You should not copy it or = use it for any purpose nor disclose or
>>>>>>>>>>>> distribute its contents to= any other person.
>>>>>>>>>>>> **************************= ******************************************
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> manet mailing list
>>>>>>>>>>> manet@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/li= stinfo/manet
>>>>>>>>>>
>>>>>>>>>> __________________________________= _____________
>>>>>>>>>> manet mailing list
>>>>>>>>>> = manet@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listin= fo/manet
>>>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> --
> We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to=
> set sail for the stars - Carl Sagan


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b343f1aac494a04e4f86d86-- From sratliff@cisco.com Thu Aug 29 07:54:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E230B21E80A3 for ; Thu, 29 Aug 2013 07:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.145 X-Spam-Level: X-Spam-Status: No, score=-10.145 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGkrckLu2AX5 for ; Thu, 29 Aug 2013 07:53:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0FD21E8099 for ; Thu, 29 Aug 2013 07:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3999; q=dns/txt; s=iport; t=1377788032; x=1378997632; h=from:to:subject:date:message-id:references:mime-version; bh=QLw5c1XptHSk0SXgn8oHP+IJJF5QlpscS2xxVwUmJHM=; b=kDJZUT4FFGaFeLOgbr4AhsP9Lbacd2BibV+BwZ7LDdlpF/0bcvtYFzbD 9Xw63WxvpIpdUYM/Bt7kymf+lON8onF0r23CbltNR/EG27gQgUa2iGUtM +uFwb50Vu2dRPXwALz1aWZBcA99Xe5vobHWw0JSgWvy6NrsdlVeNSa+ww k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAN9fH1KtJV2b/2dsb2JhbABagweBBsA3gScWdIIkAQEBBIEJAgEMDQMBAgsdBzIUBwIIAgQTCId5uT6OO4EIIBcHgxaBAAOpWYMggXE5 X-IronPort-AV: E=Sophos;i="4.89,984,1367971200"; d="scan'208,217";a="253163465" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 29 Aug 2013 14:53:52 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7TErqBT018229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 29 Aug 2013 14:53:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.187]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 09:53:51 -0500 From: "Stan Ratliff (sratliff)" To: "manet@ietf.org List" Thread-Topic: Mail lost yesterday Thread-Index: AQIiuf/NPVJ0u+Yu4la7frHQKSZfMg== Date: Thu, 29 Aug 2013 14:53:17 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1149C561@xmb-aln-x03.cisco.com> References: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1149C561xmbalnx03ciscoc_" MIME-Version: 1.0 Subject: [manet] Fwd: Mail lost yesterday X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 14:54:00 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1149C561xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group - FYI. Regards, Stan Begin forwarded message: Resent-From: > From: Adrian Farrel > Subject: FW: Mail lost yesterday Date: August 29, 2013 10:46:09 AM EDT To: > Reply-To: > For those of you who haven't noticed the message from Steve Young in your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific Time yesterday seems to have been lost. Aside from needing to re-send all mail you personally sent during that time period, you also need to inform your working groups. --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1149C561xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <07E23543FB8A59468B4ED73A4950FFA2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Working Group - 
FYI.

Regards,
Stan


Begin forwarded message:

Resent-From: <<= a href=3D"mailto:wg-alias-bounces@tools.ietf.org">wg-alias-bounces@tools.ie= tf.org>
From: Adria= n Farrel <adrian@olddog.co.uk= >
Subject: FW= : Mail lost yesterday
Date: Augus= t 29, 2013 10:46:09 AM EDT

For those of you who haven't noticed the message from Steve Young in your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific
Time yesterday seems to have been lost. Aside from needing to re-send
all mail you personally sent during that time period, you also need to
inform your working groups.


--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1149C561xmbalnx03ciscoc_-- From chris.dearlove@baesystems.com Thu Aug 29 08:22:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C8521F9E63 for ; Thu, 29 Aug 2013 08:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.423 X-Spam-Level: X-Spam-Status: No, score=-9.423 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySoRbjPMrRuk for ; Thu, 29 Aug 2013 08:22:50 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 39FE621F90FD for ; Thu, 29 Aug 2013 08:22:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,984,1367967600"; d="scan'208,217";a="368480840" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 29 Aug 2013 16:22:48 +0100 X-IronPort-AV: E=Sophos;i="4.89,984,1367967600"; d="scan'208,217";a="25717185" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 29 Aug 2013 16:22:48 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.167]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 16:22:47 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "manet@ietf.org List" Thread-Topic: Mail lost yesterday Thread-Index: AQIiuf/NPVJ0u+Yu4la7frHQKSZfMpkEIuyA Date: Thu, 29 Aug 2013 15:22:48 +0000 Message-ID: References: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C1149C561@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C1149C561@xmb-aln-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DBD0B0DGLKXM0002VGREEN_" MIME-Version: 1.0 Subject: Re: [manet] Mail lost yesterday X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:22:54 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DBD0B0DGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Fortunately, most of us in Europe were asleep. Or at least not working. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff (sratliff) Sent: 29 August 2013 15:53 To: manet@ietf.org List Subject: [manet] Fwd: Mail lost yesterday *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Working Group - FYI. Regards, Stan Begin forwarded message: Resent-From: > From: Adrian Farrel > Subject: FW: Mail lost yesterday Date: August 29, 2013 10:46:09 AM EDT To: > Reply-To: > For those of you who haven't noticed the message from Steve Young in your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific Time yesterday seems to have been lost. Aside from needing to re-send all mail you personally sent during that time period, you also need to inform your working groups. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DBD0B0DGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Fortunately, most of us i= n Europe were asleep. Or at least not working.

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff (sratliff)
Sent: 29 August 2013 15:53
To: manet@ietf.org List
Subject: [manet] Fwd: Mail lost yesterday

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Fo= r information regarding Red Flags that you can look out for in emails you r= eceive, click here.
If= you feel the email is suspicious, please follow this process.

Working Group - 

FYI.

 

Regards,

Stan

 

 

Begin forwarded message:



From: Adrian Farrel <adrian@olddog.co.uk>

Subject: FW: Mail lost yesterday

Date: August 29, 2013 10:46:09 AM EDT=

Reply-To: <adrian= @olddog.co.uk>

 

For those of you who = haven't noticed the message from Steve Young in
your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific
Time yesterday seems to have been lost. Aside from needing to re-send
all mail you personally sent during that time period, you also need to
inform your working groups.

 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DBD0B0DGLKXM0002VGREEN_-- From sratliff@cisco.com Thu Aug 29 09:19:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92EE21F9406 for ; Thu, 29 Aug 2013 09:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMWNrricyNhr for ; Thu, 29 Aug 2013 09:19:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 215C011E8123 for ; Thu, 29 Aug 2013 09:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16582; q=dns/txt; s=iport; t=1377793168; x=1379002768; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=x27/8wQ/hqC2DorZSOAo2pxL5nfkj1I/N4UxFpQejj4=; b=Z/CCNVmY4bzNDlHftZmKcOMbq4nYIjmmmI4+u1UZP+p3UKm2Ash1+5e+ qFz2paUW3M49Oe42Ndu+i15iLf3iSbybYVgirOODPuBYd6g7nS2Dj/VHj HFnGp77Bx0FoB4+pp9Z5tc9zCsRpt9ou0vX/8KG9txlpaEcZZZV/k9lMR w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusFAFdzH1KtJV2Z/2dsb2JhbABagkNENQNOt2yITIEnFnSCJAEBAQICAQEBUhkDCBACAQgHCgMBAQELHQcnCxQJCAIEDgUIh3kMp0ORU44rCgYIgQAgDAEEBgEGA4MTgQADmSKQN4MggWgCBxci X-IronPort-AV: E=Sophos;i="4.89,984,1367971200"; d="scan'208,217";a="253315001" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 29 Aug 2013 16:19:26 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7TGJQRS014404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Aug 2013 16:19:26 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.187]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 11:19:26 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Mail lost yesterday Thread-Index: AQIiuf/NPVJ0u+Yu4la7frHQKSZfMpkEIuyAgABj8gA= Date: Thu, 29 Aug 2013 16:18:51 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1149D860@xmb-aln-x03.cisco.com> References: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C1149C561@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1149D860xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] Mail lost yesterday X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:19:38 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1149D860xmbalnx03ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =85 or at least, not emailing the IETF? ;-) Regards, Stan On Aug 29, 2013, at 11:22 AM, "Dearlove, Christopher (UK)" > wrote: Fortunately, most of us in Europe were asleep. Or at least not working. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Stan Ratliff (sratli= ff) Sent: 29 August 2013 15:53 To: manet@ietf.org List Subject: [manet] Fwd: Mail lost yesterday *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Working Group - FYI. Regards, Stan Begin forwarded message: Resent-From: > From: Adrian Farrel > Subject: FW: Mail lost yesterday Date: August 29, 2013 10:46:09 AM EDT To: > Reply-To: > For those of you who haven't noticed the message from Steve Young in your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific Time yesterday seems to have been lost. Aside from needing to re-send all mail you personally sent during that time period, you also need to inform your working groups. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1149D860xmbalnx03ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable =85 or at least, not emailing the IETF? ;-) 

Regards,
Stan

On Aug 29, 2013, at 11:22 AM, "Dearlove, Christopher (UK)" &= lt;chris.dearlove@baesyste= ms.com> wrote:

Fortunately, most of us in Europe were asleep. Or at leas= t not working.
 
--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
 
From:&nbs= p;manet-bounces@ietf.org [mailto:manet-bounces@ietf.o= rg] On Behalf Of Stan Ratli= ff (sratliff)
Sent: 29 August 20= 13 15:53
To: m= anet@ietf.org List Subject: [manet] F= wd: Mail lost yesterday
 
 
*** WARNING ***

This message originates from outside our organisation= , either from an external partner or the internet.
Keep this in mind if y= ou answer this message.
For information regard= ing Red Flags that you can look out for in emails you receive, click here. If you feel the email = is suspicious, please follow this process.

Working Group - 
FYI.
 
Regards,
Stan
 
 
Begin forwarded message:


= Resent-From: <= span style=3D"font-size: 13.5pt; font-family: Helvetica, sans-serif; "><= wg-alias-bounces@tools.ietf.org>
= From: Adrian Farr= el <adrian@olddog.co.uk>
= Subject: FW: Mail lost yesterday
= Date: August 29, = 2013 10:46:09 AM EDT
= Reply-To: <adrian@olddog.co.uk>
 

For those of you who haven't noticed the message from Steve Young in
your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific
Time yesterday seems to have been lost. Aside from needing to re-send
all mail you personally sent during that time period, you also need to
inform your working groups.

 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/ma= net

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1149D860xmbalnx03ciscoc_-- From bebemaster@gmail.com Fri Aug 30 07:35:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2187221F9A7D for ; Fri, 30 Aug 2013 07:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f2NCp-uuhK5 for ; Fri, 30 Aug 2013 07:35:35 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 158D521F9A05 for ; Fri, 30 Aug 2013 07:35:23 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id es20so1629005lab.9 for ; Fri, 30 Aug 2013 07:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vVDRqVXyuFat4uuu44YAUhg2x0mslzB8JUHcuZPSPjI=; b=M/zZir5rJmqR+JjP+sjLP7pHZm2I7rb1Rza6ghVPLwoi69JIB+3VLIOsnea7ZcMwhM RR5roj1+JAFiBILzA0sAf+2NN+gykR98Pf17Qw7sYIw9xn+7AXjbrJm/pwLsEzC/Ez52 /vCv7JbowhoXCxC8CBywbgMDYhprAf73qzVp+d/XCQrKiN/joQPjBn06gftjKN75He5k wJjRe/umUetXOmlhIEdLjtPtFOvURI5blILR/q/XemLUQCcKxuaP489ZuyukBZoUbXH1 wLawrh/SRbXklcdfKp619lBeQtnGsVJ9hpT4lwzmC7cA4YpgizAW+ROCDJkYVYcZ48N0 VX2w== MIME-Version: 1.0 X-Received: by 10.112.150.97 with SMTP id uh1mr2144872lbb.34.1377873322834; Fri, 30 Aug 2013 07:35:22 -0700 (PDT) Received: by 10.152.125.136 with HTTP; Fri, 30 Aug 2013 07:35:22 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> Date: Fri, 30 Aug 2013 10:35:22 -0400 Message-ID: From: Justin Dean To: Ulrich Herberg Content-Type: multipart/alternative; boundary=047d7b342d4af4015004e52b21c9 Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org List" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 14:35:38 -0000 --047d7b342d4af4015004e52b21c9 Content-Type: text/plain; charset=ISO-8859-1 I support adoption of this draft by the working group as it addresses a previously undefined behavior of the NHDP/OLSRv2 protocols. I do have implementations and I don't see any issues with this document. I just so happened to make similar choices in behavior, if I hadn't however the changes would be simple to implement and even if I didn't nothing would "break" as no new TLVs or values are introduced with this document. Even protocols extended with future TLVs (and values) which took advantage of the behaviors outlined in this document wouldn't break anything in non-compliant protocols, they just wouldn't play as nice together (which is the current case anyhow). I do have issue with some of the language and found it overly difficult to understand what was being specified. I'm willing to provide some more concrete feedback in this regard later. Justin On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg wrote: > I don't see any issues with the approach of the TLV extension draft. Like > Chris said, it specifies a behavior that was previously unspecified (and > thus undefined). > On the procedural question, the IETF has introduced "updates RFCxxxx" for > a good reason, and I think this particular case is such a case. > > Ulrich > > > > On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > >> I thought I'd replied to this, but can't see on list. I think your >> characterisation of this whole issue is wrong. >> >> Currently, there is no specification what to do when seeing an unknown >> value. This defines one. Of course with no specification, people can do >> anything (including dropping the message). That's undesirable, let's fix it. >> >> As for the sacrosanctness of the specification, let's be real. How many >> implementations actually are there yet? Is there anyone with one who finds >> this other than a positive thing? >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Teco Boot [mailto:teco@inf-net.nl] >> Sent: 17 August 2013 08:37 >> To: Henning Rogge >> Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.orgList; Joe Macker ( >> joseph.macker@nrl.navy.mil); Thomas Heide Clausen ( >> thomas@thomasclausen.org); Stan Ratliff (sratliff) >> Subject: Re: [manet] IDs presemted in Berlin >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Can I read this as: >> >> 1) an implementations that did not implement this new specification might >> drop these new messages and therefore is not compatible >> 2) an implementations that did not implement this new specification might >> accept these new messages and therefore is compatible >> >> "old" of "new" is not important. It is about stability of the standard. >> We have to stop incremental changes that are not backwards compatible. Or >> step to new version or similar tag. >> >> Teco >> >> Op 16 aug. 2013, om 23:41 heeft Henning Rogge >> het volgende geschreven: >> >> > If I understand the draft right we have the following situations: >> > >> > 1) an "old" implementation should interop with a "new" one without any >> > extensions easily. >> > 2) an "old" implementation might just drop messages from a "new" >> > implementation which use an extension >> > >> > Henning Rogge >> > >> > On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >> >> Yes. >> >> >> >> Teco >> >> >> >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove < >> christopher.dearlove@gmail.com> het volgende geschreven: >> >> >> >>> Have you read the draft? >> >>> >> >>> -- >> >>> Christopher Dearlove >> >>> christopher.dearlove@gmail.com (iPhone) >> >>> chris@mnemosyne.demon.co.uk (home) >> >>> >> >>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >> >>> >> >>>> I understand the change is documented. >> >>>> My concerns are on what happens when different implementations are >> in same network. This has to be documented. Asking on mailing list is not >> enough. >> >>>> >> >>>> Teco >> >>>> >> >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove < >> christopher.dearlove@gmail.com> het volgende geschreven: >> >>>> >> >>>>> I think you are quite wrong on the obsoleted point. Especially when >> we are talking changes to define what was previously undefined. Nothing >> defined has changed. Which is just like the TOS change. >> >>>>> >> >>>>> But if you want to know what's changed, read the draft. >> >>>>> >> >>>>> I'd be interested in hearing from people with implementations. If >> the bottom line is that there isn't anyone with an implementation who has a >> problem, I think worries over a hypothetical unwritten implementation are >> rather beside the point. Anyone coming to something new could always check >> the "updated by" bit. >> >>>>> >> >>>>> >> >>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >> >>>>> >> >>>>>> If anyone in the future writes code that complies with std track >> RFC, he/she may assume that it is compatible with any other implementation. >> If an update of that RFC will break compatibility, that RFC shall be >> obsoleted, I think. >> >>>>>> >> >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are >> to be used to guide", "may". Remapping to DSCP is highly backwards >> compatible. >> >>>>>> >> >>>>>> Did I say I'm against? I just want to know the issues / problems. >> At least they should be documented. >> >>>>>> >> >>>>>> Teco >> >>>>>> >> >>>>>> >> >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove < >> christopher.dearlove@gmail.com> het volgende geschreven: >> >>>>>> >> >>>>>>> You can read this that there are minor issues, which I wouldn't >> elevate to the level of problems. >> >>>>>>> >> >>>>>>> Your comment on the inability to modify RFCs is just plain wrong. >> Was RFC 791 obsoleted when the TOS bits function was changed? No. Many more >> such examples could be given. >> >>>>>>> >> >>>>>>> I'm actually not aware of anyone with an implementation who >> doesn't support this. Just in case not obvious, that includes me. >> >>>>>>> >> >>>>>>> Does anyone with an implementation have an issue? >> >>>>>>> >> >>>>>>> >> >>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >> >>>>>>> >> >>>>>>>> May I read that there are problems? >> >>>>>>>> If so, we cannot bring out a std track RFC followed up with >> something that can not interoperate with it. Or we mark the to_be RFC as >> obsolete. That's how it works. >> >>>>>>>> >> >>>>>>>> Teco >> >>>>>>>> >> >>>>>>>> PS1. you mentioned something about IESG and correctness... >> >>>>>>>> PS2: I understand the motivation. discussion could be how to >> deal with it. >> >>>>>>>> >> >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove < >> christopher.dearlove@gmail.com> het volgende geschreven: >> >>>>>>>> >> >>>>>>>>> I think my starting point with such a discussion would be who >> has an implementation? Yes, there are possible minor issues for >> implementations (though it's also possible for an implementation to need no >> changes at all). But the most pointless thing would be protecting (in a >> minor way) hypothetical implementations while people actually with them >> want this. >> >>>>>>>>> >> >>>>>>>>> (I'm not saying those with them have all said they want this. >> I'm asking.) >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> Christopher Dearlove >> >>>>>>>>> christopher.dearlove@gmail.com (iPhone) >> >>>>>>>>> chris@mnemosyne.demon.co.uk (home) >> >>>>>>>>> >> >>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >> >>>>>>>>> >> >>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce >> problems in a network with and without routers that implement this? >> >>>>>>>>>> If so, I think we need some discussion first. >> >>>>>>>>>> >> >>>>>>>>>> Teco >> >>>>>>>>>> >> >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) < >> sratliff@cisco.com> het volgende geschreven: >> >>>>>>>>>> >> >>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these >> documents as working group docs? >> >>>>>>>>>>> >> >>>>>>>>>>> Regards, >> >>>>>>>>>>> Stan >> >>>>>>>>>>> >> >>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" < >> chris.dearlove@baesystems.com> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> I don't believe that the chairs have raised the WG adoption >> of the IDs I presented at Berlin. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization >> and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for >> Standards Track, and as minor updates to NHDP and OLSRv2, which we would >> like to progress as fast as possible. >> >>>>>>>>>>>> >> >>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd >> obvious have no problem with being adopted as a WG document, but it needs >> at least one more revision, which we intend to do as an author draft, so >> there isn't the same time pressure there. However of course we would like >> discussion any time from now. >> >>>>>>>>>>>> >> >>>>>>>>>>>> -- >> >>>>>>>>>>>> Christopher Dearlove >> >>>>>>>>>>>> Senior Principal Engineer, Communications Group >> >>>>>>>>>>>> Communications, Networks and Image Analysis Capability >> >>>>>>>>>>>> BAE Systems Advanced Technology Centre >> >>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> >>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> >>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >> >>>>>>>>>>>> >> >>>>>>>>>>>> BAE Systems (Operations) Limited >> >>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough >> Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >> >>>>>>>>>>>> Registered in England & Wales No: 1996687 >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> ******************************************************************** >> >>>>>>>>>>>> This email and any attachments are confidential to the >> intended >> >>>>>>>>>>>> recipient and may also be privileged. If you are not the >> intended >> >>>>>>>>>>>> recipient please delete it from your system and notify the >> sender. >> >>>>>>>>>>>> You should not copy it or use it for any purpose nor >> disclose or >> >>>>>>>>>>>> distribute its contents to any other person. >> >>>>>>>>>>>> >> ******************************************************************** >> >>>>>>>>>>> >> >>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>> manet mailing list >> >>>>>>>>>>> manet@ietf.org >> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >> >>>>>>>>>> >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> manet mailing list >> >>>>>>>>>> manet@ietf.org >> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >> >>>> >> >> >> >> _______________________________________________ >> >> manet mailing list >> >> manet@ietf.org >> >> https://www.ietf.org/mailman/listinfo/manet >> > >> > >> > >> > -- >> > We began as wanderers, and we are wanderers still. We have lingered >> > long enough on the shores of the cosmic ocean. We are ready at last to >> > set sail for the stars - Carl Sagan >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b342d4af4015004e52b21c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support adoption of this draft by the working = group as it addresses a previously undefined behavior of the NHDP/OLSRv2 pr= otocols.=A0 I do have implementations and I don't see any issues with t= his document.=A0 I just so happened to make similar choices in behavior, if= I hadn't however the changes would be simple to implement and even if = I didn't nothing would "break" as no new TLVs or values are i= ntroduced with this document.=A0 Even protocols extended with future TLVs (= and values) which took advantage of the behaviors outlined in this document= wouldn't break anything in non-compliant protocols, they just wouldn&#= 39;t play as nice together (which is the current case anyhow).

I do have issue with some of the language and found it overly dif= ficult to understand what was being specified.=A0 I'm willing to provid= e some more concrete feedback in this regard later.

Justin


On Tue,= Aug 27, 2013 at 10:05 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
I don't see any is= sues with the approach of the TLV extension draft. Like Chris said, it spec= ifies a behavior that was previously unspecified (and thus undefined).
On the procedural question, the IETF has introduced "update= s RFCxxxx" for a good reason, and I think this particular case is such= a case.
Ulrich



On Tue, Aug 27, 2013 at 2:40 = AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com<= /a>> wrote:
I thought I'd replied to this, but can&#= 39;t see on list. I think your characterisation of this whole issue is wron= g.

Currently, there is no specification what to do when seeing an unknown valu= e. This defines one. Of course with no specification, people can do anythin= g (including dropping the message). That's undesirable, let's fix i= t.

As for the sacrosanctness of the specification, let's be real. How many= implementations actually are there yet? Is there anyone with one who finds= this other than a positive thing?
-----Original Message-----
From: Teco Boot [mailto:teco@inf-net.nl]
Sent: 17 August 2013 08:37
To: Henning Rogge
Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org List; Joe Macker (joseph.macker@nrl.= navy.mil); Thomas Heide Clausen (thomas@thomasclausen.org); Stan Ratliff (sratli= ff)
Subject: Re: [manet] IDs presemted in Berlin

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Can I read this as:

1) an implementations that did not implement this new specification might d= rop these new messages and therefore is not compatible
2) an implementations that did not implement this new specification might a= ccept these new messages and therefore is compatible

"old" of "new" is not important. It is about stability = of the standard. We have to stop incremental changes that are not backwards= compatible. Or step to new version or similar tag.

Teco

Op 16 aug. 2013, om 23:41 heeft Henning Rogge <hrogge@googlemail.com> het volgend= e geschreven:

> If I understand the draft right we have the following situations:
>
> 1) an "old" implementation should interop with a "new&q= uot; one without any
> extensions easily.
> 2) an "old" implementation might just drop messages from a &= quot;new"
> implementation which use an extension
>
> Henning Rogge
>
> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot <teco@inf-net.nl> wrote:
>> Yes.
>>
>> Teco
>>
>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove <christopher.de= arlove@gmail.com> het volgende geschreven:
>>
>>> Have you read the draft?
>>>
>>> --
>>> Christopher Dearlove
>>> christopher.dearlove@gmail.com (iPhone)
>>> chris@mnemosyne.demon.co.uk (home)
>>>
>>> On 16 Aug 2013, at 21:58, Teco Boot <teco@inf-net.nl> wrote:
>>>
>>>> I understand the change is documented.
>>>> My concerns are on what happens when different implementat= ions are in same network. This has to be documented. Asking on mailing list= is not enough.
>>>>
>>>> Teco
>>>>
>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove <<= a href=3D"mailto:christopher.dearlove@gmail.com" target=3D"_blank">christop= her.dearlove@gmail.com> het volgende geschreven:
>>>>
>>>>> I think you are quite wrong on the obsoleted point. Es= pecially when we are talking changes to define what was previously undefine= d. Nothing defined has changed. Which is just like the TOS change.
>>>>>
>>>>> But if you want to know what's changed, read the d= raft.
>>>>>
>>>>> I'd be interested in hearing from people with impl= ementations. If the bottom line is that there isn't anyone with an impl= ementation who has a problem, I think worries over a hypothetical unwritten= implementation are rather beside the point. Anyone coming to something new= could always check the "updated by" bit.
>>>>>
>>>>>
>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote:
>>>>>
>>>>>> If anyone in the future writes code that complies = with std track RFC, he/she may assume that it is compatible with any other = implementation. If an update of that RFC will break compatibility, that RFC= shall be obsoleted, I think.
>>>>>>
>>>>>> RFC 791 was 1981. Wording on TOS: "provides a= n indication", "are to be used to guide", "may". R= emapping to DSCP is highly backwards compatible.
>>>>>>
>>>>>> Did I say I'm against? I just want to know the= issues / problems. At least they should be documented.
>>>>>>
>>>>>> Teco
>>>>>>
>>>>>>
>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlo= ve <= christopher.dearlove@gmail.com> het volgende geschreven:
>>>>>>
>>>>>>> You can read this that there are minor issues,= which I wouldn't elevate to the level of problems.
>>>>>>>
>>>>>>> Your comment on the inability to modify RFCs i= s just plain wrong. Was RFC 791 obsoleted when the TOS bits function was ch= anged? No. Many more such examples could be given.
>>>>>>>
>>>>>>> I'm actually not aware of anyone with an i= mplementation who doesn't support this. Just in case not obvious, that = includes me.
>>>>>>>
>>>>>>> Does anyone with an implementation have an iss= ue?
>>>>>>>
>>>>>>>
>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote:
>>>>>>>
>>>>>>>> May I read that there are problems?
>>>>>>>> If so, we cannot bring out a std track RFC= followed up with something that can not interoperate with it. Or we mark t= he to_be RFC as obsolete. That's how it works.
>>>>>>>>
>>>>>>>> Teco
>>>>>>>>
>>>>>>>> PS1. you mentioned something about IESG an= d correctness...
>>>>>>>> PS2: I understand the motivation. discussi= on could be how to deal with it.
>>>>>>>>
>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christophe= r Dearlove <christopher.dearlove@gmail.com> het volgende geschreven:
>>>>>>>>
>>>>>>>>> I think my starting point with such a = discussion would be who has an implementation? Yes, there are possible mino= r issues for implementations (though it's also possible for an implemen= tation to need no changes at all). But the most pointless thing would be pr= otecting (in a minor way) hypothetical implementations while people actuall= y with them want this.
>>>>>>>>>
>>>>>>>>> (I'm not saying those with them ha= ve all said they want this. I'm asking.)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Christopher Dearlove
>>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>> chris@mnemosyne.demon.co.uk (home)
>>>>>>>>>
>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot &l= t;teco@inf-net.nl&= gt; wrote:
>>>>>>>>>
>>>>>>>>>> Does draft-dearlove-manet-nhdp-ols= rv2-tlv-extension introduce problems in a network with and without routers = that implement this?
>>>>>>>>>> If so, I think we need some discus= sion first.
>>>>>>>>>>
>>>>>>>>>> Teco
>>>>>>>>>>
>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft St= an Ratliff (sratliff) <sratliff@cisco.com> het volgende geschreven:
>>>>>>>>>>
>>>>>>>>>>> OK, so to the WG - do we have = consensus to adopt these documents as working group docs?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Stan
>>>>>>>>>>>
>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, &= quot;Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> wro= te:
>>>>>>>>>>>
>>>>>>>>>>>> I don't believe that t= he chairs have raised the WG adoption of the IDs I presented at Berlin.
>>>>>>>>>>>>
>>>>>>>>>>>> Two of these, draft-dearlo= ve-manet-olsrv2-rmpr-optimization and draft-dearlove-manet-nhdp-olsrv2-tlv-= extension are intended for Standards Track, and as minor updates to NHDP an= d OLSRv2, which we would like to progress as fast as possible.
>>>>>>>>>>>>
>>>>>>>>>>>> The third, draft-dearlove-= manet-olsrv2-multitopology, we'd obvious have no problem with being ado= pted as a WG document, but it needs at least one more revision, which we in= tend to do as an author draft, so there isn't the same time pressure th= ere. However of course we would like discussion any time from now.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Christopher Dearlove
>>>>>>>>>>>> Senior Principal Engineer,= Communications Group
>>>>>>>>>>>> Communications, Networks a= nd Image Analysis Capability
>>>>>>>>>>>> BAE Systems Advanced Techn= ology Centre
>>>>>>>>>>>> West Hanningfield Road, Gr= eat Baddow, Chelmsford, CM2 8HN, UK
>>>>>>>>>>>> Tel: +44 1245 242194<= /a> | =A0Fax: +44 1245 242124
>>>>>>>>>>>> chris.dearlove@baesystems.com = | http://www.baesys= tems.com
>>>>>>>>>>>>
>>>>>>>>>>>> BAE Systems (Operations) L= imited
>>>>>>>>>>>> Registered Office: Warwick= House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6= YU, UK
>>>>>>>>>>>> Registered in England &= ; Wales No: 1996687
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> **************************= ******************************************
>>>>>>>>>>>> This email and any attachm= ents are confidential to the intended
>>>>>>>>>>>> recipient and may also be = privileged. If you are not the intended
>>>>>>>>>>>> recipient please delete it= from your system and notify the sender.
>>>>>>>>>>>> You should not copy it or = use it for any purpose nor disclose or
>>>>>>>>>>>> distribute its contents to= any other person.
>>>>>>>>>>>> **************************= ******************************************
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> manet mailing list
>>>>>>>>>>> manet@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/li= stinfo/manet
>>>>>>>>>>
>>>>>>>>>> __________________________________= _____________
>>>>>>>>>> manet mailing list
>>>>>>>>>> manet@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listin= fo/manet
>>>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org=
>> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> --
> We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to=
> set sail for the stars - Carl Sagan


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--047d7b342d4af4015004e52b21c9-- From christopher.dearlove@gmail.com Fri Aug 30 08:34:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2359311E811E for ; Fri, 30 Aug 2013 08:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq4hmlU9pYxO for ; Fri, 30 Aug 2013 08:34:54 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id B0C4611E80FA for ; Fri, 30 Aug 2013 08:34:53 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e12so941364wgh.9 for ; Fri, 30 Aug 2013 08:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=X5SmOvJch4hTiTaG/0hW8J+yWpChzf2JR2Htx3Exphc=; b=PXH3VXI0UCYdoO8IanDmBf1OZZvhx6bcZT998lbPHfKhHs8isfzlI6wZgpuEkQjf3E 9uNjw6fj4GSfvJJiNnylxWe4YwFi04CFfSnITdTZDn2UA/2dWnT6HXwIcpCEx874nteH aYKoc6QBnE8peU+b7tr0575zSAlvHairWklVdxpQif6jELDQEaQS+q9z3zVas7OUbVOj xH9ga66w7xXdXKvnNGMFThRCxloRveUKxUQG+eGGFj2GKGi4gERGEKpgh90eeaSBoKG+ YAZEKGX/6nXoqIuSd9K67l503gXW36sOPZvo8b7nUynZ8T+C23IlztwzC64eIsiEhxxI 2FVA== X-Received: by 10.194.176.74 with SMTP id cg10mr390423wjc.75.1377876892795; Fri, 30 Aug 2013 08:34:52 -0700 (PDT) Received: from [172.20.10.3] (dab-rcn1-h-31-9.dab.02.net. [82.132.247.107]) by mx.google.com with ESMTPSA id fv10sm4661960wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 08:34:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_EB1D6472-0759-4DCE-B0F2-4E1AF6FA2C8B" From: Christopher Dearlove In-Reply-To: Date: Fri, 30 Aug 2013 16:34:44 +0100 Message-Id: <856EBC8D-66A4-47F4-936B-BD77C579542F@gmail.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> To: Justin Dean X-Mailer: Apple Mail (2.1283) Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 15:34:56 -0000 --Apple-Mail=_EB1D6472-0759-4DCE-B0F2-4E1AF6FA2C8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Your feedback is always welcome, whether at author stage or WG stage. To be clear you say "this draft", which from comments must be the TLV = extensions draft. There are actually two drafts we're asking about, the = other being the MPR optimisation (which has no compatibility issues at = all I believe) but support to adopt as WG draft welcome. We hope soon to have a new version of the MT draft, which comment will = also be welcome on. On 30 Aug 2013, at 15:35, Justin Dean wrote: > I support adoption of this draft by the working group as it addresses = a previously undefined behavior of the NHDP/OLSRv2 protocols. I do have = implementations and I don't see any issues with this document. I just = so happened to make similar choices in behavior, if I hadn't however the = changes would be simple to implement and even if I didn't nothing would = "break" as no new TLVs or values are introduced with this document. = Even protocols extended with future TLVs (and values) which took = advantage of the behaviors outlined in this document wouldn't break = anything in non-compliant protocols, they just wouldn't play as nice = together (which is the current case anyhow). >=20 > I do have issue with some of the language and found it overly = difficult to understand what was being specified. I'm willing to = provide some more concrete feedback in this regard later. >=20 > Justin >=20 >=20 > On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg = wrote: > I don't see any issues with the approach of the TLV extension draft. = Like Chris said, it specifies a behavior that was previously unspecified = (and thus undefined). > On the procedural question, the IETF has introduced "updates RFCxxxx" = for a good reason, and I think this particular case is such a case. >=20 > Ulrich >=20 >=20 >=20 > On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) = wrote: > I thought I'd replied to this, but can't see on list. I think your = characterisation of this whole issue is wrong. >=20 > Currently, there is no specification what to do when seeing an unknown = value. This defines one. Of course with no specification, people can do = anything (including dropping the message). That's undesirable, let's fix = it. >=20 > As for the sacrosanctness of the specification, let's be real. How = many implementations actually are there yet? Is there anyone with one = who finds this other than a positive thing? >=20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 17 August 2013 08:37 > To: Henning Rogge > Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org = List; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen = (thomas@thomasclausen.org); Stan Ratliff (sratliff) > Subject: Re: [manet] IDs presemted in Berlin >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Can I read this as: >=20 > 1) an implementations that did not implement this new specification = might drop these new messages and therefore is not compatible > 2) an implementations that did not implement this new specification = might accept these new messages and therefore is compatible >=20 > "old" of "new" is not important. It is about stability of the = standard. We have to stop incremental changes that are not backwards = compatible. Or step to new version or similar tag. >=20 > Teco >=20 > Op 16 aug. 2013, om 23:41 heeft Henning Rogge = het volgende geschreven: >=20 > > If I understand the draft right we have the following situations: > > > > 1) an "old" implementation should interop with a "new" one without = any > > extensions easily. > > 2) an "old" implementation might just drop messages from a "new" > > implementation which use an extension > > > > Henning Rogge > > > > On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: > >> Yes. > >> > >> Teco > >> > >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove = het volgende geschreven: > >> > >>> Have you read the draft? > >>> > >>> -- > >>> Christopher Dearlove > >>> christopher.dearlove@gmail.com (iPhone) > >>> chris@mnemosyne.demon.co.uk (home) > >>> > >>> On 16 Aug 2013, at 21:58, Teco Boot wrote: > >>> > >>>> I understand the change is documented. > >>>> My concerns are on what happens when different implementations = are in same network. This has to be documented. Asking on mailing list = is not enough. > >>>> > >>>> Teco > >>>> > >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove = het volgende geschreven: > >>>> > >>>>> I think you are quite wrong on the obsoleted point. Especially = when we are talking changes to define what was previously undefined. = Nothing defined has changed. Which is just like the TOS change. > >>>>> > >>>>> But if you want to know what's changed, read the draft. > >>>>> > >>>>> I'd be interested in hearing from people with implementations. = If the bottom line is that there isn't anyone with an implementation who = has a problem, I think worries over a hypothetical unwritten = implementation are rather beside the point. Anyone coming to something = new could always check the "updated by" bit. > >>>>> > >>>>> > >>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: > >>>>> > >>>>>> If anyone in the future writes code that complies with std = track RFC, he/she may assume that it is compatible with any other = implementation. If an update of that RFC will break compatibility, that = RFC shall be obsoleted, I think. > >>>>>> > >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", = "are to be used to guide", "may". Remapping to DSCP is highly backwards = compatible. > >>>>>> > >>>>>> Did I say I'm against? I just want to know the issues / = problems. At least they should be documented. > >>>>>> > >>>>>> Teco > >>>>>> > >>>>>> > >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove = het volgende geschreven: > >>>>>> > >>>>>>> You can read this that there are minor issues, which I = wouldn't elevate to the level of problems. > >>>>>>> > >>>>>>> Your comment on the inability to modify RFCs is just plain = wrong. Was RFC 791 obsoleted when the TOS bits function was changed? No. = Many more such examples could be given. > >>>>>>> > >>>>>>> I'm actually not aware of anyone with an implementation who = doesn't support this. Just in case not obvious, that includes me. > >>>>>>> > >>>>>>> Does anyone with an implementation have an issue? > >>>>>>> > >>>>>>> > >>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: > >>>>>>> > >>>>>>>> May I read that there are problems? > >>>>>>>> If so, we cannot bring out a std track RFC followed up with = something that can not interoperate with it. Or we mark the to_be RFC as = obsolete. That's how it works. > >>>>>>>> > >>>>>>>> Teco > >>>>>>>> > >>>>>>>> PS1. you mentioned something about IESG and correctness... > >>>>>>>> PS2: I understand the motivation. discussion could be how to = deal with it. > >>>>>>>> > >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove = het volgende geschreven: > >>>>>>>> > >>>>>>>>> I think my starting point with such a discussion would be = who has an implementation? Yes, there are possible minor issues for = implementations (though it's also possible for an implementation to need = no changes at all). But the most pointless thing would be protecting (in = a minor way) hypothetical implementations while people actually with = them want this. > >>>>>>>>> > >>>>>>>>> (I'm not saying those with them have all said they want = this. I'm asking.) > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Christopher Dearlove > >>>>>>>>> christopher.dearlove@gmail.com (iPhone) > >>>>>>>>> chris@mnemosyne.demon.co.uk (home) > >>>>>>>>> > >>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: > >>>>>>>>> > >>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension = introduce problems in a network with and without routers that implement = this? > >>>>>>>>>> If so, I think we need some discussion first. > >>>>>>>>>> > >>>>>>>>>> Teco > >>>>>>>>>> > >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) = het volgende geschreven: > >>>>>>>>>> > >>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these = documents as working group docs? > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Stan > >>>>>>>>>>> > >>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" = wrote: > >>>>>>>>>>> > >>>>>>>>>>>> I don't believe that the chairs have raised the WG = adoption of the IDs I presented at Berlin. > >>>>>>>>>>>> > >>>>>>>>>>>> Two of these, = draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible. > >>>>>>>>>>>> > >>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, = we'd obvious have no problem with being adopted as a WG document, but it = needs at least one more revision, which we intend to do as an author = draft, so there isn't the same time pressure there. However of course we = would like discussion any time from now. > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Christopher Dearlove > >>>>>>>>>>>> Senior Principal Engineer, Communications Group > >>>>>>>>>>>> Communications, Networks and Image Analysis Capability > >>>>>>>>>>>> BAE Systems Advanced Technology Centre > >>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 = 8HN, UK > >>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com > >>>>>>>>>>>> > >>>>>>>>>>>> BAE Systems (Operations) Limited > >>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > >>>>>>>>>>>> Registered in England & Wales No: 1996687 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> = ******************************************************************** > >>>>>>>>>>>> This email and any attachments are confidential to the = intended > >>>>>>>>>>>> recipient and may also be privileged. If you are not the = intended > >>>>>>>>>>>> recipient please delete it from your system and notify = the sender. > >>>>>>>>>>>> You should not copy it or use it for any purpose nor = disclose or > >>>>>>>>>>>> distribute its contents to any other person. > >>>>>>>>>>>> = ******************************************************************** > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> manet mailing list > >>>>>>>>>>> manet@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> manet mailing list > >>>>>>>>>> manet@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > > > > > -- > > We began as wanderers, and we are wanderers still. We have lingered > > long enough on the shores of the cosmic ocean. We are ready at last = to > > set sail for the stars - Carl Sagan >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 --Apple-Mail=_EB1D6472-0759-4DCE-B0F2-4E1AF6FA2C8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

We hope soon to have a new = version of the MT draft, which comment will also be welcome = on.


On 30 Aug 2013, at 15:35, Justin = Dean wrote:

I support adoption of = this draft by the working group as it addresses a previously undefined = behavior of the NHDP/OLSRv2 protocols.  I do have implementations = and I don't see any issues with this document.  I just so happened = to make similar choices in behavior, if I hadn't however the changes = would be simple to implement and even if I didn't nothing would "break" = as no new TLVs or values are introduced with this document.  Even = protocols extended with future TLVs (and values) which took advantage of = the behaviors outlined in this document wouldn't break anything in = non-compliant protocols, they just wouldn't play as nice together (which = is the current case anyhow).

I do have issue with some of the language and found it overly = difficult to understand what was being specified.  I'm willing to = provide some more concrete feedback in this regard = later.

Justin


On = Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
I = don't see any issues with the approach of the TLV extension draft. Like = Chris said, it specifies a behavior that was previously unspecified (and = thus undefined).
On the procedural question, the IETF has introduced "updates = RFCxxxx" for a good reason, and I think this particular case is such a = case.

Ulrich



On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, = Christopher (UK) <chris.dearlove@baesystems.com> = wrote:
I thought I'd replied = to this, but can't see on list. I think your characterisation of this = whole issue is wrong.

Currently, there is no specification what to do when seeing an unknown = value. This defines one. Of course with no specification, people can do = anything (including dropping the message). That's undesirable, let's fix = it.

As for the sacrosanctness of the specification, let's be real. How many = implementations actually are there yet? Is there anyone with one who = finds this other than a positive thing?

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Teco Boot [mailto:teco@inf-net.nl]
Sent: 17 August 2013 08:37
To: Henning Rogge
Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org = List; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen = (thomas@thomasclausen.org); Stan Ratliff = (sratliff)
Subject: Re: [manet] IDs presemted in Berlin

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Can I read this as:

1) an implementations that did not implement this new specification = might drop these new messages and therefore is not compatible
2) an implementations that did not implement this new specification = might accept these new messages and therefore is compatible

"old" of "new" is not important. It is about stability of the standard. = We have to stop incremental changes that are not backwards compatible. = Or step to new version or similar tag.

Teco

Op 16 aug. 2013, om 23:41 heeft Henning Rogge <hrogge@googlemail.com> het volgende = geschreven:

> If I understand the draft right we have the following = situations:
>
> 1) an "old" implementation should interop with a "new" one without = any
> extensions easily.
> 2) an "old" implementation might just drop messages from a = "new"
> implementation which use an extension
>
> Henning Rogge
>
> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot <teco@inf-net.nl> = wrote:
>> Yes.
>>
>> Teco
>>
>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove <christopher.dearlove@gmail.com> het volgende = geschreven:
>>
>>> Have you read the draft?
>>>
>>> --
>>> Christopher Dearlove
>>> christopher.dearlove@gmail.com (iPhone)
>>> chris@mnemosyne.demon.co.uk (home)
>>>
>>> On 16 Aug 2013, at 21:58, Teco Boot <teco@inf-net.nl> = wrote:
>>>
>>>> I understand the change is documented.
>>>> My concerns are on what happens when different = implementations are in same network. This has to be documented. Asking = on mailing list is not enough.
>>>>
>>>> Teco
>>>>
>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove = <christopher.dearlove@gmail.com> het volgende = geschreven:
>>>>
>>>>> I think you are quite wrong on the obsoleted point. = Especially when we are talking changes to define what was previously = undefined. Nothing defined has changed. Which is just like the TOS = change.
>>>>>
>>>>> But if you want to know what's changed, read the = draft.
>>>>>
>>>>> I'd be interested in hearing from people with = implementations. If the bottom line is that there isn't anyone with an = implementation who has a problem, I think worries over a hypothetical = unwritten implementation are rather beside the point. Anyone coming to = something new could always check the "updated by" bit.
>>>>>
>>>>>
>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote:
>>>>>
>>>>>> If anyone in the future writes code that = complies with std track RFC, he/she may assume that it is compatible = with any other implementation. If an update of that RFC will break = compatibility, that RFC shall be obsoleted, I think.
>>>>>>
>>>>>> RFC 791 was 1981. Wording on TOS: "provides an = indication", "are to be used to guide", "may". Remapping to DSCP is = highly backwards compatible.
>>>>>>
>>>>>> Did I say I'm against? I just want to know the = issues / problems. At least they should be documented.
>>>>>>
>>>>>> Teco
>>>>>>
>>>>>>
>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher = Dearlove <christopher.dearlove@gmail.com> het volgende = geschreven:
>>>>>>
>>>>>>> You can read this that there are minor = issues, which I wouldn't elevate to the level of problems.
>>>>>>>
>>>>>>> Your comment on the inability to modify = RFCs is just plain wrong. Was RFC 791 obsoleted when the TOS bits = function was changed? No. Many more such examples could be given.
>>>>>>>
>>>>>>> I'm actually not aware of anyone with an = implementation who doesn't support this. Just in case not obvious, that = includes me.
>>>>>>>
>>>>>>> Does anyone with an implementation have an = issue?
>>>>>>>
>>>>>>>
>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot = wrote:
>>>>>>>
>>>>>>>> May I read that there are problems?
>>>>>>>> If so, we cannot bring out a std track = RFC followed up with something that can not interoperate with it. Or we = mark the to_be RFC as obsolete. That's how it works.
>>>>>>>>
>>>>>>>> Teco
>>>>>>>>
>>>>>>>> PS1. you mentioned something about IESG = and correctness...
>>>>>>>> PS2: I understand the motivation. = discussion could be how to deal with it.
>>>>>>>>
>>>>>>>> Op 16 aug. 2013, om 18:43 heeft = Christopher Dearlove <christopher.dearlove@gmail.com> het volgende = geschreven:
>>>>>>>>
>>>>>>>>> I think my starting point with such = a discussion would be who has an implementation? Yes, there are possible = minor issues for implementations (though it's also possible for an = implementation to need no changes at all). But the most pointless thing = would be protecting (in a minor way) hypothetical implementations while = people actually with them want this.
>>>>>>>>>
>>>>>>>>> (I'm not saying those with them = have all said they want this. I'm asking.)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Christopher Dearlove
>>>>>>>>> christopher.dearlove@gmail.com (iPhone)
>>>>>>>>> chris@mnemosyne.demon.co.uk (home)
>>>>>>>>>
>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot = <teco@inf-net.nl> wrote:
>>>>>>>>>
>>>>>>>>>> Does = draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce problems in a = network with and without routers that implement this?
>>>>>>>>>> If so, I think we need some = discussion first.
>>>>>>>>>>
>>>>>>>>>> Teco
>>>>>>>>>>
>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft = Stan Ratliff (sratliff) <sratliff@cisco.com> het volgende = geschreven:
>>>>>>>>>>
>>>>>>>>>>> OK, so to the WG - do we = have consensus to adopt these documents as working group docs?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Stan
>>>>>>>>>>>
>>>>>>>>>>> On Aug 16, 2013, at 8:59 = AM, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I don't believe that = the chairs have raised the WG adoption of the IDs I presented at = Berlin.
>>>>>>>>>>>>
>>>>>>>>>>>> Two of these, = draft-dearlove-manet-olsrv2-rmpr-optimization and = draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for = Standards Track, and as minor updates to NHDP and OLSRv2, which we would = like to progress as fast as possible.
>>>>>>>>>>>>
>>>>>>>>>>>> The third, = draft-dearlove-manet-olsrv2-multitopology, we'd obvious have no problem = with being adopted as a WG document, but it needs at least one more = revision, which we intend to do as an author draft, so there isn't the = same time pressure there. However of course we would like discussion any = time from now.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Christopher = Dearlove
>>>>>>>>>>>> Senior Principal = Engineer, Communications Group
>>>>>>>>>>>> Communications, = Networks and Image Analysis Capability
>>>>>>>>>>>> BAE Systems Advanced = Technology Centre
>>>>>>>>>>>> West Hanningfield Road, = Great Baddow, Chelmsford, CM2 8HN, UK
>>>>>>>>>>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com
>>>>>>>>>>>>
>>>>>>>>>>>> BAE Systems = (Operations) Limited
>>>>>>>>>>>> Registered Office: = Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, = Hants, GU14 6YU, UK
>>>>>>>>>>>> Registered in England = & Wales No: 1996687
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> = ********************************************************************
>>>>>>>>>>>> This email and any = attachments are confidential to the intended
>>>>>>>>>>>> recipient and may also = be privileged. If you are not the intended
>>>>>>>>>>>> recipient please delete = it from your system and notify the sender.
>>>>>>>>>>>> You should not copy it = or use it for any purpose nor disclose or
>>>>>>>>>>>> distribute its contents = to any other person.
>>>>>>>>>>>> = ********************************************************************
>>>>>>>>>>>
>>>>>>>>>>> = _______________________________________________
>>>>>>>>>>> manet mailing list
>>>>>>>>>>> manet@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>>>>>>
>>>>>>>>>> = _______________________________________________
>>>>>>>>>> manet mailing list
>>>>>>>>>> manet@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> --
> We began as wanderers, and we are wanderers still. We have = lingered
> long enough on the shores of the cosmic ocean. We are ready at last = to
> set sail for the stars - Carl Sagan


_______________________________________________
manet mailing list
manet@ietf.org
= https://www.ietf.org/mailman/listinfo/manet


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



= --Apple-Mail=_EB1D6472-0759-4DCE-B0F2-4E1AF6FA2C8B-- From ietf@thomasclausen.org Fri Aug 30 09:34:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CE321F9E63 for ; Fri, 30 Aug 2013 09:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aph871wXC3BF for ; Fri, 30 Aug 2013 09:34:38 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2D321F9E54 for ; Fri, 30 Aug 2013 09:34:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 48F0CE1834; Fri, 30 Aug 2013 09:34:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.64.54.17] (unknown [37.161.227.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1416DE1831; Fri, 30 Aug 2013 09:34:36 -0700 (PDT) References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-26452C26-084F-4E86-8C52-7BA5D4E1073A Content-Transfer-Encoding: 7bit Message-Id: <78817FC1-24B1-422B-A0EB-4147498BF2D3@thomasclausen.org> X-Mailer: iPad Mail (10B329) From: Thomas Heide Clausen Date: Fri, 30 Aug 2013 18:34:32 +0200 To: Justin Dean Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:34:42 -0000 --Apple-Mail-26452C26-084F-4E86-8C52-7BA5D4E1073A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I should add that I have a *strict* implementation of OLSRv2, finished well b= efore these I-Ds were as much as a twinkle in Chris' eyes, and conforming st= rictly to draft-ietf-manet-olsrv2 as currently sitting with the RFC Editor. While that implementation - of course - will not generate TLVs of the form d= escribed in TLV-Extensions, it will happily process them and will do the rig= ht thing when presented with such TLVs (i.e., already interprets fields as b= it-vectors, process value field lengths "correctly", behave appropriately wh= en seeing unknown values and not discard the message as a consequence hereof= , etc.) Much the same as Justin describes for his implementations.=20 For the Routing MPR optimization I-D, the same applies: no interoperability i= ssues. Such interoperability was, indeed, a condition for me to join Chris in this (= these) I-D, and something I verified with my implementation in advance hereo= f: I actually wrote a small piece of test code that generates OLSRv2 message= s containing TLVs formatted according to the TLV-Extension I-D, and feed the= m to my OLSRv2 implementation, just to be sure. Justin: like Chris, I look forward to your - always very useful and construc= tive - detailed feedback and comments to the I-Ds. Teco: I appreciate that you worry about "running code" - that makes two of u= s (you know my position: running code is king, and pushing specs through wit= hout them is unacceptable). My conclusion is, based on the above, that there= are no interoperability issues between a "conformant" implementation of OLS= Rv2 and a "conformat" implementation of OLSRv2 + TLV-Extensions and/or routi= ng MPR optimization. (Of course, if someone shows up with a non-conformat implementation of a spe= c, then all bets are off on interoperability - but the IETF can't really gua= rd against implementations not following the specs, other than to try to "li= mit the damage" ..... which I think that OLSRv2 does nicely). Respectfully, Thomas Sent from my iPad On 30 ao=C3=BBt 2013, at 16:35, Justin Dean wrote: > I support adoption of this draft by the working group as it addresses a pr= eviously undefined behavior of the NHDP/OLSRv2 protocols. I do have impleme= ntations and I don't see any issues with this document. I just so happened t= o make similar choices in behavior, if I hadn't however the changes would be= simple to implement and even if I didn't nothing would "break" as no new TL= Vs or values are introduced with this document. Even protocols extended wit= h future TLVs (and values) which took advantage of the behaviors outlined in= this document wouldn't break anything in non-compliant protocols, they just= wouldn't play as nice together (which is the current case anyhow). >=20 > I do have issue with some of the language and found it overly difficult to= understand what was being specified. I'm willing to provide some more conc= rete feedback in this regard later. >=20 > Justin >=20 >=20 > On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg wro= te: >> I don't see any issues with the approach of the TLV extension draft. Like= Chris said, it specifies a behavior that was previously unspecified (and th= us undefined). >> On the procedural question, the IETF has introduced "updates RFCxxxx" for= a good reason, and I think this particular case is such a case. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) wrote: >>> I thought I'd replied to this, but can't see on list. I think your chara= cterisation of this whole issue is wrong. >>>=20 >>> Currently, there is no specification what to do when seeing an unknown v= alue. This defines one. Of course with no specification, people can do anyth= ing (including dropping the message). That's undesirable, let's fix it. >>>=20 >>> As for the sacrosanctness of the specification, let's be real. How many i= mplementations actually are there yet? Is there anyone with one who finds th= is other than a positive thing? >>>=20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Teco Boot [mailto:teco@inf-net.nl] >>> Sent: 17 August 2013 08:37 >>> To: Henning Rogge >>> Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org Lis= t; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen (thomas@tho= masclausen.org); Stan Ratliff (sratliff) >>> Subject: Re: [manet] IDs presemted in Berlin >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Can I read this as: >>>=20 >>> 1) an implementations that did not implement this new specification migh= t drop these new messages and therefore is not compatible >>> 2) an implementations that did not implement this new specification migh= t accept these new messages and therefore is compatible >>>=20 >>> "old" of "new" is not important. It is about stability of the standard. W= e have to stop incremental changes that are not backwards compatible. Or ste= p to new version or similar tag. >>>=20 >>> Teco >>>=20 >>> Op 16 aug. 2013, om 23:41 heeft Henning Rogge he= t volgende geschreven: >>>=20 >>> > If I understand the draft right we have the following situations: >>> > >>> > 1) an "old" implementation should interop with a "new" one without any= >>> > extensions easily. >>> > 2) an "old" implementation might just drop messages from a "new" >>> > implementation which use an extension >>> > >>> > Henning Rogge >>> > >>> > On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >>> >> Yes. >>> >> >>> >> Teco >>> >> >>> >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove het volgende geschreven: >>> >> >>> >>> Have you read the draft? >>> >>> >>> >>> -- >>> >>> Christopher Dearlove >>> >>> christopher.dearlove@gmail.com (iPhone) >>> >>> chris@mnemosyne.demon.co.uk (home) >>> >>> >>> >>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>> >>> >>> >>>> I understand the change is documented. >>> >>>> My concerns are on what happens when different implementations are i= n same network. This has to be documented. Asking on mailing list is not eno= ugh. >>> >>>> >>> >>>> Teco >>> >>>> >>> >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove het volgende geschreven: >>> >>>> >>> >>>>> I think you are quite wrong on the obsoleted point. Especially whe= n we are talking changes to define what was previously undefined. Nothing de= fined has changed. Which is just like the TOS change. >>> >>>>> >>> >>>>> But if you want to know what's changed, read the draft. >>> >>>>> >>> >>>>> I'd be interested in hearing from people with implementations. If t= he bottom line is that there isn't anyone with an implementation who has a p= roblem, I think worries over a hypothetical unwritten implementation are rat= her beside the point. Anyone coming to something new could always check the "= updated by" bit. >>> >>>>> >>> >>>>> >>> >>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>> >>>>> >>> >>>>>> If anyone in the future writes code that complies with std track R= FC, he/she may assume that it is compatible with any other implementation. I= f an update of that RFC will break compatibility, that RFC shall be obsolete= d, I think. >>> >>>>>> >>> >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are t= o be used to guide", "may". Remapping to DSCP is highly backwards compatible= . >>> >>>>>> >>> >>>>>> Did I say I'm against? I just want to know the issues / problems.= At least they should be documented. >>> >>>>>> >>> >>>>>> Teco >>> >>>>>> >>> >>>>>> >>> >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove het volgende geschreven: >>> >>>>>> >>> >>>>>>> You can read this that there are minor issues, which I wouldn't e= levate to the level of problems. >>> >>>>>>> >>> >>>>>>> Your comment on the inability to modify RFCs is just plain wrong= . Was RFC 791 obsoleted when the TOS bits function was changed? No. Many mor= e such examples could be given. >>> >>>>>>> >>> >>>>>>> I'm actually not aware of anyone with an implementation who does= n't support this. Just in case not obvious, that includes me. >>> >>>>>>> >>> >>>>>>> Does anyone with an implementation have an issue? >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>> >>>>>>> >>> >>>>>>>> May I read that there are problems? >>> >>>>>>>> If so, we cannot bring out a std track RFC followed up with som= ething that can not interoperate with it. Or we mark the to_be RFC as obsole= te. That's how it works. >>> >>>>>>>> >>> >>>>>>>> Teco >>> >>>>>>>> >>> >>>>>>>> PS1. you mentioned something about IESG and correctness... >>> >>>>>>>> PS2: I understand the motivation. discussion could be how to de= al with it. >>> >>>>>>>> >>> >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove het volgende geschreven: >>> >>>>>>>> >>> >>>>>>>>> I think my starting point with such a discussion would be who h= as an implementation? Yes, there are possible minor issues for implementatio= ns (though it's also possible for an implementation to need no changes at al= l). But the most pointless thing would be protecting (in a minor way) hypoth= etical implementations while people actually with them want this. >>> >>>>>>>>> >>> >>>>>>>>> (I'm not saying those with them have all said they want this. I= 'm asking.) >>> >>>>>>>>> >>> >>>>>>>>> -- >>> >>>>>>>>> Christopher Dearlove >>> >>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>> >>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>> >>>>>>>>> >>> >>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>> >>>>>>>>> >>> >>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce= problems in a network with and without routers that implement this? >>> >>>>>>>>>> If so, I think we need some discussion first. >>> >>>>>>>>>> >>> >>>>>>>>>> Teco >>> >>>>>>>>>> >>> >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) het volgende geschreven: >>> >>>>>>>>>> >>> >>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these docum= ents as working group docs? >>> >>>>>>>>>>> >>> >>>>>>>>>>> Regards, >>> >>>>>>>>>>> Stan >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>>> I don't believe that the chairs have raised the WG adoption= of the IDs I presented at Berlin. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization= and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standar= ds Track, and as minor updates to NHDP and OLSRv2, which we would like to pr= ogress as fast as possible. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd o= bvious have no problem with being adopted as a WG document, but it needs at l= east one more revision, which we intend to do as an author draft, so there i= sn't the same time pressure there. However of course we would like discussio= n any time from now. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> -- >>> >>>>>>>>>>>> Christopher Dearlove >>> >>>>>>>>>>>> Senior Principal Engineer, Communications Group >>> >>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>> >>>>>>>>>>>> BAE Systems Advanced Technology Centre >>> >>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, U= K >>> >>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> >>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> BAE Systems (Operations) Limited >>> >>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Ae= rospace Centre, Farnborough, Hants, GU14 6YU, UK >>> >>>>>>>>>>>> Registered in England & Wales No: 1996687 >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> ***********************************************************= ********* >>> >>>>>>>>>>>> This email and any attachments are confidential to the inte= nded >>> >>>>>>>>>>>> recipient and may also be privileged. If you are not the in= tended >>> >>>>>>>>>>>> recipient please delete it from your system and notify the s= ender. >>> >>>>>>>>>>>> You should not copy it or use it for any purpose nor disclo= se or >>> >>>>>>>>>>>> distribute its contents to any other person. >>> >>>>>>>>>>>> ***********************************************************= ********* >>> >>>>>>>>>>> >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> manet mailing list >>> >>>>>>>>>>> manet@ietf.org >>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>> >>>>>>>>>> >>> >>>>>>>>>> _______________________________________________ >>> >>>>>>>>>> manet mailing list >>> >>>>>>>>>> manet@ietf.org >>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>> >>>> >>> >> >>> >> _______________________________________________ >>> >> manet mailing list >>> >> manet@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/manet >>> > >>> > >>> > >>> > -- >>> > We began as wanderers, and we are wanderers still. We have lingered >>> > long enough on the shores of the cosmic ocean. We are ready at last to= >>> > set sail for the stars - Carl Sagan >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-26452C26-084F-4E86-8C52-7BA5D4E1073A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I should add that I have a *strict* im= plementation of OLSRv2, finished well before these I-Ds were as much as a tw= inkle in Chris' eyes, and conforming strictly to draft-ietf-manet-olsrv2 as c= urrently sitting with the RFC Editor.

While that im= plementation - of course - will not generate TLVs of the form described in T= LV-Extensions, it will happily process them and will do the right thing when= presented with such TLVs (i.e., already interprets fields as bit-vectors, p= rocess value field lengths "correctly", behave appropriately when seeing unk= nown values and not discard the message as a consequence hereof, etc.) Much t= he same as Justin describes for his implementations. 

For the Routing MPR optimization I-D, the same applies: no interoper= ability issues.

Such interoperability was, indeed, a= condition for me to join Chris in this (these) I-D, and something I verifie= d with my implementation in advance hereof: I actually wrote a small piece of test code that genera= tes OLSRv2 messages containing TLVs formatted according to the TLV-Extension= I-D, and feed them to my OLSRv2 implementation, just to be sure.

Justin: like Chris, I look forward to your - always ve= ry useful and constructive - detailed feedback and comments to the I-Ds.

Teco: I appreciate that you worry about "running code"= - that makes two of us (you know my position: running code is king, and pus= hing specs through without them is unacceptable). My conclusion is, based on= the above, that there are no interoperability issues between a "conformant"= implementation of OLSRv2 and a "conformat" implementation of OLSRv2 + TLV-E= xtensions and/or routing MPR optimization.

(Of cour= se, if someone shows up with a non-conformat implementation of a spec, then a= ll bets are off on interoperability - but the IETF can't really guard agains= t implementations not following the specs, other than to try to "limit the d= amage" ..... which I think that OLSRv2 does nicely).

Respectfu= lly,

Thomas

Sent from my iPad

On 30 ao=C3=BBt 2013, at 16:35, Justin Dean <bebemaster@gmail.com> wrote:

I support adoption of this= draft by the working group as it addresses a previously undefined behavior o= f the NHDP/OLSRv2 protocols.  I do have implementations and I don't see= any issues with this document.  I just so happened to make similar cho= ices in behavior, if I hadn't however the changes would be simple to impleme= nt and even if I didn't nothing would "break" as no new TLVs or values are i= ntroduced with this document.  Even protocols extended with future TLVs= (and values) which took advantage of the behaviors outlined in this documen= t wouldn't break anything in non-compliant protocols, they just wouldn't pla= y as nice together (which is the current case anyhow).

I do have issue with some of the language and found it overly diff= icult to understand what was being specified.  I'm willing to provide s= ome more concrete feedback in this regard later.

Justin


On Tue, A= ug 27, 2013 at 10:05 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
I don't see any issues w= ith the approach of the TLV extension draft. Like Chris said, it specifies a= behavior that was previously unspecified (and thus undefined).
On the procedural question, the IETF has introduced "updates RFCx= xxx" for a good reason, and I think this particular case is such a case.

=
Ulrich



On Tue, Aug 27, 2013 at 2:40 AM,= Dearlove, Christopher (UK) <chris.dearlove@baesystems.com&g= t; wrote:
I thought I'd replied to this, but can't see o= n list. I think your characterisation of this whole issue is wrong.

Currently, there is no specification what to do when seeing an unknown value= . This defines one. Of course with no specification, people can do anything (= including dropping the message). That's undesirable, let's fix it.

As for the sacrosanctness of the specification, let's be real. How many impl= ementations actually are there yet? Is there anyone with one who finds this o= ther than a positive thing?

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dea= rlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Fa= rnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Teco Boot [mailto:teco@inf-net.nl]
Sent: 17 August 2013 08:37
To: Henning Rogge
Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org List; Joe Macker (joseph.macker@nrl.navy= .mil); Thomas Heide Clausen (thomas@thomasclausen.org); Stan Ratliff (sratliff) Subject: Re: [manet] IDs presemted in Berlin

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Can I read this as:

1) an implementations that did not implement this new specification might dr= op these new messages and therefore is not compatible
2) an implementations that did not implement this new specification might ac= cept these new messages and therefore is compatible

"old" of "new" is not important. It is about stability of the standard. We h= ave to stop incremental changes that are not backwards compatible. Or step t= o new version or similar tag.

Teco

Op 16 aug. 2013, om 23:41 heeft Henning Rogge <hrogge@googlemail.com> het volgende g= eschreven:

> If I understand the draft right we have the following situations:
>
> 1) an "old" implementation should interop with a "new" one without any<= br> > extensions easily.
> 2) an "old" implementation might just drop messages from a "new"
> implementation which use an extension
>
> Henning Rogge
>
> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot <teco@inf-net.nl> wrote:
>> Yes.
>>
>> Teco
>>
>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove <christopher.dearlo= ve@gmail.com> het volgende geschreven:
>>
>>> Have you read the draft?
>>>
>>> --
>>> Christopher Dearlove
>>> christopher.dearlove@gmail.com (iPhone)
>>> chris@mnemosyne.demon.co.uk (home)
>>>
>>> On 16 Aug 2013, at 21:58, Teco Boot <teco@inf-net.nl> wrote:
>>>
>>>> I understand the change is documented.
>>>> My concerns are on what happens when different implementati= ons are in same network. This has to be documented. Asking on mailing list i= s not enough.
>>>>
>>>> Teco
>>>>
>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove <christophe= r.dearlove@gmail.com> het volgende geschreven:
>>>>
>>>>> I think you are quite wrong on the obsoleted point. Esp= ecially when we are talking changes to define what was previously undefined.= Nothing defined has changed. Which is just like the TOS change.
>>>>>
>>>>> But if you want to know what's changed, read the draft.=
>>>>>
>>>>> I'd be interested in hearing from people with implement= ations. If the bottom line is that there isn't anyone with an implementation= who has a problem, I think worries over a hypothetical unwritten implementa= tion are rather beside the point. Anyone coming to something new could alway= s check the "updated by" bit.
>>>>>
>>>>>
>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote:
>>>>>
>>>>>> If anyone in the future writes code that complies w= ith std track RFC, he/she may assume that it is compatible with any other im= plementation. If an update of that RFC will break compatibility, that RFC sh= all be obsoleted, I think.
>>>>>>
>>>>>> RFC 791 was 1981. Wording on TOS: "provides an indi= cation", "are to be used to guide", "may". Remapping to DSCP is highly backw= ards compatible.
>>>>>>
>>>>>> Did I say I'm against? I just want to know the issu= es / problems. At least they should be documented.
>>>>>>
>>>>>> Teco
>>>>>>
>>>>>>
>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlov= e <ch= ristopher.dearlove@gmail.com> het volgende geschreven:
>>>>>>
>>>>>>> You can read this that there are minor issues, w= hich I wouldn't elevate to the level of problems.
>>>>>>>
>>>>>>> Your comment on the inability to modify RFCs is= just plain wrong. Was RFC 791 obsoleted when the TOS bits function was chan= ged? No. Many more such examples could be given.
>>>>>>>
>>>>>>> I'm actually not aware of anyone with an implem= entation who doesn't support this. Just in case not obvious, that includes m= e.
>>>>>>>
>>>>>>> Does anyone with an implementation have an issu= e?
>>>>>>>
>>>>>>>
>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote:
>>>>>>>
>>>>>>>> May I read that there are problems?
>>>>>>>> If so, we cannot bring out a std track RFC f= ollowed up with something that can not interoperate with it. Or we mark the t= o_be RFC as obsolete. That's how it works.
>>>>>>>>
>>>>>>>> Teco
>>>>>>>>
>>>>>>>> PS1. you mentioned something about IESG and= correctness...
>>>>>>>> PS2: I understand the motivation. discussio= n could be how to deal with it.
>>>>>>>>
>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher= Dearlove <christopher.dearlove@gmail.com> het volgende geschreven:
>>>>>>>>
>>>>>>>>> I think my starting point with such a d= iscussion would be who has an implementation? Yes, there are possible minor i= ssues for implementations (though it's also possible for an implementation t= o need no changes at all). But the most pointless thing would be protecting (= in a minor way) hypothetical implementations while people actually with them= want this.
>>>>>>>>>
>>>>>>>>> (I'm not saying those with them have al= l said they want this. I'm asking.)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Christopher Dearlove
>>>>>>>>> christopher.dearlove@gmail.com (iPhone)
= >>>>>>>>> chris@mnemosyne.demon.co.uk (home)
>>>>>>>>>
>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot <= ;teco@inf-net.nl>= ; wrote:
>>>>>>>>>
>>>>>>>>>> Does draft-dearlove-manet-nhdp-olsr= v2-tlv-extension introduce problems in a network with and without routers th= at implement this?
>>>>>>>>>> If so, I think we need some discuss= ion first.
>>>>>>>>>>
>>>>>>>>>> Teco
>>>>>>>>>>
>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Sta= n Ratliff (sratliff) <sratliff@cisco.com> het volgende geschreven:
>>>>>>>>>>
>>>>>>>>>>> OK, so to the WG - do we have c= onsensus to adopt these documents as working group docs?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Stan
>>>>>>>>>>>
>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "D= earlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I don't believe that the ch= airs have raised the WG adoption of the IDs I presented at Berlin.
>>>>>>>>>>>>
>>>>>>>>>>>> Two of these, draft-dearlov= e-manet-olsrv2-rmpr-optimization and draft-dearlove-manet-nhdp-olsrv2-tlv-ex= tension are intended for Standards Track, and as minor updates to NHDP and O= LSRv2, which we would like to progress as fast as possible.
>>>>>>>>>>>>
>>>>>>>>>>>> The third, draft-dearlove-m= anet-olsrv2-multitopology, we'd obvious have no problem with being adopted a= s a WG document, but it needs at least one more revision, which we intend to= do as an author draft, so there isn't the same time pressure there. However= of course we would like discussion any time from now.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Christopher Dearlove
>>>>>>>>>>>> Senior Principal Engineer, C= ommunications Group
>>>>>>>>>>>> Communications, Networks an= d Image Analysis Capability
>>>>>>>>>>>> BAE Systems Advanced Techno= logy Centre
>>>>>>>>>>>> West Hanningfield Road, Gre= at Baddow, Chelmsford, CM2 8HN, UK
>>>>>>>>>>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>>>>>>>>>>>> chris.dearlove@baesystems.com | <= a href=3D"http://www.baesystems.com" target=3D"_blank">http://www.baesystems= .com
>>>>>>>>>>>>
>>>>>>>>>>>> BAE Systems (Operations) Li= mited
>>>>>>>>>>>> Registered Office: Warwick H= ouse, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU,= UK
>>>>>>>>>>>> Registered in England &= Wales No: 1996687
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ***************************= *****************************************
>>>>>>>>>>>> This email and any attachme= nts are confidential to the intended
>>>>>>>>>>>> recipient and may also be p= rivileged. If you are not the intended
>>>>>>>>>>>> recipient please delete it f= rom your system and notify the sender.
>>>>>>>>>>>> You should not copy it or u= se it for any purpose nor disclose or
>>>>>>>>>>>> distribute its contents to a= ny other person.
>>>>>>>>>>>> ***************************= *****************************************
>>>>>>>>>>>
>>>>>>>>>>> _______________________________= ________________
>>>>>>>>>>> manet mailing list
>>>>>>>>>>> manet@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/list= info/manet
>>>>>>>>>>
>>>>>>>>>> ___________________________________= ____________
>>>>>>>>>> manet mailing list
>>>>>>>>>> manet@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo= /manet
>>>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org<= /a>
>> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> --
> We began as wanderers, and we are wanderers still. We have lingered
= > long enough on the shores of the cosmic ocean. We are ready at last to<= br> > set sail for the stars - Carl Sagan


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-26452C26-084F-4E86-8C52-7BA5D4E1073A-- From hrogge@googlemail.com Fri Aug 30 09:41:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3567A21E80E8 for ; Fri, 30 Aug 2013 09:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqMOwV2g7quD for ; Fri, 30 Aug 2013 09:41:45 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6922321E805F for ; Fri, 30 Aug 2013 09:41:45 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id a11so1069726qen.25 for ; Fri, 30 Aug 2013 09:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=eBpV2NRRwZWSH2a5VQoxuG1Am51+bUX1t6sL06Xe3pE=; b=BkYN/HrB146wvJGy60/ebtaJiHvDPIiWsIEamZZSfLW4GV6pAgIhsZpUl0sKKzUrDF jERjR4z98Kj1nQ/viGzPnV9JweiPoELIuq/HI5teCzskNRu+zMHZAt5jCgjS0VSGG79n ovJNPyNXx5QJ4TeHbDlPUK5axPlKIb/8dt7NfGZFlHp6N887eTZ55cTtKnQ4oQIeZlOa 3I1/AeAh6LlIlVhMBDwMtQvZ/FXo9tFTXgWMWqa14IRt3SjQpXnwKOaEwkkKNkpMw9Sk qo9lsVP6D3COgicRt23KwULO6feVYb9WLP9bWLqIEOfCWriw6ISjD8U5i/7ulVSh/sik oq/A== X-Received: by 10.224.80.74 with SMTP id s10mr13217211qak.85.1377880903800; Fri, 30 Aug 2013 09:41:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.203.7 with HTTP; Fri, 30 Aug 2013 09:41:23 -0700 (PDT) In-Reply-To: <78817FC1-24B1-422B-A0EB-4147498BF2D3@thomasclausen.org> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> <78817FC1-24B1-422B-A0EB-4147498BF2D3@thomasclausen.org> From: Henning Rogge Date: Fri, 30 Aug 2013 18:41:23 +0200 Message-ID: To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:41:47 -0000 Hi, I am pretty sure (but have not tested it) the Olsr.org OLSRv2 implementation would also have no trouble with the "TLV extension" draft, as long as the currently unused bitfields are not used. In fact, I accidentally implemented parts of the extension because I used the value 255 as "no TLV found" for a few TLVs. The only think I can see that will happen is that a "non TLV extension" implementation will not interoperate with Chris planned Multitopology implementation, when it use the unused bitfields. Which is okay for me, it cannot process the Multitopology information anywa= ys. Henning Rogge On Fri, Aug 30, 2013 at 6:34 PM, Thomas Heide Clausen wrote: > I should add that I have a *strict* implementation of OLSRv2, finished we= ll > before these I-Ds were as much as a twinkle in Chris' eyes, and conformin= g > strictly to draft-ietf-manet-olsrv2 as currently sitting with the RFC > Editor. > > While that implementation - of course - will not generate TLVs of the for= m > described in TLV-Extensions, it will happily process them and will do the > right thing when presented with such TLVs (i.e., already interprets field= s > as bit-vectors, process value field lengths "correctly", behave > appropriately when seeing unknown values and not discard the message as a > consequence hereof, etc.) Much the same as Justin describes for his > implementations. > > For the Routing MPR optimization I-D, the same applies: no interoperabili= ty > issues. > > Such interoperability was, indeed, a condition for me to join Chris in th= is > (these) I-D, and something I verified with my implementation in advance > hereof: I actually wrote a small piece of test code that generates OLSRv2 > messages containing TLVs formatted according to the TLV-Extension I-D, an= d > feed them to my OLSRv2 implementation, just to be sure. > > Justin: like Chris, I look forward to your - always very useful and > constructive - detailed feedback and comments to the I-Ds. > > Teco: I appreciate that you worry about "running code" - that makes two o= f > us (you know my position: running code is king, and pushing specs through > without them is unacceptable). My conclusion is, based on the above, that > there are no interoperability issues between a "conformant" implementatio= n > of OLSRv2 and a "conformat" implementation of OLSRv2 + TLV-Extensions and= /or > routing MPR optimization. > > (Of course, if someone shows up with a non-conformat implementation of a > spec, then all bets are off on interoperability - but the IETF can't real= ly > guard against implementations not following the specs, other than to try = to > "limit the damage" ..... which I think that OLSRv2 does nicely). > > Respectfully, > > Thomas > > Sent from my iPad > > On 30 ao=FBt 2013, at 16:35, Justin Dean wrote: > > I support adoption of this draft by the working group as it addresses a > previously undefined behavior of the NHDP/OLSRv2 protocols. I do have > implementations and I don't see any issues with this document. I just so > happened to make similar choices in behavior, if I hadn't however the > changes would be simple to implement and even if I didn't nothing would > "break" as no new TLVs or values are introduced with this document. Even > protocols extended with future TLVs (and values) which took advantage of = the > behaviors outlined in this document wouldn't break anything in non-compli= ant > protocols, they just wouldn't play as nice together (which is the current > case anyhow). > > I do have issue with some of the language and found it overly difficult t= o > understand what was being specified. I'm willing to provide some more > concrete feedback in this regard later. > > Justin > > > On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg > wrote: >> >> I don't see any issues with the approach of the TLV extension draft. Lik= e >> Chris said, it specifies a behavior that was previously unspecified (and >> thus undefined). >> On the procedural question, the IETF has introduced "updates RFCxxxx" fo= r >> a good reason, and I think this particular case is such a case. >> >> Ulrich >> >> >> >> On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) >> wrote: >>> >>> I thought I'd replied to this, but can't see on list. I think your >>> characterisation of this whole issue is wrong. >>> >>> Currently, there is no specification what to do when seeing an unknown >>> value. This defines one. Of course with no specification, people can do >>> anything (including dropping the message). That's undesirable, let's fi= x it. >>> >>> As for the sacrosanctness of the specification, let's be real. How many >>> implementations actually are there yet? Is there anyone with one who fi= nds >>> this other than a positive thing? >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> >>> -----Original Message----- >>> From: Teco Boot [mailto:teco@inf-net.nl] >>> Sent: 17 August 2013 08:37 >>> To: Henning Rogge >>> Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org >>> List; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen >>> (thomas@thomasclausen.org); Stan Ratliff (sratliff) >>> Subject: Re: [manet] IDs presemted in Berlin >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>> Can I read this as: >>> >>> 1) an implementations that did not implement this new specification mig= ht >>> drop these new messages and therefore is not compatible >>> 2) an implementations that did not implement this new specification mig= ht >>> accept these new messages and therefore is compatible >>> >>> "old" of "new" is not important. It is about stability of the standard. >>> We have to stop incremental changes that are not backwards compatible. = Or >>> step to new version or similar tag. >>> >>> Teco >>> >>> Op 16 aug. 2013, om 23:41 heeft Henning Rogge h= et >>> volgende geschreven: >>> >>> > If I understand the draft right we have the following situations: >>> > >>> > 1) an "old" implementation should interop with a "new" one without an= y >>> > extensions easily. >>> > 2) an "old" implementation might just drop messages from a "new" >>> > implementation which use an extension >>> > >>> > Henning Rogge >>> > >>> > On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >>> >> Yes. >>> >> >>> >> Teco >>> >> >>> >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove >>> >> het volgende geschreven: >>> >> >>> >>> Have you read the draft? >>> >>> >>> >>> -- >>> >>> Christopher Dearlove >>> >>> christopher.dearlove@gmail.com (iPhone) >>> >>> chris@mnemosyne.demon.co.uk (home) >>> >>> >>> >>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>> >>> >>> >>>> I understand the change is documented. >>> >>>> My concerns are on what happens when different implementations are >>> >>>> in same network. This has to be documented. Asking on mailing list= is not >>> >>>> enough. >>> >>>> >>> >>>> Teco >>> >>>> >>> >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove >>> >>>> het volgende geschreven: >>> >>>> >>> >>>>> I think you are quite wrong on the obsoleted point. Especially wh= en >>> >>>>> we are talking changes to define what was previously undefined. N= othing >>> >>>>> defined has changed. Which is just like the TOS change. >>> >>>>> >>> >>>>> But if you want to know what's changed, read the draft. >>> >>>>> >>> >>>>> I'd be interested in hearing from people with implementations. If >>> >>>>> the bottom line is that there isn't anyone with an implementation= who has a >>> >>>>> problem, I think worries over a hypothetical unwritten implementa= tion are >>> >>>>> rather beside the point. Anyone coming to something new could alw= ays check >>> >>>>> the "updated by" bit. >>> >>>>> >>> >>>>> >>> >>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>> >>>>> >>> >>>>>> If anyone in the future writes code that complies with std track >>> >>>>>> RFC, he/she may assume that it is compatible with any other impl= ementation. >>> >>>>>> If an update of that RFC will break compatibility, that RFC shal= l be >>> >>>>>> obsoleted, I think. >>> >>>>>> >>> >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are >>> >>>>>> to be used to guide", "may". Remapping to DSCP is highly backwar= ds >>> >>>>>> compatible. >>> >>>>>> >>> >>>>>> Did I say I'm against? I just want to know the issues / problems= . >>> >>>>>> At least they should be documented. >>> >>>>>> >>> >>>>>> Teco >>> >>>>>> >>> >>>>>> >>> >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove >>> >>>>>> het volgende geschreven: >>> >>>>>> >>> >>>>>>> You can read this that there are minor issues, which I wouldn't >>> >>>>>>> elevate to the level of problems. >>> >>>>>>> >>> >>>>>>> Your comment on the inability to modify RFCs is just plain wron= g. >>> >>>>>>> Was RFC 791 obsoleted when the TOS bits function was changed? N= o. Many more >>> >>>>>>> such examples could be given. >>> >>>>>>> >>> >>>>>>> I'm actually not aware of anyone with an implementation who >>> >>>>>>> doesn't support this. Just in case not obvious, that includes m= e. >>> >>>>>>> >>> >>>>>>> Does anyone with an implementation have an issue? >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>> >>>>>>> >>> >>>>>>>> May I read that there are problems? >>> >>>>>>>> If so, we cannot bring out a std track RFC followed up with >>> >>>>>>>> something that can not interoperate with it. Or we mark the to= _be RFC as >>> >>>>>>>> obsolete. That's how it works. >>> >>>>>>>> >>> >>>>>>>> Teco >>> >>>>>>>> >>> >>>>>>>> PS1. you mentioned something about IESG and correctness... >>> >>>>>>>> PS2: I understand the motivation. discussion could be how to >>> >>>>>>>> deal with it. >>> >>>>>>>> >>> >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove >>> >>>>>>>> het volgende geschreven: >>> >>>>>>>> >>> >>>>>>>>> I think my starting point with such a discussion would be who >>> >>>>>>>>> has an implementation? Yes, there are possible minor issues f= or >>> >>>>>>>>> implementations (though it's also possible for an implementat= ion to need no >>> >>>>>>>>> changes at all). But the most pointless thing would be protec= ting (in a >>> >>>>>>>>> minor way) hypothetical implementations while people actually= with them want >>> >>>>>>>>> this. >>> >>>>>>>>> >>> >>>>>>>>> (I'm not saying those with them have all said they want this. >>> >>>>>>>>> I'm asking.) >>> >>>>>>>>> >>> >>>>>>>>> -- >>> >>>>>>>>> Christopher Dearlove >>> >>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>> >>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>> >>>>>>>>> >>> >>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>> >>>>>>>>> >>> >>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduc= e >>> >>>>>>>>>> problems in a network with and without routers that implemen= t this? >>> >>>>>>>>>> If so, I think we need some discussion first. >>> >>>>>>>>>> >>> >>>>>>>>>> Teco >>> >>>>>>>>>> >>> >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) >>> >>>>>>>>>> het volgende geschreven: >>> >>>>>>>>>> >>> >>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these >>> >>>>>>>>>>> documents as working group docs? >>> >>>>>>>>>>> >>> >>>>>>>>>>> Regards, >>> >>>>>>>>>>> Stan >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" >>> >>>>>>>>>>> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>>> I don't believe that the chairs have raised the WG adoptio= n >>> >>>>>>>>>>>> of the IDs I presented at Berlin. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimizatio= n >>> >>>>>>>>>>>> and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are int= ended for >>> >>>>>>>>>>>> Standards Track, and as minor updates to NHDP and OLSRv2, = which we would >>> >>>>>>>>>>>> like to progress as fast as possible. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd >>> >>>>>>>>>>>> obvious have no problem with being adopted as a WG documen= t, but it needs at >>> >>>>>>>>>>>> least one more revision, which we intend to do as an autho= r draft, so there >>> >>>>>>>>>>>> isn't the same time pressure there. However of course we w= ould like >>> >>>>>>>>>>>> discussion any time from now. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> -- >>> >>>>>>>>>>>> Christopher Dearlove >>> >>>>>>>>>>>> Senior Principal Engineer, Communications Group >>> >>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>> >>>>>>>>>>>> BAE Systems Advanced Technology Centre >>> >>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, >>> >>>>>>>>>>>> UK >>> >>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> >>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> BAE Systems (Operations) Limited >>> >>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough >>> >>>>>>>>>>>> Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>> >>>>>>>>>>>> Registered in England & Wales No: 1996687 >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> **********************************************************= ********** >>> >>>>>>>>>>>> This email and any attachments are confidential to the >>> >>>>>>>>>>>> intended >>> >>>>>>>>>>>> recipient and may also be privileged. If you are not the >>> >>>>>>>>>>>> intended >>> >>>>>>>>>>>> recipient please delete it from your system and notify the >>> >>>>>>>>>>>> sender. >>> >>>>>>>>>>>> You should not copy it or use it for any purpose nor >>> >>>>>>>>>>>> disclose or >>> >>>>>>>>>>>> distribute its contents to any other person. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> **********************************************************= ********** >>> >>>>>>>>>>> >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> manet mailing list >>> >>>>>>>>>>> manet@ietf.org >>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>> >>>>>>>>>> >>> >>>>>>>>>> _______________________________________________ >>> >>>>>>>>>> manet mailing list >>> >>>>>>>>>> manet@ietf.org >>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>> >>>> >>> >> >>> >> _______________________________________________ >>> >> manet mailing list >>> >> manet@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/manet >>> > >>> > >>> > >>> > -- >>> > We began as wanderers, and we are wanderers still. We have lingered >>> > long enough on the shores of the cosmic ocean. We are ready at last t= o >>> > set sail for the stars - Carl Sagan >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From ietf@thomasclausen.org Fri Aug 30 09:44:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8E821E80E8 for ; Fri, 30 Aug 2013 09:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW7xbHt6UaQT for ; Fri, 30 Aug 2013 09:44:45 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4BC21E805F for ; Fri, 30 Aug 2013 09:44:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 69816E1963; Fri, 30 Aug 2013 09:44:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.64.54.17] (unknown [37.161.227.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 141F6E1960; Fri, 30 Aug 2013 09:44:42 -0700 (PDT) References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> <78817FC1-24B1-422B-A0EB-4147498BF2D3@thomasclausen.org> Mime-Version: 1.0 (1.0) In-Reply-To: <78817FC1-24B1-422B-A0EB-4147498BF2D3@thomasclausen.org> Content-Type: multipart/alternative; boundary=Apple-Mail-EE835330-4E92-4606-8665-F980543D9A7E Content-Transfer-Encoding: 7bit Message-Id: <6ECA6146-1093-4978-A75A-BA4258C5CE26@thomasclausen.org> X-Mailer: iPad Mail (10B329) From: Thomas Heide Clausen Date: Fri, 30 Aug 2013 18:44:38 +0200 To: Justin Dean Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:44:49 -0000 --Apple-Mail-EE835330-4E92-4606-8665-F980543D9A7E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The nitpicker in me insists that I be more precise on one point: On 30 ao=C3=BBt 2013, at 18:34, Thomas Heide Clausen wrote: > I should add that I have a *strict* implementation of OLSRv2, finished wel= l before these I-Ds were as much as a twinkle in Chris' eyes, and conforming= strictly to draft-ietf-manet-olsrv2 as currently sitting with the RFC Edito= r. >=20 > While that implementation - of course - will not generate TLVs of the form= described in TLV-Extensions, it will happily process them and will do the r= ight thing when presented with such TLVs (i.e., already interprets fields as= bit-vectors, It, of course, doesn't "interpret fields as bit-vectors", but as numerical v= alues. However, as the bit-vectors are set up so that the numerical values t= hat OLSRv2 expects match with the bits set/cleared, it will "interpret the b= it-vectors as the expected values" and do the right thing. Thomas > process value field lengths "correctly", behave appropriately when seeing u= nknown values and not discard the message as a consequence hereof, etc.) Muc= h the same as Justin describes for his implementations.=20 >=20 > For the Routing MPR optimization I-D, the same applies: no interoperabilit= y issues. >=20 > Such interoperability was, indeed, a condition for me to join Chris in thi= s (these) I-D, and something I verified with my implementation in advance he= reof: I actually wrote a small piece of test code that generates OLSRv2 mess= ages containing TLVs formatted according to the TLV-Extension I-D, and feed t= hem to my OLSRv2 implementation, just to be sure. >=20 > Justin: like Chris, I look forward to your - always very useful and constr= uctive - detailed feedback and comments to the I-Ds. >=20 > Teco: I appreciate that you worry about "running code" - that makes two of= us (you know my position: running code is king, and pushing specs through w= ithout them is unacceptable). My conclusion is, based on the above, that the= re are no interoperability issues between a "conformant" implementation of O= LSRv2 and a "conformat" implementation of OLSRv2 + TLV-Extensions and/or rou= ting MPR optimization. >=20 > (Of course, if someone shows up with a non-conformat implementation of a s= pec, then all bets are off on interoperability - but the IETF can't really g= uard against implementations not following the specs, other than to try to "= limit the damage" ..... which I think that OLSRv2 does nicely). >=20 > Respectfully, >=20 > Thomas >=20 > Sent from my iPad >=20 > On 30 ao=C3=BBt 2013, at 16:35, Justin Dean wrote: >=20 >> I support adoption of this draft by the working group as it addresses a p= reviously undefined behavior of the NHDP/OLSRv2 protocols. I do have implem= entations and I don't see any issues with this document. I just so happened= to make similar choices in behavior, if I hadn't however the changes would b= e simple to implement and even if I didn't nothing would "break" as no new T= LVs or values are introduced with this document. Even protocols extended wi= th future TLVs (and values) which took advantage of the behaviors outlined i= n this document wouldn't break anything in non-compliant protocols, they jus= t wouldn't play as nice together (which is the current case anyhow). >>=20 >> I do have issue with some of the language and found it overly difficult t= o understand what was being specified. I'm willing to provide some more con= crete feedback in this regard later. >>=20 >> Justin >>=20 >>=20 >> On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg wr= ote: >>> I don't see any issues with the approach of the TLV extension draft. Lik= e Chris said, it specifies a behavior that was previously unspecified (and t= hus undefined). >>> On the procedural question, the IETF has introduced "updates RFCxxxx" fo= r a good reason, and I think this particular case is such a case. >>>=20 >>> Ulrich >>>=20 >>>=20 >>>=20 >>> On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) wrote: >>>> I thought I'd replied to this, but can't see on list. I think your char= acterisation of this whole issue is wrong. >>>>=20 >>>> Currently, there is no specification what to do when seeing an unknown v= alue. This defines one. Of course with no specification, people can do anyth= ing (including dropping the message). That's undesirable, let's fix it. >>>>=20 >>>> As for the sacrosanctness of the specification, let's be real. How many= implementations actually are there yet? Is there anyone with one who finds t= his other than a positive thing? >>>>=20 >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>> Sent: 17 August 2013 08:37 >>>> To: Henning Rogge >>>> Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org Li= st; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen (thomas@th= omasclausen.org); Stan Ratliff (sratliff) >>>> Subject: Re: [manet] IDs presemted in Berlin >>>>=20 >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> Can I read this as: >>>>=20 >>>> 1) an implementations that did not implement this new specification mig= ht drop these new messages and therefore is not compatible >>>> 2) an implementations that did not implement this new specification mig= ht accept these new messages and therefore is compatible >>>>=20 >>>> "old" of "new" is not important. It is about stability of the standard.= We have to stop incremental changes that are not backwards compatible. Or s= tep to new version or similar tag. >>>>=20 >>>> Teco >>>>=20 >>>> Op 16 aug. 2013, om 23:41 heeft Henning Rogge h= et volgende geschreven: >>>>=20 >>>> > If I understand the draft right we have the following situations: >>>> > >>>> > 1) an "old" implementation should interop with a "new" one without an= y >>>> > extensions easily. >>>> > 2) an "old" implementation might just drop messages from a "new" >>>> > implementation which use an extension >>>> > >>>> > Henning Rogge >>>> > >>>> > On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >>>> >> Yes. >>>> >> >>>> >> Teco >>>> >> >>>> >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove het volgende geschreven: >>>> >> >>>> >>> Have you read the draft? >>>> >>> >>>> >>> -- >>>> >>> Christopher Dearlove >>>> >>> christopher.dearlove@gmail.com (iPhone) >>>> >>> chris@mnemosyne.demon.co.uk (home) >>>> >>> >>>> >>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>>> >>> >>>> >>>> I understand the change is documented. >>>> >>>> My concerns are on what happens when different implementations are= in same network. This has to be documented. Asking on mailing list is not e= nough. >>>> >>>> >>>> >>>> Teco >>>> >>>> >>>> >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove het volgende geschreven: >>>> >>>> >>>> >>>>> I think you are quite wrong on the obsoleted point. Especially wh= en we are talking changes to define what was previously undefined. Nothing d= efined has changed. Which is just like the TOS change. >>>> >>>>> >>>> >>>>> But if you want to know what's changed, read the draft. >>>> >>>>> >>>> >>>>> I'd be interested in hearing from people with implementations. If= the bottom line is that there isn't anyone with an implementation who has a= problem, I think worries over a hypothetical unwritten implementation are r= ather beside the point. Anyone coming to something new could always check th= e "updated by" bit. >>>> >>>>> >>>> >>>>> >>>> >>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>> >>>>> >>>> >>>>>> If anyone in the future writes code that complies with std track= RFC, he/she may assume that it is compatible with any other implementation.= If an update of that RFC will break compatibility, that RFC shall be obsole= ted, I think. >>>> >>>>>> >>>> >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are= to be used to guide", "may". Remapping to DSCP is highly backwards compatib= le. >>>> >>>>>> >>>> >>>>>> Did I say I'm against? I just want to know the issues / problems= . At least they should be documented. >>>> >>>>>> >>>> >>>>>> Teco >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove het volgende geschreven: >>>> >>>>>> >>>> >>>>>>> You can read this that there are minor issues, which I wouldn't= elevate to the level of problems. >>>> >>>>>>> >>>> >>>>>>> Your comment on the inability to modify RFCs is just plain wron= g. Was RFC 791 obsoleted when the TOS bits function was changed? No. Many mo= re such examples could be given. >>>> >>>>>>> >>>> >>>>>>> I'm actually not aware of anyone with an implementation who doe= sn't support this. Just in case not obvious, that includes me. >>>> >>>>>>> >>>> >>>>>>> Does anyone with an implementation have an issue? >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>> >>>>>>> >>>> >>>>>>>> May I read that there are problems? >>>> >>>>>>>> If so, we cannot bring out a std track RFC followed up with so= mething that can not interoperate with it. Or we mark the to_be RFC as obsol= ete. That's how it works. >>>> >>>>>>>> >>>> >>>>>>>> Teco >>>> >>>>>>>> >>>> >>>>>>>> PS1. you mentioned something about IESG and correctness... >>>> >>>>>>>> PS2: I understand the motivation. discussion could be how to d= eal with it. >>>> >>>>>>>> >>>> >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove het volgende geschreven: >>>> >>>>>>>> >>>> >>>>>>>>> I think my starting point with such a discussion would be who= has an implementation? Yes, there are possible minor issues for implementat= ions (though it's also possible for an implementation to need no changes at a= ll). But the most pointless thing would be protecting (in a minor way) hypot= hetical implementations while people actually with them want this. >>>> >>>>>>>>> >>>> >>>>>>>>> (I'm not saying those with them have all said they want this.= I'm asking.) >>>> >>>>>>>>> >>>> >>>>>>>>> -- >>>> >>>>>>>>> Christopher Dearlove >>>> >>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>> >>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>> >>>>>>>>> >>>> >>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>> >>>>>>>>> >>>> >>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduc= e problems in a network with and without routers that implement this? >>>> >>>>>>>>>> If so, I think we need some discussion first. >>>> >>>>>>>>>> >>>> >>>>>>>>>> Teco >>>> >>>>>>>>>> >>>> >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) het volgende geschreven: >>>> >>>>>>>>>> >>>> >>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these docu= ments as working group docs? >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Regards, >>>> >>>>>>>>>>> Stan >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" <= chris.dearlove@baesystems.com> wrote: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>>> I don't believe that the chairs have raised the WG adoptio= n of the IDs I presented at Berlin. >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimizatio= n and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standa= rds Track, and as minor updates to NHDP and OLSRv2, which we would like to p= rogress as fast as possible. >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd= obvious have no problem with being adopted as a WG document, but it needs a= t least one more revision, which we intend to do as an author draft, so ther= e isn't the same time pressure there. However of course we would like discus= sion any time from now. >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> -- >>>> >>>>>>>>>>>> Christopher Dearlove >>>> >>>>>>>>>>>> Senior Principal Engineer, Communications Group >>>> >>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>> >>>>>>>>>>>> BAE Systems Advanced Technology Centre >>>> >>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,= UK >>>> >>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> >>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> BAE Systems (Operations) Limited >>>> >>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough A= erospace Centre, Farnborough, Hants, GU14 6YU, UK >>>> >>>>>>>>>>>> Registered in England & Wales No: 1996687 >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> **********************************************************= ********** >>>> >>>>>>>>>>>> This email and any attachments are confidential to the int= ended >>>> >>>>>>>>>>>> recipient and may also be privileged. If you are not the i= ntended >>>> >>>>>>>>>>>> recipient please delete it from your system and notify the= sender. >>>> >>>>>>>>>>>> You should not copy it or use it for any purpose nor discl= ose or >>>> >>>>>>>>>>>> distribute its contents to any other person. >>>> >>>>>>>>>>>> **********************************************************= ********** >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> _______________________________________________ >>>> >>>>>>>>>>> manet mailing list >>>> >>>>>>>>>>> manet@ietf.org >>>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>>>>>>>> >>>> >>>>>>>>>> _______________________________________________ >>>> >>>>>>>>>> manet mailing list >>>> >>>>>>>>>> manet@ietf.org >>>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>>> >> >>>> >> _______________________________________________ >>>> >> manet mailing list >>>> >> manet@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/manet >>>> > >>>> > >>>> > >>>> > -- >>>> > We began as wanderers, and we are wanderers still. We have lingered >>>> > long enough on the shores of the cosmic ocean. We are ready at last t= o >>>> > set sail for the stars - Carl Sagan >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-EE835330-4E92-4606-8665-F980543D9A7E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The nitpicker in me insists that I be m= ore precise on one point:

On 30 ao=C3=BBt 2013, at 1= 8:34, Thomas Heide Clausen <iet= f@thomasclausen.org> wrote:

=
I should add that I have a *strict* implementation of OLSRv2, finished w= ell before these I-Ds were as much as a twinkle in Chris' eyes, and conformi= ng strictly to draft-ietf-manet-olsrv2 as currently sitting with the RFC Edi= tor.

While that implementation - of course - will n= ot generate TLVs of the form described in TLV-Extensions, it will happily pr= ocess them and will do the right thing when presented with such TLVs (i.e., a= lready interprets fields as bit-vectors,

It, of course, doesn't "interpret fields as bit-vectors", but as numeric= al values. However, as the bit-vectors are set up so that the numerical valu= es that OLSRv2 expects match with the bits set/cleared, it will "interpret t= he bit-vectors as the expected values" and do the right thing.

Thomas

process value f= ield lengths "correctly", behave appropriately when seeing unknown values an= d not discard the message as a consequence hereof, etc.) Much the same as Ju= stin describes for his implementations. 

For t= he Routing MPR optimization I-D, the same applies: no interoperability issue= s.

Such interoperability was, indeed, a condition f= or me to join Chris in this (these) I-D, and something I verified with my im= plementation in advance hereof: I actually wrote a small piece of test code that generates OLSRv2 m= essages containing TLVs formatted according to the TLV-Extension I-D, and fe= ed them to my OLSRv2 implementation, just to be sure.

<= /div>
Justin: like Chris, I look forward to your - always very useful an= d constructive - detailed feedback and comments to the I-Ds.

<= /div>
Teco: I appreciate that you worry about "running code" - that make= s two of us (you know my position: running code is king, and pushing specs t= hrough without them is unacceptable). My conclusion is, based on the above, t= hat there are no interoperability issues between a "conformant" implementati= on of OLSRv2 and a "conformat" implementation of OLSRv2 + TLV-Extensions and= /or routing MPR optimization.

(Of course, if someon= e shows up with a non-conformat implementation of a spec, then all bets are o= ff on interoperability - but the IETF can't really guard against implementat= ions not following the specs, other than to try to "limit the damage" ..... w= hich I think that OLSRv2 does nicely).

Respectfully,

Thomas

Sent from my iPad

On 30 a= o=C3=BBt 2013, at 16:35, Justin Dean <bebemaster@gmail.com> wrote:

I support adoption of this draft by the w= orking group as it addresses a previously undefined behavior of the NHDP/OLS= Rv2 protocols.  I do have implementations and I don't see any issues wi= th this document.  I just so happened to make similar choices in behavi= or, if I hadn't however the changes would be simple to implement and even if= I didn't nothing would "break" as no new TLVs or values are introduced with= this document.  Even protocols extended with future TLVs (and values) w= hich took advantage of the behaviors outlined in this document wouldn't brea= k anything in non-compliant protocols, they just wouldn't play as nice toget= her (which is the current case anyhow).

I do have issue with some of the language and found it overly diff= icult to understand what was being specified.  I'm willing to provide s= ome more concrete feedback in this regard later.

Justin


On Tue, A= ug 27, 2013 at 10:05 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
I don't see any issues w= ith the approach of the TLV extension draft. Like Chris said, it specifies a= behavior that was previously unspecified (and thus undefined).
On the procedural question, the IETF has introduced "updates RFCx= xxx" for a good reason, and I think this particular case is such a case.

=
Ulrich



On Tue, Aug 27, 2013 at 2:40 AM,= Dearlove, Christopher (UK) <chris.dearlove@baesystems.com&g= t; wrote:
I thought I'd replied to this, but can't see o= n list. I think your characterisation of this whole issue is wrong.

Currently, there is no specification what to do when seeing an unknown value= . This defines one. Of course with no specification, people can do anything (= including dropping the message). That's undesirable, let's fix it.

As for the sacrosanctness of the specification, let's be real. How many impl= ementations actually are there yet? Is there anyone with one who finds this o= ther than a positive thing?

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dea= rlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Fa= rnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Teco Boot [mailto:teco@inf-net.nl]
Sent: 17 August 2013 08:37
To: Henning Rogge
Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org List; Joe Macker (joseph.macker@nrl.navy= .mil); Thomas Heide Clausen (thomas@thomasclausen.org); Stan Ratliff (sratliff) Subject: Re: [manet] IDs presemted in Berlin

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Can I read this as:

1) an implementations that did not implement this new specification might dr= op these new messages and therefore is not compatible
2) an implementations that did not implement this new specification might ac= cept these new messages and therefore is compatible

"old" of "new" is not important. It is about stability of the standard. We h= ave to stop incremental changes that are not backwards compatible. Or step t= o new version or similar tag.

Teco

Op 16 aug. 2013, om 23:41 heeft Henning Rogge <hrogge@googlemail.com> het volgende g= eschreven:

> If I understand the draft right we have the following situations:
>
> 1) an "old" implementation should interop with a "new" one without any<= br> > extensions easily.
> 2) an "old" implementation might just drop messages from a "new"
> implementation which use an extension
>
> Henning Rogge
>
> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot <teco@inf-net.nl> wrote:
>> Yes.
>>
>> Teco
>>
>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove <christopher.dearlo= ve@gmail.com> het volgende geschreven:
>>
>>> Have you read the draft?
>>>
>>> --
>>> Christopher Dearlove
>>> christopher.dearlove@gmail.com (iPhone)
>>> chris@mnemosyne.demon.co.uk (home)
>>>
>>> On 16 Aug 2013, at 21:58, Teco Boot <teco@inf-net.nl> wrote:
>>>
>>>> I understand the change is documented.
>>>> My concerns are on what happens when different implementati= ons are in same network. This has to be documented. Asking on mailing list i= s not enough.
>>>>
>>>> Teco
>>>>
>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove <christophe= r.dearlove@gmail.com> het volgende geschreven:
>>>>
>>>>> I think you are quite wrong on the obsoleted point. Esp= ecially when we are talking changes to define what was previously undefined.= Nothing defined has changed. Which is just like the TOS change.
>>>>>
>>>>> But if you want to know what's changed, read the draft.=
>>>>>
>>>>> I'd be interested in hearing from people with implement= ations. If the bottom line is that there isn't anyone with an implementation= who has a problem, I think worries over a hypothetical unwritten implementa= tion are rather beside the point. Anyone coming to something new could alway= s check the "updated by" bit.
>>>>>
>>>>>
>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote:
>>>>>
>>>>>> If anyone in the future writes code that complies w= ith std track RFC, he/she may assume that it is compatible with any other im= plementation. If an update of that RFC will break compatibility, that RFC sh= all be obsoleted, I think.
>>>>>>
>>>>>> RFC 791 was 1981. Wording on TOS: "provides an indi= cation", "are to be used to guide", "may". Remapping to DSCP is highly backw= ards compatible.
>>>>>>
>>>>>> Did I say I'm against? I just want to know the issu= es / problems. At least they should be documented.
>>>>>>
>>>>>> Teco
>>>>>>
>>>>>>
>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlov= e <ch= ristopher.dearlove@gmail.com> het volgende geschreven:
>>>>>>
>>>>>>> You can read this that there are minor issues, w= hich I wouldn't elevate to the level of problems.
>>>>>>>
>>>>>>> Your comment on the inability to modify RFCs is= just plain wrong. Was RFC 791 obsoleted when the TOS bits function was chan= ged? No. Many more such examples could be given.
>>>>>>>
>>>>>>> I'm actually not aware of anyone with an implem= entation who doesn't support this. Just in case not obvious, that includes m= e.
>>>>>>>
>>>>>>> Does anyone with an implementation have an issu= e?
>>>>>>>
>>>>>>>
>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote:
>>>>>>>
>>>>>>>> May I read that there are problems?
>>>>>>>> If so, we cannot bring out a std track RFC f= ollowed up with something that can not interoperate with it. Or we mark the t= o_be RFC as obsolete. That's how it works.
>>>>>>>>
>>>>>>>> Teco
>>>>>>>>
>>>>>>>> PS1. you mentioned something about IESG and= correctness...
>>>>>>>> PS2: I understand the motivation. discussio= n could be how to deal with it.
>>>>>>>>
>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher= Dearlove <christopher.dearlove@gmail.com> het volgende geschreven:
>>>>>>>>
>>>>>>>>> I think my starting point with such a d= iscussion would be who has an implementation? Yes, there are possible minor i= ssues for implementations (though it's also possible for an implementation t= o need no changes at all). But the most pointless thing would be protecting (= in a minor way) hypothetical implementations while people actually with them= want this.
>>>>>>>>>
>>>>>>>>> (I'm not saying those with them have al= l said they want this. I'm asking.)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Christopher Dearlove
>>>>>>>>> christopher.dearlove@gmail.com (iPhone)
= >>>>>>>>> chris@mnemosyne.demon.co.uk (home)
>>>>>>>>>
>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot <= ;teco@inf-net.nl>= ; wrote:
>>>>>>>>>
>>>>>>>>>> Does draft-dearlove-manet-nhdp-olsr= v2-tlv-extension introduce problems in a network with and without routers th= at implement this?
>>>>>>>>>> If so, I think we need some discuss= ion first.
>>>>>>>>>>
>>>>>>>>>> Teco
>>>>>>>>>>
>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Sta= n Ratliff (sratliff) <sratliff@cisco.com> het volgende geschreven:
>>>>>>>>>>
>>>>>>>>>>> OK, so to the WG - do we have c= onsensus to adopt these documents as working group docs?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Stan
>>>>>>>>>>>
>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "D= earlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I don't believe that the ch= airs have raised the WG adoption of the IDs I presented at Berlin.
>>>>>>>>>>>>
>>>>>>>>>>>> Two of these, draft-dearlov= e-manet-olsrv2-rmpr-optimization and draft-dearlove-manet-nhdp-olsrv2-tlv-ex= tension are intended for Standards Track, and as minor updates to NHDP and O= LSRv2, which we would like to progress as fast as possible.
>>>>>>>>>>>>
>>>>>>>>>>>> The third, draft-dearlove-m= anet-olsrv2-multitopology, we'd obvious have no problem with being adopted a= s a WG document, but it needs at least one more revision, which we intend to= do as an author draft, so there isn't the same time pressure there. However= of course we would like discussion any time from now.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Christopher Dearlove
>>>>>>>>>>>> Senior Principal Engineer, C= ommunications Group
>>>>>>>>>>>> Communications, Networks an= d Image Analysis Capability
>>>>>>>>>>>> BAE Systems Advanced Techno= logy Centre
>>>>>>>>>>>> West Hanningfield Road, Gre= at Baddow, Chelmsford, CM2 8HN, UK
>>>>>>>>>>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>>>>>>>>>>>> chris.dearlove@baesystems.com | <= a href=3D"http://www.baesystems.com" target=3D"_blank">http://www.baesystems= .com
>>>>>>>>>>>>
>>>>>>>>>>>> BAE Systems (Operations) Li= mited
>>>>>>>>>>>> Registered Office: Warwick H= ouse, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU,= UK
>>>>>>>>>>>> Registered in England &= Wales No: 1996687
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ***************************= *****************************************
>>>>>>>>>>>> This email and any attachme= nts are confidential to the intended
>>>>>>>>>>>> recipient and may also be p= rivileged. If you are not the intended
>>>>>>>>>>>> recipient please delete it f= rom your system and notify the sender.
>>>>>>>>>>>> You should not copy it or u= se it for any purpose nor disclose or
>>>>>>>>>>>> distribute its contents to a= ny other person.
>>>>>>>>>>>> ***************************= *****************************************
>>>>>>>>>>>
>>>>>>>>>>> _______________________________= ________________
>>>>>>>>>>> manet mailing list
>>>>>>>>>>> manet@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/list= info/manet
>>>>>>>>>>
>>>>>>>>>> ___________________________________= ____________
>>>>>>>>>> manet mailing list
>>>>>>>>>> manet@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo= /manet
>>>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org<= /a>
>> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> --
> We began as wanderers, and we are wanderers still. We have lingered
= > long enough on the shores of the cosmic ocean. We are ready at last to<= br> > set sail for the stars - Carl Sagan


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-EE835330-4E92-4606-8665-F980543D9A7E-- From sratliff@cisco.com Fri Aug 30 09:52:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144AF21E808F for ; Fri, 30 Aug 2013 09:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.269 X-Spam-Level: X-Spam-Status: No, score=-10.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEWIgKZfA0CQ for ; Fri, 30 Aug 2013 09:51:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2B821E805F for ; Fri, 30 Aug 2013 09:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18076; q=dns/txt; s=iport; t=1377881512; x=1379091112; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ski40yTFhzTLnJ4But1xzV3ZLMdBNhwxGfW8W7ONEEc=; b=i+6ZP664aoNVt6oIeez7VAZG29AzMo3jHsi5+FWTljePX3DfnFg8KhWU SrX+/ZRq9I9kuelE3hwgwYJG6tWPJNqS3V3LNwaMgkDhpT2eK4DT3IEbl TyPC+XoVucXkdawIRaP9bArExoNz7SGeFReJOCT8RhzV3n/F5gfqo9ULS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAI3MIFKtJV2a/2dsb2JhbABagwc1UcBQgR4WdIIkAQEBAwEBAQEaOBkDCAUHBAIBCA4DBAEBAQodByEGCxQJCAIEDgUIh2cDCQYMsBQNiVyNBYEmCgENfgIsBQcGgxaBAAOIfI0OgxiLCIUvgyCBaAEIFyI X-IronPort-AV: E=Sophos;i="4.89,992,1367971200"; d="scan'208";a="253779309" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 30 Aug 2013 16:51:51 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7UGppMq018844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Aug 2013 16:51:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.187]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 30 Aug 2013 11:51:50 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] IDs presemted in Berlin Thread-Index: AQHOo5Md3se/1MLIS0GTdRoITUFK2pmuKPsAgAAhTACAAAHqgIAAAusA Date: Fri, 30 Aug 2013 16:51:13 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1149F906@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> <78817FC1-24B1-422B-A0EB-4147498BF2D3@thomasclausen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2E5997D684C7AF4CB705234A03F551CA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org List" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:52:00 -0000 OK, so with the emails from Henning and Thomas, it looks like the issue of = interoperability has been covered. And again, the request was simply for ad= opting these documents as working group documents - not for ratification.=20 My vote is to accept all three as WG documents. Consider this email as "las= t call for opposition"... Regards, Stan On Aug 30, 2013, at 12:41 PM, Henning Rogge wrote: > Hi, >=20 > I am pretty sure (but have not tested it) the Olsr.org OLSRv2 > implementation would also have no trouble with the "TLV extension" > draft, as long as the currently unused bitfields are not used. In > fact, I accidentally implemented parts of the extension because I used > the value 255 as "no TLV found" for a few TLVs. >=20 > The only think I can see that will happen is that a "non TLV > extension" implementation will not interoperate with Chris planned > Multitopology implementation, when it use the unused bitfields. >=20 > Which is okay for me, it cannot process the Multitopology information any= ways. >=20 > Henning Rogge >=20 > On Fri, Aug 30, 2013 at 6:34 PM, Thomas Heide Clausen > wrote: >> I should add that I have a *strict* implementation of OLSRv2, finished w= ell >> before these I-Ds were as much as a twinkle in Chris' eyes, and conformi= ng >> strictly to draft-ietf-manet-olsrv2 as currently sitting with the RFC >> Editor. >>=20 >> While that implementation - of course - will not generate TLVs of the fo= rm >> described in TLV-Extensions, it will happily process them and will do th= e >> right thing when presented with such TLVs (i.e., already interprets fiel= ds >> as bit-vectors, process value field lengths "correctly", behave >> appropriately when seeing unknown values and not discard the message as = a >> consequence hereof, etc.) Much the same as Justin describes for his >> implementations. >>=20 >> For the Routing MPR optimization I-D, the same applies: no interoperabil= ity >> issues. >>=20 >> Such interoperability was, indeed, a condition for me to join Chris in t= his >> (these) I-D, and something I verified with my implementation in advance >> hereof: I actually wrote a small piece of test code that generates OLSRv= 2 >> messages containing TLVs formatted according to the TLV-Extension I-D, a= nd >> feed them to my OLSRv2 implementation, just to be sure. >>=20 >> Justin: like Chris, I look forward to your - always very useful and >> constructive - detailed feedback and comments to the I-Ds. >>=20 >> Teco: I appreciate that you worry about "running code" - that makes two = of >> us (you know my position: running code is king, and pushing specs throug= h >> without them is unacceptable). My conclusion is, based on the above, tha= t >> there are no interoperability issues between a "conformant" implementati= on >> of OLSRv2 and a "conformat" implementation of OLSRv2 + TLV-Extensions an= d/or >> routing MPR optimization. >>=20 >> (Of course, if someone shows up with a non-conformat implementation of a >> spec, then all bets are off on interoperability - but the IETF can't rea= lly >> guard against implementations not following the specs, other than to try= to >> "limit the damage" ..... which I think that OLSRv2 does nicely). >>=20 >> Respectfully, >>=20 >> Thomas >>=20 >> Sent from my iPad >>=20 >> On 30 ao=FBt 2013, at 16:35, Justin Dean wrote: >>=20 >> I support adoption of this draft by the working group as it addresses a >> previously undefined behavior of the NHDP/OLSRv2 protocols. I do have >> implementations and I don't see any issues with this document. I just s= o >> happened to make similar choices in behavior, if I hadn't however the >> changes would be simple to implement and even if I didn't nothing would >> "break" as no new TLVs or values are introduced with this document. Eve= n >> protocols extended with future TLVs (and values) which took advantage of= the >> behaviors outlined in this document wouldn't break anything in non-compl= iant >> protocols, they just wouldn't play as nice together (which is the curren= t >> case anyhow). >>=20 >> I do have issue with some of the language and found it overly difficult = to >> understand what was being specified. I'm willing to provide some more >> concrete feedback in this regard later. >>=20 >> Justin >>=20 >>=20 >> On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg >> wrote: >>>=20 >>> I don't see any issues with the approach of the TLV extension draft. Li= ke >>> Chris said, it specifies a behavior that was previously unspecified (an= d >>> thus undefined). >>> On the procedural question, the IETF has introduced "updates RFCxxxx" f= or >>> a good reason, and I think this particular case is such a case. >>>=20 >>> Ulrich >>>=20 >>>=20 >>>=20 >>> On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) >>> wrote: >>>>=20 >>>> I thought I'd replied to this, but can't see on list. I think your >>>> characterisation of this whole issue is wrong. >>>>=20 >>>> Currently, there is no specification what to do when seeing an unknown >>>> value. This defines one. Of course with no specification, people can d= o >>>> anything (including dropping the message). That's undesirable, let's f= ix it. >>>>=20 >>>> As for the sacrosanctness of the specification, let's be real. How man= y >>>> implementations actually are there yet? Is there anyone with one who f= inds >>>> this other than a positive thing? >>>>=20 >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>> Sent: 17 August 2013 08:37 >>>> To: Henning Rogge >>>> Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org >>>> List; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen >>>> (thomas@thomasclausen.org); Stan Ratliff (sratliff) >>>> Subject: Re: [manet] IDs presemted in Berlin >>>>=20 >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> Can I read this as: >>>>=20 >>>> 1) an implementations that did not implement this new specification mi= ght >>>> drop these new messages and therefore is not compatible >>>> 2) an implementations that did not implement this new specification mi= ght >>>> accept these new messages and therefore is compatible >>>>=20 >>>> "old" of "new" is not important. It is about stability of the standard= . >>>> We have to stop incremental changes that are not backwards compatible.= Or >>>> step to new version or similar tag. >>>>=20 >>>> Teco >>>>=20 >>>> Op 16 aug. 2013, om 23:41 heeft Henning Rogge = het >>>> volgende geschreven: >>>>=20 >>>>> If I understand the draft right we have the following situations: >>>>>=20 >>>>> 1) an "old" implementation should interop with a "new" one without an= y >>>>> extensions easily. >>>>> 2) an "old" implementation might just drop messages from a "new" >>>>> implementation which use an extension >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote: >>>>>> Yes. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove >>>>>> het volgende geschreven: >>>>>>=20 >>>>>>> Have you read the draft? >>>>>>>=20 >>>>>>> -- >>>>>>> Christopher Dearlove >>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>=20 >>>>>>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>>>>>>=20 >>>>>>>> I understand the change is documented. >>>>>>>> My concerns are on what happens when different implementations are >>>>>>>> in same network. This has to be documented. Asking on mailing list= is not >>>>>>>> enough. >>>>>>>>=20 >>>>>>>> Teco >>>>>>>>=20 >>>>>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove >>>>>>>> het volgende geschreven: >>>>>>>>=20 >>>>>>>>> I think you are quite wrong on the obsoleted point. Especially wh= en >>>>>>>>> we are talking changes to define what was previously undefined. N= othing >>>>>>>>> defined has changed. Which is just like the TOS change. >>>>>>>>>=20 >>>>>>>>> But if you want to know what's changed, read the draft. >>>>>>>>>=20 >>>>>>>>> I'd be interested in hearing from people with implementations. If >>>>>>>>> the bottom line is that there isn't anyone with an implementation= who has a >>>>>>>>> problem, I think worries over a hypothetical unwritten implementa= tion are >>>>>>>>> rather beside the point. Anyone coming to something new could alw= ays check >>>>>>>>> the "updated by" bit. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>>>>>>>=20 >>>>>>>>>> If anyone in the future writes code that complies with std track >>>>>>>>>> RFC, he/she may assume that it is compatible with any other impl= ementation. >>>>>>>>>> If an update of that RFC will break compatibility, that RFC shal= l be >>>>>>>>>> obsoleted, I think. >>>>>>>>>>=20 >>>>>>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are >>>>>>>>>> to be used to guide", "may". Remapping to DSCP is highly backwar= ds >>>>>>>>>> compatible. >>>>>>>>>>=20 >>>>>>>>>> Did I say I'm against? I just want to know the issues / problems= . >>>>>>>>>> At least they should be documented. >>>>>>>>>>=20 >>>>>>>>>> Teco >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove >>>>>>>>>> het volgende geschreven: >>>>>>>>>>=20 >>>>>>>>>>> You can read this that there are minor issues, which I wouldn't >>>>>>>>>>> elevate to the level of problems. >>>>>>>>>>>=20 >>>>>>>>>>> Your comment on the inability to modify RFCs is just plain wron= g. >>>>>>>>>>> Was RFC 791 obsoleted when the TOS bits function was changed? N= o. Many more >>>>>>>>>>> such examples could be given. >>>>>>>>>>>=20 >>>>>>>>>>> I'm actually not aware of anyone with an implementation who >>>>>>>>>>> doesn't support this. Just in case not obvious, that includes m= e. >>>>>>>>>>>=20 >>>>>>>>>>> Does anyone with an implementation have an issue? >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> May I read that there are problems? >>>>>>>>>>>> If so, we cannot bring out a std track RFC followed up with >>>>>>>>>>>> something that can not interoperate with it. Or we mark the to= _be RFC as >>>>>>>>>>>> obsolete. That's how it works. >>>>>>>>>>>>=20 >>>>>>>>>>>> Teco >>>>>>>>>>>>=20 >>>>>>>>>>>> PS1. you mentioned something about IESG and correctness... >>>>>>>>>>>> PS2: I understand the motivation. discussion could be how to >>>>>>>>>>>> deal with it. >>>>>>>>>>>>=20 >>>>>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove >>>>>>>>>>>> het volgende geschreven: >>>>>>>>>>>>=20 >>>>>>>>>>>>> I think my starting point with such a discussion would be who >>>>>>>>>>>>> has an implementation? Yes, there are possible minor issues f= or >>>>>>>>>>>>> implementations (though it's also possible for an implementat= ion to need no >>>>>>>>>>>>> changes at all). But the most pointless thing would be protec= ting (in a >>>>>>>>>>>>> minor way) hypothetical implementations while people actually= with them want >>>>>>>>>>>>> this. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> (I'm not saying those with them have all said they want this. >>>>>>>>>>>>> I'm asking.) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduc= e >>>>>>>>>>>>>> problems in a network with and without routers that implemen= t this? >>>>>>>>>>>>>> If so, I think we need some discussion first. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Teco >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) >>>>>>>>>>>>>> het volgende geschreven: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these >>>>>>>>>>>>>>> documents as working group docs? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Stan >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I don't believe that the chairs have raised the WG adoptio= n >>>>>>>>>>>>>>>> of the IDs I presented at Berlin. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimizatio= n >>>>>>>>>>>>>>>> and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are int= ended for >>>>>>>>>>>>>>>> Standards Track, and as minor updates to NHDP and OLSRv2, = which we would >>>>>>>>>>>>>>>> like to progress as fast as possible. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd >>>>>>>>>>>>>>>> obvious have no problem with being adopted as a WG documen= t, but it needs at >>>>>>>>>>>>>>>> least one more revision, which we intend to do as an autho= r draft, so there >>>>>>>>>>>>>>>> isn't the same time pressure there. However of course we w= ould like >>>>>>>>>>>>>>>> discussion any time from now. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, >>>>>>>>>>>>>>>> UK >>>>>>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough >>>>>>>>>>>>>>>> Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> **********************************************************= ********** >>>>>>>>>>>>>>>> This email and any attachments are confidential to the >>>>>>>>>>>>>>>> intended >>>>>>>>>>>>>>>> recipient and may also be privileged. If you are not the >>>>>>>>>>>>>>>> intended >>>>>>>>>>>>>>>> recipient please delete it from your system and notify the >>>>>>>>>>>>>>>> sender. >>>>>>>>>>>>>>>> You should not copy it or use it for any purpose nor >>>>>>>>>>>>>>>> disclose or >>>>>>>>>>>>>>>> distribute its contents to any other person. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> **********************************************************= ********** >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> We began as wanderers, and we are wanderers still. We have lingered >>>>> long enough on the shores of the cosmic ocean. We are ready at last t= o >>>>> set sail for the stars - Carl Sagan >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 >=20 >=20 > --=20 > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jpmacker@gmail.com Fri Aug 30 09:55:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6983C21F9ACA for ; Fri, 30 Aug 2013 09:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ9m8e9Z1qnp for ; Fri, 30 Aug 2013 09:55:20 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9931E11E80FA for ; Fri, 30 Aug 2013 09:55:18 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id f6so1083242qej.5 for ; Fri, 30 Aug 2013 09:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OAhObkrDZZP3wnFrn7cic5zLQ3kelAqskkhiPoks+qA=; b=VilWciy9m2NhFNDIZvyDtoaIUkC2oocY7kDT2UEmFY+wl6KVD7PMw2s820JuZ581TP lgJnQtw/JBesdOnZRd4Jreb7QGTYrGN6kOAZk7fIbIlr5Gt1pDASJWYV0ZL4uFNBIMYY MqD2dG6GPnisSGry6I31nqQNdwNbebLLi1MJh4D37SIcy6gIlmMMEUM+l4VbILx0Snei MFY11CU0zbR9nkuq/2yolhMAPCVIuSizARk/alh4efFPd+FoiRLOxWDKUqkr6tFUFYfr 6rP1//ksEoHdiL+j7eu6A9OLC84eHaxJ6HSnr7qN14DcoMruoZmIcxIs5cFsj1ZZS4tu 1YYw== X-Received: by 10.49.58.132 with SMTP id r4mr12690111qeq.10.1377881713251; Fri, 30 Aug 2013 09:55:13 -0700 (PDT) Received: from vpn217206.nrl.navy.mil (vpn217206.nrl.navy.mil. [132.250.217.206]) by mx.google.com with ESMTPSA id t4sm53117867qas.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 09:55:12 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Macker In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C1149F906@xmb-aln-x03.cisco.com> Date: Fri, 30 Aug 2013 12:55:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> <78817FC1-24B1-422B-A0EB-4147498BF2D3@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C1149F906@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1508) Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org List" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:55:22 -0000 I also agree so far I see no strong opposition and because they are only = being adopted for further work the raised issues such as Justin's can = continue to be worked in the normal process. -Joe On Aug 30, 2013, at 12:51 PM, "Stan Ratliff (sratliff)" = wrote: > OK, so with the emails from Henning and Thomas, it looks like the = issue of interoperability has been covered. And again, the request was = simply for adopting these documents as working group documents - not for = ratification.=20 >=20 > My vote is to accept all three as WG documents. Consider this email as = "last call for opposition"... >=20 > Regards, > Stan >=20 >=20 > On Aug 30, 2013, at 12:41 PM, Henning Rogge > wrote: >=20 >> Hi, >>=20 >> I am pretty sure (but have not tested it) the Olsr.org OLSRv2 >> implementation would also have no trouble with the "TLV extension" >> draft, as long as the currently unused bitfields are not used. In >> fact, I accidentally implemented parts of the extension because I = used >> the value 255 as "no TLV found" for a few TLVs. >>=20 >> The only think I can see that will happen is that a "non TLV >> extension" implementation will not interoperate with Chris planned >> Multitopology implementation, when it use the unused bitfields. >>=20 >> Which is okay for me, it cannot process the Multitopology information = anyways. >>=20 >> Henning Rogge >>=20 >> On Fri, Aug 30, 2013 at 6:34 PM, Thomas Heide Clausen >> wrote: >>> I should add that I have a *strict* implementation of OLSRv2, = finished well >>> before these I-Ds were as much as a twinkle in Chris' eyes, and = conforming >>> strictly to draft-ietf-manet-olsrv2 as currently sitting with the = RFC >>> Editor. >>>=20 >>> While that implementation - of course - will not generate TLVs of = the form >>> described in TLV-Extensions, it will happily process them and will = do the >>> right thing when presented with such TLVs (i.e., already interprets = fields >>> as bit-vectors, process value field lengths "correctly", behave >>> appropriately when seeing unknown values and not discard the message = as a >>> consequence hereof, etc.) Much the same as Justin describes for his >>> implementations. >>>=20 >>> For the Routing MPR optimization I-D, the same applies: no = interoperability >>> issues. >>>=20 >>> Such interoperability was, indeed, a condition for me to join Chris = in this >>> (these) I-D, and something I verified with my implementation in = advance >>> hereof: I actually wrote a small piece of test code that generates = OLSRv2 >>> messages containing TLVs formatted according to the TLV-Extension = I-D, and >>> feed them to my OLSRv2 implementation, just to be sure. >>>=20 >>> Justin: like Chris, I look forward to your - always very useful and >>> constructive - detailed feedback and comments to the I-Ds. >>>=20 >>> Teco: I appreciate that you worry about "running code" - that makes = two of >>> us (you know my position: running code is king, and pushing specs = through >>> without them is unacceptable). My conclusion is, based on the above, = that >>> there are no interoperability issues between a "conformant" = implementation >>> of OLSRv2 and a "conformat" implementation of OLSRv2 + = TLV-Extensions and/or >>> routing MPR optimization. >>>=20 >>> (Of course, if someone shows up with a non-conformat implementation = of a >>> spec, then all bets are off on interoperability - but the IETF can't = really >>> guard against implementations not following the specs, other than to = try to >>> "limit the damage" ..... which I think that OLSRv2 does nicely). >>>=20 >>> Respectfully, >>>=20 >>> Thomas >>>=20 >>> Sent from my iPad >>>=20 >>> On 30 ao=FBt 2013, at 16:35, Justin Dean = wrote: >>>=20 >>> I support adoption of this draft by the working group as it = addresses a >>> previously undefined behavior of the NHDP/OLSRv2 protocols. I do = have >>> implementations and I don't see any issues with this document. I = just so >>> happened to make similar choices in behavior, if I hadn't however = the >>> changes would be simple to implement and even if I didn't nothing = would >>> "break" as no new TLVs or values are introduced with this document. = Even >>> protocols extended with future TLVs (and values) which took = advantage of the >>> behaviors outlined in this document wouldn't break anything in = non-compliant >>> protocols, they just wouldn't play as nice together (which is the = current >>> case anyhow). >>>=20 >>> I do have issue with some of the language and found it overly = difficult to >>> understand what was being specified. I'm willing to provide some = more >>> concrete feedback in this regard later. >>>=20 >>> Justin >>>=20 >>>=20 >>> On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg = >>> wrote: >>>>=20 >>>> I don't see any issues with the approach of the TLV extension = draft. Like >>>> Chris said, it specifies a behavior that was previously unspecified = (and >>>> thus undefined). >>>> On the procedural question, the IETF has introduced "updates = RFCxxxx" for >>>> a good reason, and I think this particular case is such a case. >>>>=20 >>>> Ulrich >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) >>>> wrote: >>>>>=20 >>>>> I thought I'd replied to this, but can't see on list. I think your >>>>> characterisation of this whole issue is wrong. >>>>>=20 >>>>> Currently, there is no specification what to do when seeing an = unknown >>>>> value. This defines one. Of course with no specification, people = can do >>>>> anything (including dropping the message). That's undesirable, = let's fix it. >>>>>=20 >>>>> As for the sacrosanctness of the specification, let's be real. How = many >>>>> implementations actually are there yet? Is there anyone with one = who finds >>>>> this other than a positive thing? >>>>>=20 >>>>> -- >>>>> Christopher Dearlove >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>=20 >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England & Wales No: 1996687 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>>> Sent: 17 August 2013 08:37 >>>>> To: Henning Rogge >>>>> Cc: Christopher Dearlove; Dearlove, Christopher (UK); = manet@ietf.org >>>>> List; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide = Clausen >>>>> (thomas@thomasclausen.org); Stan Ratliff (sratliff) >>>>> Subject: Re: [manet] IDs presemted in Berlin >>>>>=20 >>>>> ----------------------! WARNING ! ---------------------- >>>>> This message originates from outside our organisation, >>>>> either from an external partner or from the internet. >>>>> Keep this in mind if you answer this message. >>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>> for instructions on reporting suspicious email messages. >>>>> -------------------------------------------------------- >>>>>=20 >>>>> Can I read this as: >>>>>=20 >>>>> 1) an implementations that did not implement this new = specification might >>>>> drop these new messages and therefore is not compatible >>>>> 2) an implementations that did not implement this new = specification might >>>>> accept these new messages and therefore is compatible >>>>>=20 >>>>> "old" of "new" is not important. It is about stability of the = standard. >>>>> We have to stop incremental changes that are not backwards = compatible. Or >>>>> step to new version or similar tag. >>>>>=20 >>>>> Teco >>>>>=20 >>>>> Op 16 aug. 2013, om 23:41 heeft Henning Rogge = het >>>>> volgende geschreven: >>>>>=20 >>>>>> If I understand the draft right we have the following situations: >>>>>>=20 >>>>>> 1) an "old" implementation should interop with a "new" one = without any >>>>>> extensions easily. >>>>>> 2) an "old" implementation might just drop messages from a "new" >>>>>> implementation which use an extension >>>>>>=20 >>>>>> Henning Rogge >>>>>>=20 >>>>>> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot = wrote: >>>>>>> Yes. >>>>>>>=20 >>>>>>> Teco >>>>>>>=20 >>>>>>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove >>>>>>> het volgende geschreven: >>>>>>>=20 >>>>>>>> Have you read the draft? >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Christopher Dearlove >>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>=20 >>>>>>>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>> I understand the change is documented. >>>>>>>>> My concerns are on what happens when different implementations = are >>>>>>>>> in same network. This has to be documented. Asking on mailing = list is not >>>>>>>>> enough. >>>>>>>>>=20 >>>>>>>>> Teco >>>>>>>>>=20 >>>>>>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove >>>>>>>>> het volgende geschreven: >>>>>>>>>=20 >>>>>>>>>> I think you are quite wrong on the obsoleted point. = Especially when >>>>>>>>>> we are talking changes to define what was previously = undefined. Nothing >>>>>>>>>> defined has changed. Which is just like the TOS change. >>>>>>>>>>=20 >>>>>>>>>> But if you want to know what's changed, read the draft. >>>>>>>>>>=20 >>>>>>>>>> I'd be interested in hearing from people with = implementations. If >>>>>>>>>> the bottom line is that there isn't anyone with an = implementation who has a >>>>>>>>>> problem, I think worries over a hypothetical unwritten = implementation are >>>>>>>>>> rather beside the point. Anyone coming to something new could = always check >>>>>>>>>> the "updated by" bit. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>>>>>>>>=20 >>>>>>>>>>> If anyone in the future writes code that complies with std = track >>>>>>>>>>> RFC, he/she may assume that it is compatible with any other = implementation. >>>>>>>>>>> If an update of that RFC will break compatibility, that RFC = shall be >>>>>>>>>>> obsoleted, I think. >>>>>>>>>>>=20 >>>>>>>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", = "are >>>>>>>>>>> to be used to guide", "may". Remapping to DSCP is highly = backwards >>>>>>>>>>> compatible. >>>>>>>>>>>=20 >>>>>>>>>>> Did I say I'm against? I just want to know the issues / = problems. >>>>>>>>>>> At least they should be documented. >>>>>>>>>>>=20 >>>>>>>>>>> Teco >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove >>>>>>>>>>> het volgende geschreven: >>>>>>>>>>>=20 >>>>>>>>>>>> You can read this that there are minor issues, which I = wouldn't >>>>>>>>>>>> elevate to the level of problems. >>>>>>>>>>>>=20 >>>>>>>>>>>> Your comment on the inability to modify RFCs is just plain = wrong. >>>>>>>>>>>> Was RFC 791 obsoleted when the TOS bits function was = changed? No. Many more >>>>>>>>>>>> such examples could be given. >>>>>>>>>>>>=20 >>>>>>>>>>>> I'm actually not aware of anyone with an implementation who >>>>>>>>>>>> doesn't support this. Just in case not obvious, that = includes me. >>>>>>>>>>>>=20 >>>>>>>>>>>> Does anyone with an implementation have an issue? >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> May I read that there are problems? >>>>>>>>>>>>> If so, we cannot bring out a std track RFC followed up = with >>>>>>>>>>>>> something that can not interoperate with it. Or we mark = the to_be RFC as >>>>>>>>>>>>> obsolete. That's how it works. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Teco >>>>>>>>>>>>>=20 >>>>>>>>>>>>> PS1. you mentioned something about IESG and correctness... >>>>>>>>>>>>> PS2: I understand the motivation. discussion could be how = to >>>>>>>>>>>>> deal with it. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove >>>>>>>>>>>>> het volgende geschreven: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think my starting point with such a discussion would be = who >>>>>>>>>>>>>> has an implementation? Yes, there are possible minor = issues for >>>>>>>>>>>>>> implementations (though it's also possible for an = implementation to need no >>>>>>>>>>>>>> changes at all). But the most pointless thing would be = protecting (in a >>>>>>>>>>>>>> minor way) hypothetical implementations while people = actually with them want >>>>>>>>>>>>>> this. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> (I'm not saying those with them have all said they want = this. >>>>>>>>>>>>>> I'm asking.) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot = wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension = introduce >>>>>>>>>>>>>>> problems in a network with and without routers that = implement this? >>>>>>>>>>>>>>> If so, I think we need some discussion first. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Teco >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) >>>>>>>>>>>>>>> het volgende geschreven: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these >>>>>>>>>>>>>>>> documents as working group docs? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> Stan >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher = (UK)" >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I don't believe that the chairs have raised the WG = adoption >>>>>>>>>>>>>>>>> of the IDs I presented at Berlin. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Two of these, = draft-dearlove-manet-olsrv2-rmpr-optimization >>>>>>>>>>>>>>>>> and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are = intended for >>>>>>>>>>>>>>>>> Standards Track, and as minor updates to NHDP and = OLSRv2, which we would >>>>>>>>>>>>>>>>> like to progress as fast as possible. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, = we'd >>>>>>>>>>>>>>>>> obvious have no problem with being adopted as a WG = document, but it needs at >>>>>>>>>>>>>>>>> least one more revision, which we intend to do as an = author draft, so there >>>>>>>>>>>>>>>>> isn't the same time pressure there. However of course = we would like >>>>>>>>>>>>>>>>> discussion any time from now. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 = 8HN, >>>>>>>>>>>>>>>>> UK >>>>>>>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>>>>>>>>> chris.dearlove@baesystems.com | = http://www.baesystems.com >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, = Farnborough >>>>>>>>>>>>>>>>> Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> = ******************************************************************** >>>>>>>>>>>>>>>>> This email and any attachments are confidential to the >>>>>>>>>>>>>>>>> intended >>>>>>>>>>>>>>>>> recipient and may also be privileged. If you are not = the >>>>>>>>>>>>>>>>> intended >>>>>>>>>>>>>>>>> recipient please delete it from your system and notify = the >>>>>>>>>>>>>>>>> sender. >>>>>>>>>>>>>>>>> You should not copy it or use it for any purpose nor >>>>>>>>>>>>>>>>> disclose or >>>>>>>>>>>>>>>>> distribute its contents to any other person. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> = ******************************************************************** >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> We began as wanderers, and we are wanderers still. We have = lingered >>>>>> long enough on the shores of the cosmic ocean. We are ready at = last to >>>>>> set sail for the stars - Carl Sagan >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >>=20 >>=20 >> --=20 >> We began as wanderers, and we are wanderers still. We have lingered >> long enough on the shores of the cosmic ocean. We are ready at last = to >> set sail for the stars - Carl Sagan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From christopher.dearlove@gmail.com Fri Aug 30 10:34:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679F111E8113 for ; Fri, 30 Aug 2013 10:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSRUM+CWSFR8 for ; Fri, 30 Aug 2013 10:33:59 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8A36711E80FA for ; Fri, 30 Aug 2013 10:33:58 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so2182479wgh.1 for ; Fri, 30 Aug 2013 10:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=auQ+/8rdxNc3fKtCiohEg2vQELzGH3Oksa9dTNbjiGs=; b=ZizeoItncLfBjAhxbZc/PQtXqWX/pznYOUrndHTURhI80Cy1IyjlENZJ923D251UFN a8auEfWKK6oTz+8wxK2hfjEm1RIea4rnXqY6B+ObZwCSThpbOX53wN8cLz4j9Mr6iu/D O4lz+LsS1mzT5bLO4bmhoHxr1yT5j5VcNuZj/6GSHc4+PSIBjH95eQwKB2V0lsLZTSt3 h3r0r4xZo0DDOfiSQ/64SmHchSw3R0ZsOdQd34IbdUtNys28YRvT9YS/FJiA2ZXYIyHK aQVWUrEOhN0xUvx+dqlvWI+gLx6uCQcGJcpOowZEaHwR2SNhjXeaAZeKBOWqhdv3cxEB lbTg== X-Received: by 10.180.9.69 with SMTP id x5mr3356302wia.41.1377884037648; Fri, 30 Aug 2013 10:33:57 -0700 (PDT) Received: from [192.168.1.92] (host109-153-94-19.range109-153.btcentralplus.com. [109.153.94.19]) by mx.google.com with ESMTPSA id r6sm5871840wiw.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 10:33:56 -0700 (PDT) References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> <9B9E2495-29AB-4DAB-8532-1F2163FF7637@inf-net.nl> <78EC0155-B992-4397-9305-37679A7F5787@inf-net.nl> <3BC5404D-D126-4E04-BB51-9006DF7EF165@inf-net.nl> <78817FC1-24B1-422B-A0EB-4147498BF2D3@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C1149F906@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4881B045-9D83-4824-834C-8E58373C1E03@gmail.com> X-Mailer: iPhone Mail (10B350) From: Christopher Dearlove Date: Fri, 30 Aug 2013 18:32:34 +0100 To: Joe Macker Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 17:34:00 -0000 Indeed. While I want to go further than the WG with them, to the WG is all t= hat's being considered now. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 30 Aug 2013, at 17:55, Joe Macker wrote: > I also agree so far I see no strong opposition and because they are only b= eing adopted for further work the raised issues such as Justin's can continu= e to be worked in the normal process. > -Joe > On Aug 30, 2013, at 12:51 PM, "Stan Ratliff (sratliff)" wrote: >=20 >> OK, so with the emails from Henning and Thomas, it looks like the issue o= f interoperability has been covered. And again, the request was simply for a= dopting these documents as working group documents - not for ratification.=20= >>=20 >> My vote is to accept all three as WG documents. Consider this email as "l= ast call for opposition"... >>=20 >> Regards, >> Stan >>=20 >>=20 >> On Aug 30, 2013, at 12:41 PM, Henning Rogge >> wrote: >>=20 >>> Hi, >>>=20 >>> I am pretty sure (but have not tested it) the Olsr.org OLSRv2 >>> implementation would also have no trouble with the "TLV extension" >>> draft, as long as the currently unused bitfields are not used. In >>> fact, I accidentally implemented parts of the extension because I used >>> the value 255 as "no TLV found" for a few TLVs. >>>=20 >>> The only think I can see that will happen is that a "non TLV >>> extension" implementation will not interoperate with Chris planned >>> Multitopology implementation, when it use the unused bitfields. >>>=20 >>> Which is okay for me, it cannot process the Multitopology information an= yways. >>>=20 >>> Henning Rogge >>>=20 >>> On Fri, Aug 30, 2013 at 6:34 PM, Thomas Heide Clausen >>> wrote: >>>> I should add that I have a *strict* implementation of OLSRv2, finished w= ell >>>> before these I-Ds were as much as a twinkle in Chris' eyes, and conform= ing >>>> strictly to draft-ietf-manet-olsrv2 as currently sitting with the RFC >>>> Editor. >>>>=20 >>>> While that implementation - of course - will not generate TLVs of the f= orm >>>> described in TLV-Extensions, it will happily process them and will do t= he >>>> right thing when presented with such TLVs (i.e., already interprets fie= lds >>>> as bit-vectors, process value field lengths "correctly", behave >>>> appropriately when seeing unknown values and not discard the message as= a >>>> consequence hereof, etc.) Much the same as Justin describes for his >>>> implementations. >>>>=20 >>>> For the Routing MPR optimization I-D, the same applies: no interoperabi= lity >>>> issues. >>>>=20 >>>> Such interoperability was, indeed, a condition for me to join Chris in t= his >>>> (these) I-D, and something I verified with my implementation in advance= >>>> hereof: I actually wrote a small piece of test code that generates OLSR= v2 >>>> messages containing TLVs formatted according to the TLV-Extension I-D, a= nd >>>> feed them to my OLSRv2 implementation, just to be sure. >>>>=20 >>>> Justin: like Chris, I look forward to your - always very useful and >>>> constructive - detailed feedback and comments to the I-Ds. >>>>=20 >>>> Teco: I appreciate that you worry about "running code" - that makes two= of >>>> us (you know my position: running code is king, and pushing specs throu= gh >>>> without them is unacceptable). My conclusion is, based on the above, th= at >>>> there are no interoperability issues between a "conformant" implementat= ion >>>> of OLSRv2 and a "conformat" implementation of OLSRv2 + TLV-Extensions a= nd/or >>>> routing MPR optimization. >>>>=20 >>>> (Of course, if someone shows up with a non-conformat implementation of a= >>>> spec, then all bets are off on interoperability - but the IETF can't re= ally >>>> guard against implementations not following the specs, other than to tr= y to >>>> "limit the damage" ..... which I think that OLSRv2 does nicely). >>>>=20 >>>> Respectfully, >>>>=20 >>>> Thomas >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On 30 ao=C3=BBt 2013, at 16:35, Justin Dean wrot= e: >>>>=20 >>>> I support adoption of this draft by the working group as it addresses a= >>>> previously undefined behavior of the NHDP/OLSRv2 protocols. I do have >>>> implementations and I don't see any issues with this document. I just s= o >>>> happened to make similar choices in behavior, if I hadn't however the >>>> changes would be simple to implement and even if I didn't nothing would= >>>> "break" as no new TLVs or values are introduced with this document. Ev= en >>>> protocols extended with future TLVs (and values) which took advantage o= f the >>>> behaviors outlined in this document wouldn't break anything in non-comp= liant >>>> protocols, they just wouldn't play as nice together (which is the curre= nt >>>> case anyhow). >>>>=20 >>>> I do have issue with some of the language and found it overly difficult= to >>>> understand what was being specified. I'm willing to provide some more >>>> concrete feedback in this regard later. >>>>=20 >>>> Justin >>>>=20 >>>>=20 >>>> On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg >>>> wrote: >>>>>=20 >>>>> I don't see any issues with the approach of the TLV extension draft. L= ike >>>>> Chris said, it specifies a behavior that was previously unspecified (a= nd >>>>> thus undefined). >>>>> On the procedural question, the IETF has introduced "updates RFCxxxx" f= or >>>>> a good reason, and I think this particular case is such a case. >>>>>=20 >>>>> Ulrich >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) >>>>> wrote: >>>>>>=20 >>>>>> I thought I'd replied to this, but can't see on list. I think your >>>>>> characterisation of this whole issue is wrong. >>>>>>=20 >>>>>> Currently, there is no specification what to do when seeing an unknow= n >>>>>> value. This defines one. Of course with no specification, people can d= o >>>>>> anything (including dropping the message). That's undesirable, let's f= ix it. >>>>>>=20 >>>>>> As for the sacrosanctness of the specification, let's be real. How ma= ny >>>>>> implementations actually are there yet? Is there anyone with one who f= inds >>>>>> this other than a positive thing? >>>>>>=20 >>>>>> -- >>>>>> Christopher Dearlove >>>>>> Senior Principal Engineer, Communications Group >>>>>> Communications, Networks and Image Analysis Capability >>>>>> BAE Systems Advanced Technology Centre >>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>=20 >>>>>> BAE Systems (Operations) Limited >>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>>>> Registered in England & Wales No: 1996687 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>>>> Sent: 17 August 2013 08:37 >>>>>> To: Henning Rogge >>>>>> Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org >>>>>> List; Joe Macker (joseph.macker@nrl.navy.mil); Thomas Heide Clausen >>>>>> (thomas@thomasclausen.org); Stan Ratliff (sratliff) >>>>>> Subject: Re: [manet] IDs presemted in Berlin >>>>>>=20 >>>>>> ----------------------! WARNING ! ---------------------- >>>>>> This message originates from outside our organisation, >>>>>> either from an external partner or from the internet. >>>>>> Keep this in mind if you answer this message. >>>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>>> for instructions on reporting suspicious email messages. >>>>>> -------------------------------------------------------- >>>>>>=20 >>>>>> Can I read this as: >>>>>>=20 >>>>>> 1) an implementations that did not implement this new specification m= ight >>>>>> drop these new messages and therefore is not compatible >>>>>> 2) an implementations that did not implement this new specification m= ight >>>>>> accept these new messages and therefore is compatible >>>>>>=20 >>>>>> "old" of "new" is not important. It is about stability of the standar= d. >>>>>> We have to stop incremental changes that are not backwards compatible= . Or >>>>>> step to new version or similar tag. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>> Op 16 aug. 2013, om 23:41 heeft Henning Rogge = het >>>>>> volgende geschreven: >>>>>>=20 >>>>>>> If I understand the draft right we have the following situations: >>>>>>>=20 >>>>>>> 1) an "old" implementation should interop with a "new" one without a= ny >>>>>>> extensions easily. >>>>>>> 2) an "old" implementation might just drop messages from a "new" >>>>>>> implementation which use an extension >>>>>>>=20 >>>>>>> Henning Rogge >>>>>>>=20 >>>>>>> On Fri, Aug 16, 2013 at 11:36 PM, Teco Boot wrote:= >>>>>>>> Yes. >>>>>>>>=20 >>>>>>>> Teco >>>>>>>>=20 >>>>>>>> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove >>>>>>>> het volgende geschreven: >>>>>>>>=20 >>>>>>>>> Have you read the draft? >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Christopher Dearlove >>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>>=20 >>>>>>>>> On 16 Aug 2013, at 21:58, Teco Boot wrote: >>>>>>>>>=20 >>>>>>>>>> I understand the change is documented. >>>>>>>>>> My concerns are on what happens when different implementations ar= e >>>>>>>>>> in same network. This has to be documented. Asking on mailing lis= t is not >>>>>>>>>> enough. >>>>>>>>>>=20 >>>>>>>>>> Teco >>>>>>>>>>=20 >>>>>>>>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove >>>>>>>>>> het volgende geschreven: >>>>>>>>>>=20 >>>>>>>>>>> I think you are quite wrong on the obsoleted point. Especially w= hen >>>>>>>>>>> we are talking changes to define what was previously undefined. N= othing >>>>>>>>>>> defined has changed. Which is just like the TOS change. >>>>>>>>>>>=20 >>>>>>>>>>> But if you want to know what's changed, read the draft. >>>>>>>>>>>=20 >>>>>>>>>>> I'd be interested in hearing from people with implementations. I= f >>>>>>>>>>> the bottom line is that there isn't anyone with an implementatio= n who has a >>>>>>>>>>> problem, I think worries over a hypothetical unwritten implement= ation are >>>>>>>>>>> rather beside the point. Anyone coming to something new could al= ways check >>>>>>>>>>> the "updated by" bit. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 16 Aug 2013, at 21:27, Teco Boot wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> If anyone in the future writes code that complies with std trac= k >>>>>>>>>>>> RFC, he/she may assume that it is compatible with any other imp= lementation. >>>>>>>>>>>> If an update of that RFC will break compatibility, that RFC sha= ll be >>>>>>>>>>>> obsoleted, I think. >>>>>>>>>>>>=20 >>>>>>>>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "ar= e >>>>>>>>>>>> to be used to guide", "may". Remapping to DSCP is highly backwa= rds >>>>>>>>>>>> compatible. >>>>>>>>>>>>=20 >>>>>>>>>>>> Did I say I'm against? I just want to know the issues / problem= s. >>>>>>>>>>>> At least they should be documented. >>>>>>>>>>>>=20 >>>>>>>>>>>> Teco >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove >>>>>>>>>>>> het volgende geschreven: >>>>>>>>>>>>=20 >>>>>>>>>>>>> You can read this that there are minor issues, which I wouldn'= t >>>>>>>>>>>>> elevate to the level of problems. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Your comment on the inability to modify RFCs is just plain wro= ng. >>>>>>>>>>>>> Was RFC 791 obsoleted when the TOS bits function was changed? N= o. Many more >>>>>>>>>>>>> such examples could be given. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I'm actually not aware of anyone with an implementation who >>>>>>>>>>>>> doesn't support this. Just in case not obvious, that includes m= e. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Does anyone with an implementation have an issue? >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 16 Aug 2013, at 18:05, Teco Boot wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> May I read that there are problems? >>>>>>>>>>>>>> If so, we cannot bring out a std track RFC followed up with >>>>>>>>>>>>>> something that can not interoperate with it. Or we mark the t= o_be RFC as >>>>>>>>>>>>>> obsolete. That's how it works. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Teco >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> PS1. you mentioned something about IESG and correctness... >>>>>>>>>>>>>> PS2: I understand the motivation. discussion could be how to >>>>>>>>>>>>>> deal with it. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove >>>>>>>>>>>>>> het volgende geschreven: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think my starting point with such a discussion would be wh= o >>>>>>>>>>>>>>> has an implementation? Yes, there are possible minor issues f= or >>>>>>>>>>>>>>> implementations (though it's also possible for an implementa= tion to need no >>>>>>>>>>>>>>> changes at all). But the most pointless thing would be prote= cting (in a >>>>>>>>>>>>>>> minor way) hypothetical implementations while people actuall= y with them want >>>>>>>>>>>>>>> this. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> (I'm not saying those with them have all said they want this= . >>>>>>>>>>>>>>> I'm asking.) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>>>>> christopher.dearlove@gmail.com (iPhone) >>>>>>>>>>>>>>> chris@mnemosyne.demon.co.uk (home) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 16 Aug 2013, at 17:00, Teco Boot wrote:= >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introdu= ce >>>>>>>>>>>>>>>> problems in a network with and without routers that impleme= nt this? >>>>>>>>>>>>>>>> If so, I think we need some discussion first. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Teco >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) >>>>>>>>>>>>>>>> het volgende geschreven: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> OK, so to the WG - do we have consensus to adopt these >>>>>>>>>>>>>>>>> documents as working group docs? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> Stan >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Aug 16, 2013, at 8:59 AM, "Dearlove, Christopher (UK)" >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I don't believe that the chairs have raised the WG adopti= on >>>>>>>>>>>>>>>>>> of the IDs I presented at Berlin. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimizati= on >>>>>>>>>>>>>>>>>> and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are in= tended for >>>>>>>>>>>>>>>>>> Standards Track, and as minor updates to NHDP and OLSRv2,= which we would >>>>>>>>>>>>>>>>>> like to progress as fast as possible. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'= d >>>>>>>>>>>>>>>>>> obvious have no problem with being adopted as a WG docume= nt, but it needs at >>>>>>>>>>>>>>>>>> least one more revision, which we intend to do as an auth= or draft, so there >>>>>>>>>>>>>>>>>> isn't the same time pressure there. However of course we w= ould like >>>>>>>>>>>>>>>>>> discussion any time from now. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Christopher Dearlove >>>>>>>>>>>>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>>>>>>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>>>>>>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>>>>>>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN= , >>>>>>>>>>>>>>>>>> UK >>>>>>>>>>>>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>>>>>>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com= >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> BAE Systems (Operations) Limited >>>>>>>>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough >>>>>>>>>>>>>>>>>> Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>>>>>>>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> *********************************************************= *********** >>>>>>>>>>>>>>>>>> This email and any attachments are confidential to the >>>>>>>>>>>>>>>>>> intended >>>>>>>>>>>>>>>>>> recipient and may also be privileged. If you are not the >>>>>>>>>>>>>>>>>> intended >>>>>>>>>>>>>>>>>> recipient please delete it from your system and notify th= e >>>>>>>>>>>>>>>>>> sender. >>>>>>>>>>>>>>>>>> You should not copy it or use it for any purpose nor >>>>>>>>>>>>>>>>>> disclose or >>>>>>>>>>>>>>>>>> distribute its contents to any other person. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> *********************************************************= *********** >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> We began as wanderers, and we are wanderers still. We have lingered >>>>>>> long enough on the shores of the cosmic ocean. We are ready at last t= o >>>>>>> set sail for the stars - Carl Sagan >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>> --=20 >>> We began as wanderers, and we are wanderers still. We have lingered >>> long enough on the shores of the cosmic ocean. We are ready at last to >>> set sail for the stars - Carl Sagan >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From abdussalambaryun@gmail.com Sat Aug 31 01:55:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC9321E80A7 for ; Sat, 31 Aug 2013 01:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE3MLjzSnbGr for ; Sat, 31 Aug 2013 01:55:25 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D1ABA11E80DF for ; Sat, 31 Aug 2013 01:55:25 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so3243710pad.18 for ; Sat, 31 Aug 2013 01:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HjYdo5YGxh14Ox6Ab4mUf1BoyA9r81RNiVm4A0pxXTY=; b=hNerr2Au3JKN7M+LbBWIpNZbeOTewnFJgrx7bfLHV/LUiuLnPVKiZ4umvf45/UChBm nHVebdBN6tkRp9/YolhpmlEpm3+Jk2kWbyyZNuq2itBvY5CbeqCH7W2pjcGWKqIb+R0V Ewt5aGO9L8toA1hBNebOGUe7whUzeRBoAvTGD41NiNWuCxbAikyhgJl2tQRPcykqFRDA 81docBMrLRN3+x5GaU8gMKZ+yaz7DC6hgrUq9/k8rNif/FFOtW6fbBU5/ziBoXfW1O5Z 66HfkXtBe85ThQE3f6b0LmJ+zxMrLutU5QbKSULJ/iMgW+4IIqk+z1qe+dVmG936dRgc tPew== MIME-Version: 1.0 X-Received: by 10.66.230.233 with SMTP id tb9mr15472799pac.38.1377939325569; Sat, 31 Aug 2013 01:55:25 -0700 (PDT) Received: by 10.68.195.168 with HTTP; Sat, 31 Aug 2013 01:55:25 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C101F636D@xmb-aln-x03.cisco.com> <71EDEBC0-0674-4341-BE62-B62B07DF4F07@inf-net.nl> <537333C4-E5A1-4C58-992A-B409D4EDD59B@gmail.com> <9729ABC0-38D9-4DB7-A786-D6C68D732D14@inf-net.nl> <042C379C-3D2B-49FA-9492-9F27855B0F78@gmail.com> Date: Sat, 31 Aug 2013 10:55:25 +0200 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org List" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] IDs presemted in Berlin X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 08:55:27 -0000 On 8/16/13, Teco Boot wrote: > Did I say I'm against? I just want to know the issues / problems. At least > they should be documented. >questions before the above> >Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce problems in a network with and without routers that implement this? If so, I think we need some discussion first. >May I read that there are problems? If so, we cannot bring out a std track RFC followed up with something that can not interoperate with it. Or we mark the to_be RFC as obsolete. That's how it works. +++++++++++++++++++++++++++++++++++++ I agree, that problems/questions that made MANET WG to update such RFC, SHOULD be documented/listed or discussed into IETF, we SHOULD not hide any information related to OLSRv2 problems. I still not foud answers from the new draft authors of the document requested to adopt, I agree with Teco's questions and approach to update MANET documents. AB