From russ@cisco.com Mon Aug 1 11:18:10 2011 Return-Path: X-Original-To: p2prg@ietfa.amsl.com Delivered-To: p2prg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ED45E8007 for ; Mon, 1 Aug 2011 11:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bplpEmvLqBs for ; Mon, 1 Aug 2011 11:18:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 42EF011E8131 for ; Mon, 1 Aug 2011 11:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=2283; q=dns/txt; s=iport; t=1312222696; x=1313432296; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=gmoWc+poYKjyKCs76IHbqtCnYa/330zeATsNn+tTnP0=; b=XNpoqclgnkuSXnj2UTWTi0nzn4ao5ROAYrETsyWZArcBXaktDoCzvmTv glTaZg7sAdwVVxMT6SqyzgnHzglGLNRcbcCNMHidaNnuisoF7PwCRZJQX kGyQSJnIy+qhPRhROQdsDtac07muxFlqzxmTT11x5xpvIAuTHW2NoSvFh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkIAIrsNk6rRDoH/2dsb2JhbABBmFCPEXeBWQFfBj0WGAMCAQIBWAgBAR6nd4EjAZ5bhkIEknuFB4t5 X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8522510" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 01 Aug 2011 18:18:15 +0000 Received: from [10.116.137.179] (rtp-russwh-8712.cisco.com [10.116.137.179]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p71IIEqX029362 for ; Mon, 1 Aug 2011 18:18:14 GMT Message-ID: <4E36EDE7.2080205@cisco.com> Date: Mon, 01 Aug 2011 14:18:15 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: p2prg@irtf.org X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [p2prg] Random Thoughts on draft-asai-cross-domain-overlay-01 X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 18:18:10 -0000 Y'all: My first comment is this all seems like a heuristic based on understanding current business models and modes --if business models change, the entire underlying structure needs to change. I'm not certain that's a really good place to be. On the other hand, I'm not certain there's a lot of other options in this sort of work. But it's at least worth discussing, I think. For more specific comments: == It is true that AS paths can be resolved from IP address-based paths, which can be retrieved by network management tools (e.g., traceroute). Hence, ASes do not have to provide AS paths because applications can resolve AS paths without support of ASes. However, it is an ongoing work to assign appropriate AS numbers to routers [Huffaker10]. I wonder why you wouldn't start with just peering to the BGP peers that you can, and pulling a database into a torrent, so you have this as a "background reference?" Then you could consult this database first, and if the destination is not found there, then use other techniques? You could also use some sort of location type service to choose a table that would provide the closest view to your current location as a base --the table from a provider as close to where you are as possible. This would also be "publicly available information," I think, something like having a "private P-2-P route view?" Or this covered in section 4.1? == The algorithms based on paths analysis have a difficulty in applying the inferred AS to the cost computation because there are lots of missing links, which have not been inferred. It seems like another way to estimate relationships would be based on the routes actually advertised. For instance, if an AS receives a lot of routes at 24 bits, and then sends those out plus a shorter length prefix that covers them, then the relationship is almost certainly transit, rather than peer (?). This intuition could be completely wrong, though. == Overall, this is a good start --given the caveat above about heuristics based on current business models. There are some places where we might could gather more specific information. Perhaps the only real option, long term, is something like a PSV, or other graph overlay on BGP? :-) Russ From lars.eggert@nokia.com Tue Aug 2 06:45:58 2011 Return-Path: X-Original-To: p2prg@ietfa.amsl.com Delivered-To: p2prg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9B21F86DE for ; Tue, 2 Aug 2011 06:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.785 X-Spam-Level: X-Spam-Status: No, score=-103.785 tagged_above=-999 required=5 tests=[AWL=0.703, BAYES_00=-2.599, GB_I_INVITATION=-2, SARE_NETPROD=0.111, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py287kDEHOVV for ; Tue, 2 Aug 2011 06:45:58 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id DA68921F877D for ; Tue, 2 Aug 2011 06:45:57 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p72Dk5ix029322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Aug 2011 16:46:06 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.2 at fit.nokia.com Content-Type: multipart/signed; boundary="Apple-Mail=_B8163B66-B565-463A-BF9E-0E67A46ACB10"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 2 Aug 2011 16:46:02 +0300 Message-Id: To: p2prg@irtf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.fit.nokia.com); Tue, 02 Aug 2011 16:46:02 +0300 (EEST) X-Nokia-AV: Clean X-Mailman-Approved-At: Tue, 02 Aug 2011 12:53:51 -0700 Subject: [p2prg] Call for Nominations: Applied Networking Research Prize (ANRP) for IETF-82 X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: anrp@isoc.org List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:45:58 -0000 --Apple-Mail=_B8163B66-B565-463A-BF9E-0E67A46ACB10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) =20 http://irtf.org/anrp *** Submit nominations until August 28 for the ANRP for IETF-82, *** November 13-18, 2011 in Taipei, Taiwan: *** http://fit.nokia.com/anrp/82/ The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recently published results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize (ANRP) is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: * cash prize of $500 (USD) * invited talk at the IRTF Open Meeting * travel grant to attend the week-long IETF meeting (airfare, hotel, registration, stipend) * recognition at the IETF plenary * invitation to related social activities * potential for additional travel grants to future IETF meetings, based on community feedback HOW TO APPLY Only a single person can be nominated based on a peer-reviewed, recently-published, original journal, conference or workshop paper they authored. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one=92s own paper) and third-party nominations (nominating someone else=92s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how presentation of these research results will foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend the respective IETF meeting in person and in its entirety. Nominations must include: * the name and email address of the nominee * a reference to the published nominated paper * a PDF copy of the nominated paper * a statement that describes how the nominated paper fulfills the goals of the award * a statement that the nominee is available to attend the respective IETF meeting in person and in its entirety * a brief biography or CV of the nominee * optionally, any other supporting information (link to nominee's web site, etc.) *** Nominations are submitted via the submission site: *** http://fit.nokia.com/anrp/82/ SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. The goal is to select 1-2 submissions for the Applied Networking Research Prize (ANRP) during each nomination period. All nominees will be notified by email. IMPORTANT DATES Applications open: August 1, 2011 Applications close: August 28, 2011 Notifications: September 20, 2011 IETF-82 Meeting: November 13-18, 2011 in Taipei, Taiwan=20 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF).= --Apple-Mail=_B8163B66-B565-463A-BF9E-0E67A46ACB10 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgwMjEzNDYwMlowIwYJKoZIhvcNAQkE MRYEFLG+NfUytUvQjRBiP9XmDWgPc50jMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AEz8LmUjijWXQjWEURQB+179At4PNfI/1Arum8VNYQkgaHTktDyL40VM88oMHAl6IIdyyEKJ/izF usww3xMNAx9WB5R3YME+5Bi6LqAEcZeKzU3vDJ4lzxoINlTpUWkAnxxjLk7QyRhSLoYRpcpZWX0T lX5KbMZi73OPyYOtU7UhhAwERT/ADspSG4Tnq5WFDhCcajon4EyUDOizN0T+p260IBm73GIVIFpw PE42p20IhWWrzcJM5HFgpq9fDmC+yE1+u4pLgO8O//d9I0/J26T/NgIehTSwDWNuSAXri2QeJxgY YKBT1e6RmxAEeh3YxYFoamKE0r2aPB6ts7yLPKEAAAAAAAA= --Apple-Mail=_B8163B66-B565-463A-BF9E-0E67A46ACB10-- From panda@hongo.wide.ad.jp Thu Aug 4 04:58:10 2011 Return-Path: X-Original-To: p2prg@ietfa.amsl.com Delivered-To: p2prg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D9721F8B52 for ; Thu, 4 Aug 2011 04:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeTbbHVVyxIk for ; Thu, 4 Aug 2011 04:58:09 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFC421F85C4 for ; Thu, 4 Aug 2011 04:58:03 -0700 (PDT) Received: from [172.16.78.6] (tc.b.scyphus.co.jp [219.117.248.118]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id B57BA108DF44; Thu, 4 Aug 2011 20:58:13 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hirochika Asai In-Reply-To: <4E36EDE7.2080205@cisco.com> Date: Thu, 4 Aug 2011 20:58:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6FF4B4F6-5E19-4180-9FFE-2242C38B2291@hongo.wide.ad.jp> References: <4E36EDE7.2080205@cisco.com> To: Russ White X-Mailer: Apple Mail (2.1084) Cc: p2prg@irtf.org Subject: Re: [p2prg] Random Thoughts on draft-asai-cross-domain-overlay-01 X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 11:58:10 -0000 Thank you, Russ. I agree with your point that the proposal in our draft depends on = current business models. These kinds of underlying structures will change with = adapting application needs and the actual traffic. Consequently, the proposed = solution approach may not be the best one, or may be poor, but discussing = considerations and problems with application-layer traffic optimization on the current underlying business model is essential even before the ALTO architecture = has deployed. > I wonder why you wouldn't start with just peering to the BGP peers = that > you can, and pulling a database into a torrent, so you have this as a > "background reference?" Then you could consult this database first, = and > if the destination is not found there, then use other techniques? You > could also use some sort of location type service to choose a table = that > would provide the closest view to your current location as a base = --the > table from a provider as close to where you are as possible. > This would also be "publicly available information," I think, = something > like having a "private P-2-P route view?" > Or this covered in section 4.1? Yes, retrieving BGP-level paths from BGP routers is the simplest = approach. In S4.1, we assume that this function is included in the "AS Path Provision Service". S4 is one of the possible solution but there should be more alternatives and confusing description. Hence, we want to get started = from problem statements of "cross-domain" application-layer traffic = optimization, such as policy conflicts. After we could brush up or get a consensus on = the problem statements, we want to extend the view to the architecture to = solve them, like S4. > Perhaps the only real option, long term, is something like a PSV, or > other graph overlay on BGP? In my opinion, PSV like BGP is hard to be an option for overlay networks = due to the size of path-vector tables. Path-vector tables are computed for = each file or stream when PSV is used. However, I cannot say how large the tables = are, at this time. I should show the size, the possibility of table = aggregation, etc. We'll work on it soon! Thank you, again. Hirochika On Aug 2, 2011, at 3:18 AM, Russ White wrote: > Y'all: >=20 > My first comment is this all seems like a heuristic based on > understanding current business models and modes --if business models > change, the entire underlying structure needs to change. I'm not = certain > that's a really good place to be. On the other hand, I'm not certain > there's a lot of other options in this sort of work. >=20 > But it's at least worth discussing, I think. >=20 > For more specific comments: >=20 > =3D=3D > It is true that AS paths can be resolved from IP address-based paths, > which can be retrieved by network management tools (e.g., traceroute). > Hence, ASes do not have to provide AS paths because applications can > resolve AS paths without support of ASes. However, it is an ongoing > work to assign appropriate AS numbers to routers [Huffaker10]. >=20 > I wonder why you wouldn't start with just peering to the BGP peers = that > you can, and pulling a database into a torrent, so you have this as a > "background reference?" Then you could consult this database first, = and > if the destination is not found there, then use other techniques? You > could also use some sort of location type service to choose a table = that > would provide the closest view to your current location as a base = --the > table from a provider as close to where you are as possible. > This would also be "publicly available information," I think, = something > like having a "private P-2-P route view?" > Or this covered in section 4.1? >=20 > =3D=3D > The algorithms based on paths analysis have a difficulty in applying = the > inferred AS to the cost computation because there are lots of missing > links, which have not been inferred. >=20 > It seems like another way to estimate relationships would be based on > the routes actually advertised. For instance, if an AS receives a lot = of > routes at 24 bits, and then sends those out plus a shorter length = prefix > that covers them, then the relationship is almost certainly transit, > rather than peer (?). This intuition could be completely wrong, = though. >=20 > =3D=3D >=20 > Overall, this is a good start --given the caveat above about = heuristics > based on current business models. There are some places where we might > could gather more specific information. >=20 > Perhaps the only real option, long term, is something like a PSV, or > other graph overlay on BGP? >=20 > :-) >=20 > Russ > _______________________________________________ > p2prg mailing list > p2prg@irtf.org > http://www.irtf.org/mailman/listinfo/p2prg >=20 --=20 Hirochika Asai , The University of Tokyo