From huai@cse.ohio-state.edu Mon May 3 07:09:19 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F35B3A6CE4 for ; Mon, 3 May 2010 07:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.001 X-Spam-Level: ** X-Spam-Status: No, score=2.001 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzGrJnxuQLhT for ; Mon, 3 May 2010 07:09:17 -0700 (PDT) Received: from cse.ohio-state.edu (mail.cse.ohio-state.edu [164.107.115.49]) by core3.amsl.com (Postfix) with ESMTP id 7F7D13A6CE3 for ; Mon, 3 May 2010 07:09:12 -0700 (PDT) Received: from yhuaiPC (dhcp-128-146-87-231.osuwireless.ohio-state.edu [128.146.87.231]) (authenticated bits=0) by cse.ohio-state.edu (8.12.11.20060308/8.12.11) with ESMTP id o43E9dqZ020851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 3 May 2010 10:09:40 -0400 (EDT) From: "huai" To: Date: Mon, 3 May 2010 10:08:43 -0400 Message-ID: <000001caeaca$23f6ca30$6be45e90$@ohio-state.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CAEAA8.9CE52A30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHK0dVQAvbs76BnI06lyD8YxLQwVw== Content-Language: en-us Subject: [alto] TopBT: a topology-aware and infrastructure-independent BitTorrent client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 14:09:19 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CAEAA8.9CE52A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, I am a developer of "TopBT", a topology-aware bittorrent client. This work was presented on IEEE INFOCOM 2010, San Diego. In TopBT, we use lightweight measurement (TCP Ping) to probe network distances of peers and then use a new unchoking algorithm to reduce unnecessary Internet traffic while trying to retain a decent downloading rate. I think this work is relevant to ALTO, so I am posting this work here. We will be very glad to hear any comment from you. Project website: http://topbt.cse.ohio-state.edu/ You can access the paper and slides from: http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/abs10-1.html http://topbt.cse.ohio-state.edu/TopBT-talk-INFOCOM10.pptx This work has already accumulated a certain number of users, as you can see from our weekly updated map of TopBT users: http://topbt.cse.ohio-state.edu/topbt-usermaps.php Thank you very much! Yin Huai ------=_NextPart_000_0001_01CAEAA8.9CE52A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = All,

I am a developer of "TopBT", a topology-aware bittorrent client. This work was presented on IEEE INFOCOM = 2010, San Diego. In TopBT, we = use lightweight measurement (TCP Ping) to probe network distances of peers and then use a new = unchoking algorithm to reduce unnecessary Internet traffic while trying to retain a = decent downloading rate. I think = this work is relevant to ALTO, so I am posting this work here. We will be very glad to hear any comment = from you.

Project website: http://topbt.cse.ohio-state.edu/<= span style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:black'> You can access the paper and slides from:

http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publica= tions/abs10-1.html

http://topbt.cse.ohio-state.edu/TopBT-talk-INFOCOM1= 0.pptx

This work has already accumulated a certain number of = users, as you can see from our weekly updated map of TopBT users:&n= bsp;http://topbt.cse.ohio-state.edu/topbt-usermaps.php<= /span>

Thank you very much!

Yin = Huai

------=_NextPart_000_0001_01CAEAA8.9CE52A30-- From richard.alimi@gmail.com Tue May 11 22:52:11 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4103428C0F8 for ; Tue, 11 May 2010 22:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl6T+d+a1I1u for ; Tue, 11 May 2010 22:52:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0DCC43A6AD9 for ; Tue, 11 May 2010 22:52:09 -0700 (PDT) Received: by wwb28 with SMTP id 28so1034060wwb.31 for ; Tue, 11 May 2010 22:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=dnp6F0TjkXReMTXsM3QB2dW1M+SPWsMLoDVSIG52HEk=; b=Xg/pLncG4mVgHSSSjzDBZMxOcsrcBiLunLHKvm0aSck+H9fYtU9B+/VmCvj1oVHq4o Cwt+E4ezvqydgrknYhXfs1ok85DZsOFVObYxXtuOD3bUzSdU3qcOcLdzeHZjXisVipS8 JK4Mpr7/v/tpfzfpRWJwgIfSUdy2fhUDaIuLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=mKMDGtlQWPMxemdaBWcjqPT0F3CWkHhKFaxLyi72b/dUmqJrYaWhRAdoCI4NBZx+Sn 4nDi21+fBeyhchjL2z6/cr93oNEo5b0sZ9VU8anXck9aknuA5D0EU8I0N/tKX6WJ1gMU i4K3GRE3b32knFBOGU5q8mFz6ivxysbhtTaY4= MIME-Version: 1.0 Received: by 10.216.86.6 with SMTP id v6mr3973811wee.185.1273643514996; Tue, 11 May 2010 22:51:54 -0700 (PDT) Sender: richard.alimi@gmail.com Received: by 10.216.166.147 with HTTP; Tue, 11 May 2010 22:51:54 -0700 (PDT) Date: Wed, 12 May 2010 01:51:54 -0400 X-Google-Sender-Auth: EQ1V3OWEwDrSU-oI3uQqNrH0jq0 Message-ID: From: Richard Alimi To: alto@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [alto] ALTO Protocol Encoding X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 05:52:11 -0000 Hi All, We are currently revising the ALTO Protocol draft following the feedback received at IETF77. There was much helpful feedback, including a suggestion of an alternative, fully-RESTful, approach to the protocol. One of the possible changes to make the protocol truly RESTful would be to define a single (or few) entry point for discovering resources available at the ALTO Server (i.e., services and various resources within those services); the returned document would be an index for available resources and their corresponding URLs. A previous incarnation of the protocol draft (pre-WG-document-days, see http://tools.ietf.org/html/draft-penno-alto-protocol-01#page-19) used a similar approach, but the argument was made that this made the protocol more complicated than it really needed to be. Thus, the current protocol instead follows a pattern similar to that used in many public services deployed today, where URLs are explicitly defined. There are other aspects of the protocol that might be changed to make it fully RESTful (see the thread begun by Martin Thomson: http://www.ietf.org/mail-archive/web/alto/current/msg00632.html for a more complete discussion), but the above is probably the first one which the WG should agree on. While a fully RESTful approach may provide more flexibility for the ALTO Service, but it is unclear whether this flexibility is needed in our context. In other words, we are looking for consensus and use-cases as opposed to being fully RESTful just from a compliance perspective. Thus, we are looking for input from the WG. Taking into account all previous feedback, it looks like (in our opinion) there is no consensus to change the current direction. At the current stage, we plan to update the draft to explicitly clarify the design choices that were made and avoid claiming that the service is RESTful (to avoid abusing the term). Thanks, Rich and Reinaldo From enrico.marocco@telecomitalia.it Thu May 20 08:01:10 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2973A6C1E for ; Thu, 20 May 2010 08:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.85 X-Spam-Level: * X-Spam-Status: No, score=1.85 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIWrHVcG8MFA for ; Thu, 20 May 2010 08:01:09 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 4F1403A6CE5 for ; Thu, 20 May 2010 08:00:57 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 May 2010 17:00:46 +0200 Received: from [163.162.173.11] (163.162.173.11) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 May 2010 17:00:45 +0200 Message-ID: <4BF54EAF.6070800@telecomitalia.it> Date: Thu, 20 May 2010 17:01:03 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: "alto@ietf.org" X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080008080403080106020005" Cc: "Vijay K. Gurbani" Subject: [alto] Virtual Interim -- Agenda Requests X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 15:01:10 -0000 --------------ms080008080403080106020005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi folks, as anticipated in April, the ALTO working group will have a 2-hour virtual interim meeting on June 16. To request a slot on the agenda simply send a private email to the chairs with a short description of the topic and the desired time for discussion. The cutoff date for agenda requests and draft submissions is June 2. As for regular meetings, issues related to working group documents will get highest priority in meeting time allocation. An official announcement from the IETF secretariat will follow soon. -- Ciao, Enrico --------------ms080008080403080106020005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwNTIw MTUwMTAzWjAjBgkqhkiG9w0BCQQxFgQUciEnCsMPXhV9VdyvdTqsqN9YOEkwXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBALdLRJ71GcBi8xOthfMr UI1jUBWriSss2wy3rfHDQJONqdGmIyopW+V9BL/NAfKT+haBBbJIvwQkD+2P4w3Tvo1fUJUj g6IP9mVXeScHkhnTVZ5oOuHMa9TnQJreFISGqxvlQjzW7Qp0Pabvs6tMyop+/jJKWbm85XAa H/fbAuM1whXAldjXHD2r/DuyyNgoYFWnfrQOQRAfLklYVzrEv3INxbeSLjsPVubbYIVnOEJ7 mdiKp9oUDBmcDxyu0lFotYA9wJgRaYPGQUCmh1yQKsv6DOcXzZDCUwHoYoKQK+YnyaaIbLhX QwnQZ/hJFCoWIKsdQdDkEZxIhTy0tW3zOLYAAAAAAAA= --------------ms080008080403080106020005-- From melodysong@huawei.com Thu May 20 17:50:23 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5DB63A68E6 for ; Thu, 20 May 2010 17:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.986 X-Spam-Level: * X-Spam-Status: No, score=1.986 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE9dfC5Q0lZ2 for ; Thu, 20 May 2010 17:50:23 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 402B53A6A13 for ; Thu, 20 May 2010 17:48:59 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Q00AIPVL6TQ@szxga01-in.huawei.com> for alto@ietf.org; Fri, 21 May 2010 08:48:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Q007L5VL6ST@szxga01-in.huawei.com> for alto@ietf.org; Fri, 21 May 2010 08:48:42 +0800 (CST) Received: from s64081a ([10.138.84.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2Q00HCGVL2HW@szxml06-in.huawei.com> for alto@ietf.org; Fri, 21 May 2010 08:48:42 +0800 (CST) Date: Fri, 21 May 2010 08:48:42 +0800 From: Song Haibin To: alto@ietf.org Message-id: <002f01caf87f$5c434d10$14c9e730$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acr4f1ZdLzTFdrDSSbGEnKxjt4G0BA== x-cr-hashedpuzzle: AJb5 AjjY BeEW Blat CP7J EVjS EgXG FlHw GAhm GQ0Z HKUm HfTQ H7ak JV5s LDLe Mfb0; 1; YQBsAHQAbwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {1FA4C60B-4E6B-4549-8C0D-D3EC4D610AF6}; bQBlAGwAbwBkAHkAcwBvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Fri, 21 May 2010 00:48:32 GMT;QQBMAFQATwAgAGMAbABpAGUAbgB0AA== x-cr-puzzleid: {1FA4C60B-4E6B-4549-8C0D-D3EC4D610AF6} Subject: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 00:50:24 -0000 For tracker based p2p applications, some guys proposed to embed the ALTO client within the tracker, so that the p2p clients do not have to be changed. But one additional thought comes into mind, peers usually exchange peer list among themselves, does a peer also have to implement ALTO client to select peers from these candidates got from other peers? Xie Xie, Haibin From rpenno@juniper.net Thu May 20 20:58:33 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C8C3A7CAB for ; Thu, 20 May 2010 20:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l8qA+EiHMMT for ; Thu, 20 May 2010 20:58:33 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 715193A7395 for ; Thu, 20 May 2010 19:51:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS/X1JvN1HZWKQVzCfwv6NQm2pvipAup3@postini.com; Thu, 20 May 2010 19:51:21 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 20 May 2010 19:50:26 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 20 May 2010 22:50:26 -0400 From: Reinaldo Penno To: Song Haibin , "alto@ietf.org" Date: Thu, 20 May 2010 22:50:24 -0400 Thread-Topic: [alto] ALTO client Thread-Index: Acr4f1ZdLzTFdrDSSbGEnKxjt4G0BAAEQXhF Message-ID: In-Reply-To: <002f01caf87f$5c434d10$14c9e730$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.4.0.100208 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 03:58:34 -0000 Hi, On 5/20/10 5:48 PM, "Song Haibin" wrote: > For tracker based p2p applications, some guys proposed to embed the ALTO > client within the tracker, so that the p2p clients do not have to be > changed. But one additional thought comes into mind, peers usually exchan= ge > peer list among themselves, does a peer also have to implement ALTO clien= t > to select peers from these candidates got from other peers? I would say no. ALTO was optional from the beginning since the idea is that clients can always fall back to original behavior in case of disruption. Interesting question what would happen if you control the tracker (as in your example) but peers can exchange info that ultimately is based on the original selection done at the tracker. You will loose some localization bu= t without DHT there is no other place to get peers from, therefore inter-AS traffic might still be curbed. >=20 > Xie Xie, > Haibin >=20 >=20 >=20 > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto From melodysong@huawei.com Thu May 20 22:42:14 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE3E3A701E for ; Thu, 20 May 2010 22:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.949 X-Spam-Level: X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[AWL=0.948, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HGB0mnx8XSm for ; Thu, 20 May 2010 22:42:13 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 27A6B3A7E69 for ; Thu, 20 May 2010 21:07:20 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2R00K684RZPN@szxga03-in.huawei.com> for alto@ietf.org; Fri, 21 May 2010 12:07:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2R00B364RZGW@szxga03-in.huawei.com> for alto@ietf.org; Fri, 21 May 2010 12:07:11 +0800 (CST) Received: from s64081a ([10.138.84.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2R00FWI4RW5J@szxml04-in.huawei.com> for alto@ietf.org; Fri, 21 May 2010 12:07:11 +0800 (CST) Date: Fri, 21 May 2010 12:07:09 +0800 From: Song Haibin In-reply-to: To: 'Reinaldo Penno' , alto@ietf.org Message-id: <003d01caf89b$15362610$3fa27230$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acr4f1ZdLzTFdrDSSbGEnKxjt4G0BAAEQXhFAAHej2A= References: <002f01caf87f$5c434d10$14c9e730$@com> Subject: Re: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 05:42:14 -0000 Hi Reinaldo, Thanks for your reply. See comments in line. > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Friday, May 21, 2010 10:50 AM > To: Song Haibin; alto@ietf.org > Subject: Re: [alto] ALTO client > > Hi, > > On 5/20/10 5:48 PM, "Song Haibin" wrote: > > > For tracker based p2p applications, some guys proposed to embed the > ALTO > > client within the tracker, so that the p2p clients do not have to be > > changed. But one additional thought comes into mind, peers usually > exchange > > peer list among themselves, does a peer also have to implement ALTO > client > > to select peers from these candidates got from other peers? > > I would say no. ALTO was optional from the beginning since the idea is that > clients can always fall back to original behavior in case of disruption. > > Interesting question what would happen if you control the tracker (as in > your example) but peers can exchange info that ultimately is based on the > original selection done at the tracker. You will loose some localization but > without DHT there is no other place to get peers from, therefore inter-AS > traffic might still be curbed. > A peer can get peers in the same swarm from the connected neighbors in the existing p2p applications, even without DHT. I don't know how much difference there will be if the peer also implements the ALTO client. Haibin > > > > Xie Xie, > > Haibin > > > > > > > > _______________________________________________ > > alto mailing list > > alto@ietf.org > > https://www.ietf.org/mailman/listinfo/alto From root@core3.amsl.com Fri May 21 15:00:01 2010 Return-Path: X-Original-To: alto@ietf.org Delivered-To: alto@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 59B573A68B1; Fri, 21 May 2010 15:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100521220001.59B573A68B1@core3.amsl.com> Date: Fri, 21 May 2010 15:00:01 -0700 (PDT) Cc: alto@ietf.org Subject: [alto] ALTO WG Virtual Interim Meeting, June 16, 2010 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 22:00:01 -0000 The ALTO working group will hold a Virtual Interim Meeting on June 16, 16:00-18:00 CET (07:00-09:00 on the Pacific coast, 22:00-24:00 in eastern China). Meeting details, including WebEx information, will be announced on the ALTO WG mailing list: http://www.ietf.org/mail-archive/web/alto/current/maillist.html From sebi@smtp.ehlo.wurstkaes.de Sat May 22 15:03:39 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E2A3A6783 for ; Sat, 22 May 2010 15:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.35 X-Spam-Level: ** X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDzUpZLQsasB for ; Sat, 22 May 2010 15:03:38 -0700 (PDT) Received: from smtp.ehlo.wurstkaes.de (r01e.ehlo.wurstkaes.de [82.139.198.28]) by core3.amsl.com (Postfix) with ESMTP id 48CA33A63D3 for ; Sat, 22 May 2010 15:03:37 -0700 (PDT) Received: from sebi by smtp.ehlo.wurstkaes.de with local (Exim 4.69) (envelope-from ) id 1OFwmx-0002T1-FM; Sun, 23 May 2010 00:03:23 +0200 Date: Sun, 23 May 2010 00:03:23 +0200 From: Sebastian Kiesel To: Song Haibin Message-ID: <20100522220323.GG4692@nat01e.ehlo.wurstkaes.de> References: <002f01caf87f$5c434d10$14c9e730$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002f01caf87f$5c434d10$14c9e730$@com> Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.18 (2008-05-17) Cc: alto@ietf.org Subject: Re: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 22:03:39 -0000 On Fri, May 21, 2010 at 08:48:42AM +0800, Song Haibin wrote: > For tracker based p2p applications, some guys proposed to embed the ALTO > client within the tracker, so that the p2p clients do not have to be > changed. It is a good question wheter it is more practical to change only the tracker or all the peers in order to deploy ALTO. However, I think this is not the most important question when we ask ourselves where to place the ALTO client! I believe it is more important that we ask: Which configuration will yield better results for the peer selection? Please read section 2.1 of draft-kiesel-alto-3pdisc-02, there we explain why we believe the ALTO client in the tracker will give better results as opposed to putting the ALTO client in the peers. If you have questions or another point of view pleas let us know, we'd be happy to discuss! > But one additional thought comes into mind, peers usually exchange > peer list among themselves, does a peer also have to implement ALTO client > to select peers from these candidates got from other peers? I am not sure about this. Probably it would be the best if there was an ALTO client in the tracker and in each peer. But maybe in some scenarios it would be sufficient to have an ALTO client in the tracker, in order to get a "good" list of initial neighbors. For the peers you learn from your neigbors it might be sufficient to assess them by doing measurements. If you are interested not only in performance improvements but also in reducing ISP's costs you probably need to always ask ALTO. Thanks, Sebastian From enrico.marocco@telecomitalia.it Mon May 24 02:14:08 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905C93A6D48 for ; Mon, 24 May 2010 02:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.853 X-Spam-Level: * X-Spam-Status: No, score=1.853 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo0skHLJGxww for ; Mon, 24 May 2010 02:14:07 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 1B9023A6CE5 for ; Mon, 24 May 2010 02:14:06 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 24 May 2010 11:13:47 +0200 Received: from [163.162.173.11] (163.162.173.11) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 24 May 2010 11:13:46 +0200 Message-ID: <4BFA4365.2010001@telecomitalia.it> Date: Mon, 24 May 2010 11:14:13 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Sebastian Kiesel References: <002f01caf87f$5c434d10$14c9e730$@com> <20100522220323.GG4692@nat01e.ehlo.wurstkaes.de> In-Reply-To: <20100522220323.GG4692@nat01e.ehlo.wurstkaes.de> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050504060804010501080504" Cc: "alto@ietf.org" Subject: Re: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 09:14:08 -0000 --------------ms050504060804010501080504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sebastian Kiesel wrote: >> For tracker based p2p applications, some guys proposed to embed the ALTO >> client within the tracker, so that the p2p clients do not have to be >> changed. > > It is a good question wheter it is more practical to change only the > tracker or all the peers in order to deploy ALTO. > However, I think this is not the most important question when we > ask ourselves where to place the ALTO client! > > I believe it is more important that we ask: Which configuration will > yield better results for the peer selection? Please read section > 2.1 of draft-kiesel-alto-3pdisc-02, there we explain why we believe the > ALTO client in the tracker will give better results as opposed to > putting the ALTO client in the peers. If you have questions or another > point of view pleas let us know, we'd be happy to discuss! I don't have a strong opinion whether it will be better to have the client embedded in the peers or in the tracker, but I see good points on both sides. To add some information to the discussion, I've uploaded at the following link some charts showing the observed number of peers a BitTorrent client got to know while downloading a particular file in swarms of different size: http://ubiq.tilab.com/~enrico/graphs/ While the peers returned by the tracker -- the initial rise in the graphs -- are important in the first phase of the download, the number of peers discovered during the entire download period gets often very close to the size of the swarm. -- Ciao, Enrico --------------ms050504060804010501080504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwNTI0 MDkxNDEzWjAjBgkqhkiG9w0BCQQxFgQUhS23muF5hJWYdrvM+6jE7AIPKQQwXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAMv1SO4eKaVfixfdlYtW LLr0pPNS4p7hWYaakCZiDmiXcWci7X1sCMoyHbheWWxYE9d2JrzFUhhNGFbM0hq4tOQrXYuO XBKE1faKIJB+sl/LzWZyJ71WCVSkpjgVTmttaxf+pZ+RmlsX50pzpKRYfdAlF7CXzASxj5mn k7z5aofxDXR4/XZTk7t7qpdhEIQwCePC6/dIDxu3wHjiOgcPTZK6uKtbNH5q0Ao0ZxQ4WAEX poErN4cCDerLQzOElGfYVB1zIComTfag2HamgRF+5n8isKK5jJNvXqK6HWFwXE2RufWUIv+h YoVhTwVYocHlCiYuUAktmsLDwxJdfCHk/CQAAAAAAAA= --------------ms050504060804010501080504-- From melodysong@huawei.com Tue May 25 01:33:16 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A623A6D99 for ; Tue, 25 May 2010 01:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.895 X-Spam-Level: * X-Spam-Status: No, score=1.895 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXRsOAtjioYB for ; Tue, 25 May 2010 01:33:15 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DF0A73A6917 for ; Tue, 25 May 2010 01:33:14 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Y00JLWVQN5I@szxga03-in.huawei.com> for alto@ietf.org; Tue, 25 May 2010 16:32:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Y000BPVQMXH@szxga03-in.huawei.com> for alto@ietf.org; Tue, 25 May 2010 16:32:46 +0800 (CST) Received: from s64081a ([10.138.84.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2Y00AVSVQGM6@szxml06-in.huawei.com> for alto@ietf.org; Tue, 25 May 2010 16:32:46 +0800 (CST) Date: Tue, 25 May 2010 16:32:40 +0800 From: Song Haibin In-reply-to: <4BFA4365.2010001@telecomitalia.it> To: 'Enrico Marocco' , 'Sebastian Kiesel' Message-id: <006301cafbe4$d6d24460$8476cd20$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acr7IZg76TDuY+w3QhGUVwkG2duxrwAwfDRA References: <002f01caf87f$5c434d10$14c9e730$@com> <20100522220323.GG4692@nat01e.ehlo.wurstkaes.de> <4BFA4365.2010001@telecomitalia.it> Cc: alto@ietf.org Subject: Re: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 08:33:16 -0000 > -----Original Message----- > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Sent: Monday, May 24, 2010 5:14 PM > To: Sebastian Kiesel > Cc: Song Haibin; alto@ietf.org > Subject: Re: [alto] ALTO client > > Sebastian Kiesel wrote: > >> For tracker based p2p applications, some guys proposed to embed the > ALTO > >> client within the tracker, so that the p2p clients do not have to be > >> changed. > > > > It is a good question wheter it is more practical to change only the > > tracker or all the peers in order to deploy ALTO. > > However, I think this is not the most important question when we > > ask ourselves where to place the ALTO client! > > > > I believe it is more important that we ask: Which configuration will > > yield better results for the peer selection? Please read section > > 2.1 of draft-kiesel-alto-3pdisc-02, there we explain why we believe the > > ALTO client in the tracker will give better results as opposed to > > putting the ALTO client in the peers. If you have questions or another > > point of view pleas let us know, we'd be happy to discuss! > > I don't have a strong opinion whether it will be better to have the > client embedded in the peers or in the tracker, but I see good points on > both sides. > I agree. My concern is the tradeoff between the complexity and the performance. > To add some information to the discussion, I've uploaded at the > following link some charts showing the observed number of peers a > BitTorrent client got to know while downloading a particular file in > swarms of different size: http://ubiq.tilab.com/~enrico/graphs/ > > While the peers returned by the tracker -- the initial rise in the > graphs -- are important in the first phase of the download, the number > of peers discovered during the entire download period gets often very > close to the size of the swarm. > These graphs are very interesting. Do you have some data about the total number of peers returned by tracker VS the total number got from other peers during the entire download period? BR, Haibin > -- > Ciao, > Enrico From enrico.marocco@telecomitalia.it Tue May 25 01:47:19 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087CB3A6AD3 for ; Tue, 25 May 2010 01:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.855 X-Spam-Level: * X-Spam-Status: No, score=1.855 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiW+Pp3-ABRA for ; Tue, 25 May 2010 01:47:18 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 628083A67F0 for ; Tue, 25 May 2010 01:47:17 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 May 2010 10:46:59 +0200 Received: from [163.162.173.11] (163.162.173.11) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 May 2010 10:46:58 +0200 Message-ID: <4BFB8E9F.6070207@telecomitalia.it> Date: Tue, 25 May 2010 10:47:27 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Song Haibin References: <002f01caf87f$5c434d10$14c9e730$@com> <20100522220323.GG4692@nat01e.ehlo.wurstkaes.de> <4BFA4365.2010001@telecomitalia.it> <006301cafbe4$d6d24460$8476cd20$@com> In-Reply-To: <006301cafbe4$d6d24460$8476cd20$@com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050105020602090004050309" Cc: "alto@ietf.org" Subject: Re: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 08:47:19 -0000 --------------ms050105020602090004050309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Song Haibin wrote: >> To add some information to the discussion, I've uploaded at the >> following link some charts showing the observed number of peers a >> BitTorrent client got to know while downloading a particular file in >> swarms of different size: http://ubiq.tilab.com/~enrico/graphs/ >> >> While the peers returned by the tracker -- the initial rise in the >> graphs -- are important in the first phase of the download, the number >> of peers discovered during the entire download period gets often very >> close to the size of the swarm. >> > These graphs are very interesting. Do you have some data about the total > number of peers returned by tracker VS the total number got from other peers > during the entire download period? 50, only once, at the beginning of the download. -- Ciao, Enrico --------------ms050105020602090004050309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwNTI1 MDg0NzI3WjAjBgkqhkiG9w0BCQQxFgQUllXEvuHi/9Ikhbv+lJQQcYgHYz8wXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAJg7Rhz/6nadiY77wKHW GAu19GQZ0f8zRUq72FRdI24VUqqBIOD2H8IznpzcgXbrDUkJTegi8KBrrWnphxsKvqSdNHAF Ffo6ou2zg7DBvyEeNuuHkTVlDxQpOMPOnRqrkphW2PNS29A55CM38AthRpLejtIV0wYc5lIw H20hU/4Uxgx6Gannq2IPkuXcVJGyjgf2G2dtQmmeBWN3n03CRXBHFU22CLP25CZFBjXPCwqQ 0MMf982AT4xjcg8Nu1wZ+tkgQeEuR4q9ysRdnX67KynK9+cTFgn6ARMrqTkVj4eAn4P34wMt xpgRHowP2iUmETQycReph4bz4xZhWKyB5IwAAAAAAAA= --------------ms050105020602090004050309-- From haage@net.in.tum.de Tue May 25 02:01:04 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518953A69E6 for ; Tue, 25 May 2010 02:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT8qQq22IXI9 for ; Tue, 25 May 2010 02:01:03 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 02F803A6A91 for ; Tue, 25 May 2010 02:01:02 -0700 (PDT) Received: from caramillo.net.in.tum.de (caramillo.net.in.tum.de [131.159.20.119]) by mail.net.in.tum.de (Postfix) with ESMTPSA id A6614208AE26 for ; Tue, 25 May 2010 11:00:52 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1078) From: Dirk Haage In-Reply-To: <003d01caf89b$15362610$3fa27230$@com> Date: Tue, 25 May 2010 11:00:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4328B644-576D-4EA6-8F48-44C525118A3C@net.in.tum.de> References: <002f01caf87f$5c434d10$14c9e730$@com> <003d01caf89b$15362610$3fa27230$@com> To: alto@ietf.org X-Mailer: Apple Mail (2.1078) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 09:01:04 -0000 Hi, comments below On 2010-05-21, at 06:07, Song Haibin wrote: >> On 5/20/10 5:48 PM, "Song Haibin" wrote: >>=20 >>> For tracker based p2p applications, some guys proposed to embed the >> ALTO >>> client within the tracker, so that the p2p clients do not have to be >>> changed. But one additional thought comes into mind, peers usually >> exchange >>> peer list among themselves, does a peer also have to implement ALTO >> client >>> to select peers from these candidates got from other peers? >>=20 >> I would say no. ALTO was optional from the beginning since the idea = is > that >> clients can always fall back to original behavior in case of = disruption. >>=20 >> Interesting question what would happen if you control the tracker (as = in >> your example) but peers can exchange info that ultimately is based on = the >> original selection done at the tracker. You will loose some = localization > but >> without DHT there is no other place to get peers from, therefore = inter-AS >> traffic might still be curbed. >>=20 >=20 > A peer can get peers in the same swarm from the connected neighbors in = the > existing p2p applications, even without DHT. I don't know how much > difference there will be if the peer also implements the ALTO client. >=20 One thing I would expect in this scenario is, that each client gets = peers from the tracker which in this case are selected by the ALTO = client within the tracker. This means most of the clients will know mostly good peers in the sense = of ALTO. The direct peer exchange will then also provide the better = peers to other clients. But this argument might only be valid if all trackers use ALTO. best regards Dirk --=20 Dipl.-Ing. Dirk Haage | Informatics VIII: +49 89 289 18019 | Network Architectures & Services haage@net.in.tum.de |Technical University of Munich MI 03.05.057, Bolzmannstr. 3, 85748 Garching bei M=FCnchen, Germany From sebi@smtp.ehlo.wurstkaes.de Tue May 25 05:50:16 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A559C3A6BB9 for ; Tue, 25 May 2010 05:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.351 X-Spam-Level: * X-Spam-Status: No, score=1.351 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyDi31SVvHrW for ; Tue, 25 May 2010 05:50:12 -0700 (PDT) Received: from smtp.ehlo.wurstkaes.de (r01e.ehlo.wurstkaes.de [82.139.198.28]) by core3.amsl.com (Postfix) with ESMTP id 7B4DB3A6B9B for ; Tue, 25 May 2010 05:50:12 -0700 (PDT) Received: from sebi by smtp.ehlo.wurstkaes.de with local (Exim 4.69) (envelope-from ) id 1OGtZt-0001cF-FE; Tue, 25 May 2010 14:49:49 +0200 Date: Tue, 25 May 2010 14:49:49 +0200 From: Sebastian Kiesel To: Enrico Marocco Message-ID: <20100525124949.GB32611@nat01e.ehlo.wurstkaes.de> References: <002f01caf87f$5c434d10$14c9e730$@com> <20100522220323.GG4692@nat01e.ehlo.wurstkaes.de> <4BFA4365.2010001@telecomitalia.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BFA4365.2010001@telecomitalia.it> Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "alto@ietf.org" Subject: Re: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 12:50:16 -0000 On Mon, May 24, 2010 at 11:14:13AM +0200, Enrico Marocco wrote: > To add some information to the discussion, I've uploaded at the > following link some charts showing the observed number of peers a > BitTorrent client got to know while downloading a particular file in > swarms of different size: http://ubiq.tilab.com/~enrico/graphs/ > > While the peers returned by the tracker -- the initial rise in the > graphs -- are important in the first phase of the download, the number > of peers discovered during the entire download period gets often very > close to the size of the swarm. Isn't this initial phase when joining a swarm the one where ALTO can be most beneficial? IIRC this insight was captured in our charter: "The Working Group will design ... service ... to perform better-than-random *** INITIAL *** peer selection." If we are talking about the application's performance or QoE only: It is no suprise that, if we wait long enough, we can find enough fast neighbors just by gossipping and throughput probing (if fast neighbors actually exist in the swarm). But not trying to optimize the tracker response would mean that we assume, that the tracker is an irrelvant bootstrap helper only, while the "real" neighbor discovery is done by other means, right? If we think of the general case with arbitrary rating criteria that cannot be measured(e.g., monetary cost for data transmission to the candidate peer), all candidate peers should be evaluated by ALTO, no matter whether they were learnt from the tracker or discovered by some other means. Therefore we need an ALTO client in the peer. Nevertheless, the quality (i.e., long-term impact) of the tracker response can be improved by performing an ALTO-guided selection of peers in the tracker. Thanks, Sebastian From enrico.marocco@telecomitalia.it Tue May 25 06:43:30 2010 Return-Path: X-Original-To: alto@core3.amsl.com Delivered-To: alto@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1C53A6B0C for ; Tue, 25 May 2010 06:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.856 X-Spam-Level: * X-Spam-Status: No, score=1.856 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOVooYT9ZctY for ; Tue, 25 May 2010 06:43:29 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id EEFFB3A6BC1 for ; Tue, 25 May 2010 06:43:27 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 May 2010 15:43:14 +0200 Received: from [163.162.173.11] (163.162.173.11) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 May 2010 15:43:04 +0200 Message-ID: <4BFBD404.3090102@telecomitalia.it> Date: Tue, 25 May 2010 15:43:32 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Sebastian Kiesel References: <002f01caf87f$5c434d10$14c9e730$@com> <20100522220323.GG4692@nat01e.ehlo.wurstkaes.de> <4BFA4365.2010001@telecomitalia.it> <20100525124949.GB32611@nat01e.ehlo.wurstkaes.de> In-Reply-To: <20100525124949.GB32611@nat01e.ehlo.wurstkaes.de> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060704040003060401080600" Cc: "alto@ietf.org" Subject: Re: [alto] ALTO client X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 13:43:31 -0000 --------------ms060704040003060401080600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sebastian Kiesel wrote: >> To add some information to the discussion, I've uploaded at the >> following link some charts showing the observed number of peers a >> BitTorrent client got to know while downloading a particular file in >> swarms of different size: http://ubiq.tilab.com/~enrico/graphs/ >> >> While the peers returned by the tracker -- the initial rise in the >> graphs -- are important in the first phase of the download, the number >> of peers discovered during the entire download period gets often very >> close to the size of the swarm. > > Isn't this initial phase when joining a swarm the one where ALTO > can be most beneficial? IIRC this insight was captured in our > charter: "The Working Group will design ... service ... to perform > better-than-random *** INITIAL *** peer selection." Well, I'd say that ALTO information may be useful in any selection process that would be random otherwise, regardless of whether it happens when joining the swarm or, e.g., in the BitTorrent optimistic unchoke recurring phase. In the spirit of the charter, at least as I read it, "initial" peer selection is intended as opposed to application-specific peer selection (e.g. tit-for-tat in BitTorrent). > If we are talking about the application's performance or QoE only: > It is no suprise that, if we wait long enough, we can find enough fast > neighbors just by gossipping and throughput probing (if fast neighbors > actually exist in the swarm). But not trying to optimize the tracker > response would mean that we assume, that the tracker is an irrelvant > bootstrap helper only, while the "real" neighbor discovery is done > by other means, right? > > > If we think of the general case with arbitrary rating criteria that > cannot be measured(e.g., monetary cost for data transmission to the > candidate peer), all candidate peers should be evaluated by ALTO, no > matter whether they were learnt from the tracker or discovered by some > other means. Therefore we need an ALTO client in the peer. Nevertheless, > the quality (i.e., long-term impact) of the tracker response can be > improved by performing an ALTO-guided selection of peers in the tracker. I agree. Again, I really don't have an opinion whether an ALTO client would be best embedded in the tracker or in the peers, but I don't even see a reason why it could not be embedded in both. -- Ciao, Enrico --------------ms060704040003060401080600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwNTI1 MTM0MzMyWjAjBgkqhkiG9w0BCQQxFgQUFxJt6BadJUw/1bfCtSWp22tMlvswXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAAb2XuGrTM+FOZjHC3kd XmERarPgUebAyCoHUlR4aKinpGhSK1YIrwmNuvF3plok44aPVq16z4HqChVo1yeF2dKWousD 2cCPYI6K/G4cS3H/FKhPjYRLLfLIxnoFK0hMUh3hkqR5zz5ssyh5+RpirGN6qnDPHKBo9Eri 9OHcWDulASawTCLWb3RAphVt2MN2umwqNYuGiPSP6xKCeJ5yIeKX6MwQoVZJ/EhjHk3BmvEX /lt+s7ojNXp1Of7nam7KyXET+XcvPsFqzNZUvgot/zBImNY8A4vSjGWC1NbsZm+eNdK89KEl iBE4WuSKUVxa/IHwMo2u4Q6MVn6TFymU1L0AAAAAAAA= --------------ms060704040003060401080600-- From root@core3.amsl.com Mon May 31 19:45:02 2010 Return-Path: X-Original-To: alto@ietf.org Delivered-To: alto@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BC2F33A686D; Mon, 31 May 2010 19:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100601024502.BC2F33A686D@core3.amsl.com> Date: Mon, 31 May 2010 19:45:02 -0700 (PDT) Cc: alto@ietf.org Subject: [alto] I-D Action:draft-ietf-alto-protocol-04.txt X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization $alto$ WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 02:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application-Layer Traffic Optimization Working Group of the IETF. Title : ALTO Protocol Author(s) : R. Alimi, et al. Filename : draft-ietf-alto-protocol-04.txt Pages : 57 Date : 2010-05-31 Networking applications today already have access to a great amount of Inter-Provider network topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to be downloaded by clients. What is missing is knowledge of the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes a protocol implementing the ALTO Service. While such service would primarily be provided by the network (i.e., the ISP), content providers and third parties could also operate this service. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-alto-protocol-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-alto-protocol-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-31193731.I-D@ietf.org> --NextPart--