From vkg@bell-labs.com Fri Apr 2 09:36:54 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 D75823A6939 for ; Fri, 2 Apr 2010 09:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.131
X-Spam-Level: *
X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 oeMwPdnaV+a4 for ; Fri, 2 Apr 2010 09:36:54 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A306C3A6933 for ; Fri, 2 Apr 2010 09:36:54 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o32GbSwW019017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Apr 2010 11:37:28 -0500 (CDT)
Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o32GbSbM028201 for ; Fri, 2 Apr 2010 11:37:28 -0500 (CDT)
Message-ID: <4BB61D87.1000706@bell-labs.com>
Date: Fri, 02 Apr 2010 11:38:31 -0500
From: "Vijay K. Gurbani"
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3
MIME-Version: 1.0
To: alto
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: [alto] IETF 77 Minutes
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, 02 Apr 2010 16:36:54 -0000
Folks: A draft version of minutes from IETF 77 ALTO WG
meeting has been posted at the URL below. The minutes
include links to slides as well as individual audio files
for each discussion.
http://www.ietf.org/proceedings/10mar/minutes/alto.html
Please review the minutes and submit any correction to the
chairs by April 20, 2010.
Thank you,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
From richard_woundy@cable.comcast.com Mon Apr 5 06:42:52 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 9599528C0EE for ; Mon, 5 Apr 2010 06:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.863
X-Spam-Level:
X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8]
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 4tO8r7bz87sf for ; Mon, 5 Apr 2010 06:42:51 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 5A00E28C0F2 for ; Mon, 5 Apr 2010 06:42:50 -0700 (PDT)
Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.76048874; Mon, 05 Apr 2010 09:42:44 -0400
Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 09:42:44 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 5 Apr 2010 09:42:24 -0400
Message-ID:
In-Reply-To: <4BB61D87.1000706@bell-labs.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [alto] IETF 77 Minutes
Thread-Index: AcrSgszYSCNfk7wMTXCz8firUv8Q2wCQt/Sg
References: <4BB61D87.1000706@bell-labs.com>
From: "Woundy, Richard"
To: "Vijay K. Gurbani" , "alto"
X-OriginalArrivalTime: 05 Apr 2010 13:42:44.0330 (UTC) FILETIME=[DEB17CA0:01CAD4C5]
Subject: Re: [alto] IETF 77 Minutes
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, 05 Apr 2010 13:42:52 -0000
Just a quick clarification under Deployment considerations.
>Rich: some of us a year ago thought about this, lost the information
because we didn't capture. Make a WG item, it will happen again.
I think I said, please make this a WG item so we *don't* lose this
information again. :)
-- Rich
-----Original Message-----
From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf Of
Vijay K. Gurbani
Sent: Friday, April 02, 2010 12:39 PM
To: alto
Subject: [alto] IETF 77 Minutes
Folks: A draft version of minutes from IETF 77 ALTO WG
meeting has been posted at the URL below. The minutes
include links to slides as well as individual audio files
for each discussion.
http://www.ietf.org/proceedings/10mar/minutes/alto.html
Please review the minutes and submit any correction to the
chairs by April 20, 2010.
Thank you,
- vijay
--=20
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
From vkg@bell-labs.com Mon Apr 5 14:54:34 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 856CF3A67E1 for ; Mon, 5 Apr 2010 14:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlGoYQFb-Eay for ; Mon, 5 Apr 2010 14:54:33 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 397BC3A6A60 for ; Mon, 5 Apr 2010 14:54:32 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o35LsTOm007090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 16:54:29 -0500 (CDT)
Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o35LsTNj026044; Mon, 5 Apr 2010 16:54:29 -0500 (CDT)
Message-ID: <4BBA5C56.6090804@bell-labs.com>
Date: Mon, 05 Apr 2010 16:55:34 -0500
From: "Vijay K. Gurbani"
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3
MIME-Version: 1.0
To: "Woundy, Richard"
References: <4BB61D87.1000706@bell-labs.com>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: alto
Subject: Re: [alto] IETF 77 Minutes
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, 05 Apr 2010 21:54:34 -0000
On 04/05/2010 08:42 AM, Woundy, Richard wrote:
> Just a quick clarification under Deployment considerations.
>
>> Rich: some of us a year ago thought about this, lost the information
> because we didn't capture. Make a WG item, it will happen again.
>
> I think I said, please make this a WG item so we *don't* lose this
> information again. :)
Rich: Corrected as you note above. The amended minutes are on
the same URL:
http://www.ietf.org/proceedings/10mar/minutes/alto.html
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
From hocs@itri.org.tw Wed Apr 7 19:42:37 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 A97EA3A67F7 for ; Wed, 7 Apr 2010 19:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -90.169
X-Spam-Level:
X-Spam-Status: No, score=-90.169 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_TW=1.335, HELO_MISMATCH_TW=0.994, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 W65t8lCo7GXI for ; Wed, 7 Apr 2010 19:42:36 -0700 (PDT)
Received: from maillog2.itri.org.tw (unknown [61.61.254.185]) by core3.amsl.com (Postfix) with ESMTP id 9B1323A62C1 for ; Wed, 7 Apr 2010 19:42:35 -0700 (PDT)
Received: from mail.itri.org.tw (mail.itri.org.tw [140.96.157.2]) by maillog2.itri.org.tw with ESMTP id o382fuAl007995 for ; Thu, 8 Apr 2010 10:42:01 +0800 (CST) (envelope-from hocs@itri.org.tw)
Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id o382fk5c002548 for ; Thu, 8 Apr 2010 10:41:46 +0800 (CST)
Received: from msx.itri.org.tw ([140.96.147.139]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id o382fhhl002481 for ; Thu, 8 Apr 2010 10:41:46 +0800 (CST)
Received: from 52092035394 (140.96.150.239) by smtpx.itri.org.tw (140.96.147.139) with Microsoft SMTP Server id 8.2.247.2; Thu, 8 Apr 2010 10:41:39 +0800
From: JeffreyHo
To:
Date: Thu, 8 Apr 2010 10:41:39 +0800
Message-ID:
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01CAD708.122BC8D0"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcrWxQPbOH2K/cAERf+to3l2ZWEzTQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-MAIL: maillog2.itri.org.tw o382fuAl007995
Subject: [alto] just wondering if ISPs are willing to reveal its network information for ALTO service
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, 08 Apr 2010 02:42:37 -0000
------=_NextPart_000_004E_01CAD708.122BC8D0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 7bit
Dear all,
I am new here. I and my colleagues are designing P2P Streaming Service as
software vendors do. I think ALTO service is very helpful for enhancing P2P
service performance.
>From my point of view, I think the most important component will be ALTO
Server collecting network and traffic information provided by network
operators (say ISP). But I am just wondering if ISPs are willing to reveal
its network information. Do you think the probability of ISP revealing such
information is high or low? Without ALTO Server collecting network and
traffic information from ISP, our P2P streaming service provider can do
nothing on ALTO, I think.
Thanks a lot.
BR,
Jeffrey
本信件可能包含工研院機密資訊,非指定之收件者,請勿使用或揭露本信件內容,並請銷毀此信件。
This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.
------=_NextPart_000_004E_01CAD708.122BC8D0
Content-Type: text/html; charset="big5"
Content-Transfer-Encoding: quoted-printable
just wondering if ISPs are willing to reveal its network information=
for ALTO service
Dear all,
I am new here. I and my=
colleagues are designing P2P Streaming Service as software vendors do. I=
think ALTO service is very helpful for enhancing P2P service=
performance.
From my point of view, I think=
the most important component will be ALTO Server collecting network and=
traffic information provided by network operators (say ISP). But I am just=
wondering if ISPs are willing to reveal its network information. Do you=
think the probability of ISP revealing such information is high or low?=
Without ALTO Server collecting network and traffic information from ISP,=
our P2P streaming service provider can do nothing on ALTO, I think.=
Thanks a lot.
BR,
Jeffrey
=A5=BB=ABH=A5=F3=A5i=
=AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1K=B8=EA=B0T=A1A=ABD=AB=FC=A9w=A4=A7=A6=
=AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5=A8=CF=A5=CE=A9=CE=B4=A6=C5S=A5=BB=ABH=A5=F3=
=A4=BA=AEe=A1A=A8=C3=BD=D0=BEP=B7=B4=A6=B9=ABH=A5=F3=A1C
This email may contain confidential information. Please do not use or=
disclose it in any way and delete it if you are not the intended=
recipient.
------=_NextPart_000_004E_01CAD708.122BC8D0--
From abcdmatao@gmail.com Fri Apr 9 01:29:28 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 5EF753A6822 for ; Fri, 9 Apr 2010 01:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 vLrBvWpxAH07 for ; Fri, 9 Apr 2010 01:29:24 -0700 (PDT)
Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 3F3133A67A5 for ; Fri, 9 Apr 2010 01:29:23 -0700 (PDT)
Received: by iwn27 with SMTP id 27so2192856iwn.5 for ; Fri, 09 Apr 2010 01:29:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:cc:content-type; bh=YUV/SnWXyRPP4yfxAGf43bD06x8fZKUT5mDgPPUaqMU=; b=hV8d23t9YiOVKO3qvV77nWlcZGfoH7zz4ly8BbefPz5DnGOQqwqcx2Olcapo6mbh5A uiCwGSfvnDi+aJWsLNQhpqXPWrulNF6sRvzuHg/VxR955UzX2wlw7MCEtxCOIpJb0A03 3XMqh/tSMVpwFVSRuuFyBp9pbrNsijGcUl6Rc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=UPuuGlAircKlCdhAd3nCQrYDS80kCBNOglyYqsy0Ft9+hZnjPE0jRIpPpShMhcFJMy IGM4QkK/P//G8vdWr0tZsBFCwHWZVTVISLdQEDDHSeRpREnAl9vrZETm1+tWOA+QRyJM rnTILH2/mbohBFFDxjCdv5Xg2tM6+zqY7W/OQ=
MIME-Version: 1.0
Received: by 10.231.34.12 with HTTP; Fri, 9 Apr 2010 01:29:17 -0700 (PDT)
Date: Fri, 9 Apr 2010 16:29:17 +0800
Received: by 10.231.166.68 with SMTP id l4mr597009iby.40.1270801757075; Fri, 09 Apr 2010 01:29:17 -0700 (PDT)
Message-ID:
From: Tao Ma
To: JeffreyHo
Content-Type: multipart/alternative; boundary=0050450144554f79990483c99793
Cc: alto@ietf.org, zhangchbupt@gmail.com
Subject: Re: [alto] just wondering if ISPs are willing to reveal its network information for ALTO service
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, 09 Apr 2010 08:29:28 -0000
--0050450144554f79990483c99793
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi, Jeffrey
The ALTO service tries to make P2P applications ISP-friendly. It has bee=
n
becoming a common sense that ISP and P2P application providers cooperate to
achieve the win-win situation. Therefore, ISPs have its own benefit
considerations to reveal its information to ALTO services. Of course, the
confidentiality and privacy should be guaranteed.
By the way, ALTO service may discover the information from some sources
other than ISPs. For example, ALTO server can be deployed by the third part=
y
provider which has some contracts with ISPs to get the information.
For P2P service providers, ALTO service is like an oracle that you only
needs to query. That=92s my understanding:)
Tao Ma
Beijing University of Posts and Telecommunications, Mobile lIfe and New
mEdia(MINE) Lab
---------------------------------------------------------------------------=
------------------------------------------------------
[alto] just wondering if ISPs are willing to reveal its network information
for ALTO service
||Dear all,
I am new here. I and my colleagues are designing P2P Streaming Service as
software vendors do. I think ALTO service is very helpful for enhancing P2P
service performance.
>From my point of view, I think the most important component will be ALTO
Server collecting network and traffic information provided by network
operators (say ISP). But I am just wondering if ISPs are willing to reveal
its network information. Do you think the probability of ISP revealing such
information is high or low? Without ALTO Server collecting network and
traffic information from ISP, our P2P streaming service provider can do
nothing on ALTO, I think.
Thanks a lot.
BR,
Jeffrey
--0050450144554f79990483c99793
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Hi, Jeffrey
The ALTO service tries to =
make P2P
applications ISP-friendly. It has been becoming a common sense that ISP and=
P2P
application providers cooperate to achieve the win-win situation. Therefore=
,
ISPs have its own benefit considerations to reveal its information to ALTO
services. Of course, the confidentiality and privacy should be guaranteed.<=
/span>
By the way, ALTO service may di=
scover the
information from some sources other than ISPs. For example, ALTO server can=
be
deployed by the third party provider which has some contracts with ISPs to =
get
the information.
For P2P service providers, ALTO=
service is
like an oracle that you only needs to query. That’s my understanding:=
)
Tao Ma
BeijingUniversity of Posts and=
Telecommunications, MobilelIfeand=
NewmEdia(MINE) Lab
[alt=
o] just wondering if ISPs are willing to reveal its network information for=
ALTO service
||Dear all,
I am new here. I and my coll=
eagues are=20
designing P2P Streaming Service as software vendors do. I think ALTO servic=
e is=20
very helpful for enhancing P2P service performance.
From my point of view, I thi=
nk the most=20
important component will be ALTO Server collecting network and traffic=20
information provided by network operators (say ISP). But I am just wonderin=
g if=20
ISPs are willing to reveal its network information. Do you think the probab=
ility=20
of ISP revealing such information is high or low? Without ALTO Server colle=
cting=20
network and traffic information from ISP, our P2P streaming service provide=
r can=20
do nothing on ALTO, I think.
Thanks a lot.
BR, Jeffrey
--0050450144554f79990483c99793--
From enrico.marocco@telecomitalia.it Thu Apr 15 06:37:37 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 97A863A69BB for ; Thu, 15 Apr 2010 06:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.696
X-Spam-Level: *
X-Spam-Status: No, score=1.696 tagged_above=-999 required=5 tests=[AWL=-0.185, 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 ntjVTsXIuDcB for ; Thu, 15 Apr 2010 06:37:36 -0700 (PDT)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id A78353A689C for ; Thu, 15 Apr 2010 06:36:19 -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.247.2; Thu, 15 Apr 2010 15:36:07 +0200
Received: from [163.162.173.39] (163.162.173.39) by GRFHUB701BA020.griffon.local (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 15 Apr 2010 15:36:07 +0200
Message-ID: <4BC7164B.2080501@telecomitalia.it>
Date: Thu, 15 Apr 2010 15:36:11 +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="------------ms010109050803020908090003"
Cc: "Vijay K. Gurbani"
Subject: [alto] Interim Virtual Meeting
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, 15 Apr 2010 13:37:37 -0000
--------------ms010109050803020908090003
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Hi all,
as mentioned during the last meeting, we plan to have an interim WebEx
meeting between Anaheim and Maastricht. The date we have identified is
June 16, but it may still be subject to change.
In particular, we would like to focus the meeting on progressing the
work on the protocol document, info redistribution, deployment
considerations and v4/v6 issues. If anyone would like to propose other
topics, please check well in advance with the chairs.
An official email from the IETF secretariat will follow in the following
weeks.
--
Ciao,
Enrico
--------------ms010109050803020908090003
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
AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwNDE1
MTMzNjExWjAjBgkqhkiG9w0BCQQxFgQUiCu2S6eudogz9PScJmQfbr1MMgswXwYJKoZIhvcN
AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG
SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy
MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp
ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln
biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk
MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAEuId3SJ7mTUHTqSV8Ns
ro2MLiurPQKJAVFCSDsSdKgerf5VxUGoeMl1FwQ6OINe0OsuauCQjNmP4ujiB0nDpj6iuiDu
11Hvrw+fdxuIV30Tdu/jowyNc3UmOR8+jNlvsFKlUgAU6AD8aaZLHFaEYzCKaNOPGospPX/7
U2pP0sSzacEhkjmtc8E5EYZW8KVyiutN0oHfxk8n0i3zSkHLMHJHvKkMoD1bJ34B6Dus/dK2
DvHXikCbl2fShDZZrRCr6L81qtQx08rrq3q6JAKrbt0Kgrlq+iy44V5wZ4uBTSbZtAWklL9D
gJnFgWPGovD7EJvtrKCERpL/niAe27NH1K4AAAAAAAA=
--------------ms010109050803020908090003--
From rpenno@juniper.net Fri Apr 16 11:26:18 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 F09883A6A99 for ; Fri, 16 Apr 2010 11:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level:
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6, 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 fPIfbSrVURt5 for ; Fri, 16 Apr 2010 11:26:17 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 375413A684A for ; Fri, 16 Apr 2010 11:26:00 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKS8irmIwBDcbyteBfFfl+0T1MAQAct7st@postini.com; Fri, 16 Apr 2010 11:25:58 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 16 Apr 2010 11:20:28 -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; Fri, 16 Apr 2010 14:20:28 -0400
From: Reinaldo Penno
To: wangaijun , Richard Alimi
Date: Fri, 16 Apr 2010 14:20:24 -0400
Thread-Topic: [alto] ***SPAM*** 5.418 (5) Is it possible to incorporate "server notification" mechanism into current ALTO protocol
Thread-Index: AcrcyYyq6UqCVUAATomfDdMBAE5w3AArMyTAAAGuepAABRoCDw==
Message-ID:
In-Reply-To: <004601cadd7d$54a4afd0$fdee0f70$@org.cn>
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
Cc: "Zhouky@ctbri.com.cn" , "Wangqian@ctbri.com.cn" , "alto@ietf.org" , 'Likai'
Subject: Re: [alto] ***SPAM*** 5.418 (5) Is it possible to incorporate "server notification" mechanism into current ALTO protocol
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, 16 Apr 2010 18:26:19 -0000
Interesting. I certainly see value in such mechanism for Tracker/CDN based
networks. Given the developments in HTTPby you might not even need a new
connection for such deployments.
Thanks,
Reinaldo
On 4/16/10 8:56 AM, "wangaijun" wrote:
> Hi Alimi,
>=20
> We have discussed about our
> draft(http://tools.ietf.org/id/draft-sun-alto-notification-00.txt) for sh=
ort
> time in IETF meeting in Anaheim. It a pity we did not get the chance to
> illustrate the prepared ppt(see attached file)in this meeting.
>=20
> After this meeting, I discussed your comments with my colleagues, and we
> still think the "server notification" mechanism should be incorporated in=
to
> the current ALTO protocol. It may act as one optional implementation, and
> mainly aim at the tracker-based environment. For tracker-less application=
,
> if one PID head was elected as described in draft
> http://tools.ietf.org/id/draft-ikpark-alto-virtual-p2ptracker-00.txt,
> the notification mechanism can also applied to it, on the assumption that=
it
> has the public IP address. These implementation can certainly reduce the
> burden of the ALTO server and let the ALTO clients get the ALTO informati=
on
> timely. This eventually will let the p2p traffic to keep up with the
> adjustment pace of ISP's policy.
>=20
> Wait for you and other interested persons' comments. If possible, we can
> discuss it in the coming " Interim Virtual Meeting " or next IETF plenary
> meeting.
>=20
> Best regards.
>=20
>=20
> Wang Aijun
> Network Infrastructure Research Division
> Network and Service Research Department
> China Telecom Coporation Beijing Research Institute
> =20
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D
> Today's Topics:
>=20
> 1. Interim Virtual Meeting (Enrico Marocco)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Message: 1
> Date: Thu, 15 Apr 2010 15:36:11 +0200
> From: Enrico Marocco
> Subject: [alto] Interim Virtual Meeting
> To: "alto@ietf.org"
> Cc: "Vijay K. Gurbani"
> Message-ID: <4BC7164B.2080501@telecomitalia.it>
> Content-Type: text/plain; charset=3D"iso-8859-1"
>=20
> Hi all,
>=20
> as mentioned during the last meeting, we plan to have an interim WebEx
> meeting between Anaheim and Maastricht. The date we have identified is Ju=
ne
> 16, but it may still be subject to change.
>=20
> In particular, we would like to focus the meeting on progressing the work=
on
> the protocol document, info redistribution, deployment considerations and
> v4/v6 issues. If anyone would like to propose other topics, please check
> well in advance with the chairs.
>=20
> An official email from the IETF secretariat will follow in the following
> weeks.
>=20
> --
> Ciao,
> Enrico
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 5162 bytes
> Desc: S/MIME Cryptographic Signature
> Url :
> achment.bin>
>=20
> ------------------------------
>=20
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>=20
>=20
> End of alto Digest, Vol 18, Issue 6
> ***********************************
>=20
>=20
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
From richard.alimi@gmail.com Fri Apr 16 11:26: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 13B793A67E2 for ; Fri, 16 Apr 2010 11:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.148
X-Spam-Level: *
X-Spam-Status: No, score=1.148 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6, MIME_CHARSET_FARAWAY=2.45]
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 WKHTZ6O7q7tz for ; Fri, 16 Apr 2010 11:26:38 -0700 (PDT)
Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id C405E3A66B4 for ; Fri, 16 Apr 2010 11:26:37 -0700 (PDT)
Received: by iwn27 with SMTP id 27so1587379iwn.5 for ; Fri, 16 Apr 2010 11:26:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=prjHImVR+rNZYxeVPbvC5CeKZ1veCvZDt5jiulURQPg=; b=Mz3ueEBfBJ1XXfRI3ehWNzL3uLOTwE5/YAfJ51/0Yt8QKCQk8ivWLoGaM1sMqqXEZz tlfcZNYmPni9K/34ZOGKcsVYFpm2RYwT6dAU46Z2EHJpgTlIPe/L8i5c/+Q9n1wBw6uw JlZthMOYT3aAnRlDD/hvHX4kWcmJBmhoOt0Bs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=B8SYphFC7FoPMZJgW0Gm2q78gQKa679H21xRcRVNzjXE13O7/zZ5MNFS6JC1pm5MTd K1A5f8SRagWg0FItXs5jUvcHkhZ70GAtVXUyCMox6yEy5seFmIsD/ofMAfEPHxjh0u9+ T5lorPkW3THWG/blxUCfUFopNp3ggzz/uQ+io=
MIME-Version: 1.0
Sender: richard.alimi@gmail.com
Received: by 10.231.169.12 with HTTP; Fri, 16 Apr 2010 11:26:28 -0700 (PDT)
In-Reply-To: <004201cadd7b$9489b890$bd9d29b0$@org.cn>
References: <004201cadd7b$9489b890$bd9d29b0$@org.cn>
Date: Fri, 16 Apr 2010 14:26:28 -0400
X-Google-Sender-Auth: e06b7d7b280ae68c
Received: by 10.231.161.132 with SMTP id r4mr680176ibx.48.1271442388244; Fri, 16 Apr 2010 11:26:28 -0700 (PDT)
Message-ID:
From: Richard Alimi
To: wangaijun
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Cc: Zhouky@ctbri.com.cn, Wangqian@ctbri.com.cn, alto@ietf.org, Likai
Subject: Re: [alto] Is it possible to incorporate "server notification" mechanism into current ALTO protocol
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, 16 Apr 2010 18:26:39 -0000
I believe that this is now a question for the WG (since it is a WG
document), and should receive comments from more WG participants
than just one of the draft's editors.
However, I can give my personal opinions (my initial thoughts at
least) on that may need further
consideration before being incorporated. I don't mean to imply that
_if_ something were to be included we must have all of the details
worked out, but we should be reasonably comfortable with the scope of
such a mechanism.
(1) For what entities can an ALTO Client register for notifications?
Network map changes? Cost map changes? Changes to only a subset of the
maps (e.g., as returned by the Map Filtering Service)? Endpoint
properties? Endpoint costs? How specific or general do you envision
this notification mechanism to be?
(2) How "persistent" is the registration for notifications? Does an
ALTO Client simply register for the _next_ network event, and is
expected to re-register after receiving this particular notification?
Or, does an ALTO Client register for notifications for all future
network events (in which case, a mechanism for un-registering must
also be provided)?
(3) What happens if the ALTO Server cannot reach a particular client
that registered for notifications -- is it permanently removed from
the notification list? What if there is a network failure between the
ALTO Server and ALTO Client - is the ALTO Client expected to somehow
detect this and re-register for notifications?
(4) I see in the draft that you mention "In order to improve the ALTO
server's efficiency, only P2P tracker and application server will be
notified by ALTO server." How do does the ALTO Server know which ALTO
Clients are P2P trackers or application servers? Is there a whitelist
maintained by the ALTO Service's provider?
You also mention below that "For tracker-less application, if one PID
head was elected as described in draft
http://tools.ietf.org/id/draft-ikpark-alto-virtual-p2ptracker-00.txt
the notification mechanism can also applied to it." Looking back at
this draft, I think you are assuming that the ALTO Server maintains
state information about the particular P2P swarms -- this would
require a radical shift from the current direction of the ALTO
Protocol and the multiple solution proposals that fed into it. My
personal preference would be to keep P2P swarm information out of the
ALTO Server; an alternative method for the P2P application would be to
utilize a different mechanism such as a DHT.
Another architecture for providing notifications (if they are needed
in only certain deployment scenarios) is to define it as a separate
protocol. "Notification servers" could be deployed separately (either
physically or logically separate) from the ALTO Servers. Notification
servers could be responsible for performing more frequently polling
the ALTO Server to look for changes, and a notification mechanism can
operate between the Notification Servers and ALTO Clients. The same
protocol could even be used between Notification Servers, and be used
for distributing notifications in a distribution-tree-like fashion.
Of course, this would not provide "realtime" notifications (in the
sense that it still operates as a polling mechanism), but I just
mention it as another possibility for consideration that might satisfy
your particular design goals.
Thanks,
--
Richard Alimi
Department of Computer Science
Yale University
2010/4/16 wangaijun :
> Hi Alimi,
>
> We have discussed about our
> draft(http://tools.ietf.org/id/draft-sun-alto-notification-00.txt) for sh=
ort
> time in IETF meeting in Anaheim. It a pity we did not get the chance to
> illustrate the prepared ppt(see attached file)in this meeting.
>
> After this meeting, I discussed your comments with my colleagues, and we
> still think the "server notification" mechanism should be incorporated in=
to
> the current ALTO protocol. It may act as one optional implementation, and
> mainly aim at the tracker-based environment. For tracker-less application=
,
> if one PID head was elected as described in draft
> http://tools.ietf.org/id/draft-ikpark-alto-virtual-p2ptracker-00.txt,
> the notification mechanism can also applied to it, on the assumption that=
it
> has the public IP address. These implementation can certainly reduce the
> burden of the ALTO server and let the ALTO clients get the ALTO informati=
on
> timely. This eventually will let the p2p traffic to keep up with the
> adjustment pace of ISP's policy.
>
> Wait for you and other interested persons' comments. If possible, we can
> discuss it in the coming " Interim Virtual Meeting " or next IETF plenary
> meeting.
>
> Best regards.
>
> =CD=F5=B0=AE=BF=A1
> =CD=F8=C2=E7=D2=B5=CE=F1=D1=D0=BE=BF=B2=BF =BB=F9=B4=A1=CD=F8=C2=E7=D1=D0=
=BE=BF=CA=D2
> =D6=D0=B9=FA=B5=E7=D0=C5 =B1=B1=BE=A9=D1=D0=BE=BF=D4=BA
> Tel: 010-58552347
>
> Wang Aijun
> Network Infrastructure Research Division
> Network and Service Research Department
> China Telecom Coporation Beijing Research Institute
>
>
>
>
> Today's Topics:
>
> 1. Interim Virtual Meeting (Enrico Marocco)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 15 Apr 2010 15:36:11 +0200
> From: Enrico Marocco
> Subject: [alto] Interim Virtual Meeting
> To: "alto@ietf.org"
> Cc: "Vijay K. Gurbani"
> Message-ID: <4BC7164B.2080501@telecomitalia.it>
> Content-Type: text/plain; charset=3D"iso-8859-1"
>
> Hi all,
>
> as mentioned during the last meeting, we plan to have an interim WebEx
> meeting between Anaheim and Maastricht. The date we have identified is
> June 16, but it may still be subject to change.
>
> In particular, we would like to focus the meeting on progressing the
> work on the protocol document, info redistribution, deployment
> considerations and v4/v6 issues. If anyone would like to propose other
> topics, please check well in advance with the chairs.
>
> An official email from the IETF secretariat will follow in the following
> weeks.
>
> --
> Ciao,
> Enrico
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 5162 bytes
> Desc: S/MIME Cryptographic Signature
> Url :
> achment.bin>
>
> ------------------------------
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>
> End of alto Digest, Vol 18, Issue 6
> ***********************************
>
From rpenno@juniper.net Fri Apr 16 11:53:18 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 0EC3328C116 for ; Fri, 16 Apr 2010 11:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.948
X-Spam-Level:
X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=-1.752, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 VGKIJcQ6V8nv for ; Fri, 16 Apr 2010 11:53:16 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 97A263A6781 for ; Fri, 16 Apr 2010 11:53:13 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKS8iyCawzBELHnyU4AeYwjKdvto4DfjPr@postini.com; Fri, 16 Apr 2010 11:53:09 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 16 Apr 2010 11:50:38 -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; Fri, 16 Apr 2010 14:50:38 -0400
From: Reinaldo Penno
To: Richard Alimi , wangaijun
Date: Fri, 16 Apr 2010 14:50:35 -0400
Thread-Topic: [alto] Is it possible to incorporate "server notification"mechanism into current ALTO protocol
Thread-Index: AcrdkmnmXkO3w0NjS1aef8IPXwq70QAA0i1N
Message-ID:
In-Reply-To:
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="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "Zhouky@ctbri.com.cn" , "Wangqian@ctbri.com.cn" , "alto@ietf.org" , Likai
Subject: Re: [alto] Is it possible to incorporate "server notification"mechanism into current ALTO protocol
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, 16 Apr 2010 18:53:18 -0000
SSBhZ3JlZS4gQXMgSSBzYWlkLCBJIGNlcnRhaW5seSBzZWUgdmFsdWUgaW4gdGhlIHByb3Bvc2Vk
IG1lY2hhbmlzbSwgYnV0DQp0aGVyZSBhcmUgZGV0YWlscyB0byBiZSBmaWxsZWQgYW5kIHRoYXQg
Y2FuIGNvbnRpbnVlIGluIHBhcmFsbGVsLg0KDQpUaGFua3MsDQoNClJlaW5hbGRvDQoNCg0KT24g
NC8xNi8xMCAxMToyNiBBTSwgIlJpY2hhcmQgQWxpbWkiIDxyaWNoYXJkLmFsaW1pQHlhbGUuZWR1
PiB3cm90ZToNCg0KPiBJIGJlbGlldmUgdGhhdCB0aGlzIGlzIG5vdyBhIHF1ZXN0aW9uIGZvciB0
aGUgV0cgKHNpbmNlIGl0IGlzIGEgV0cNCmRvY3VtZW50KSwNCj4gYW5kIHNob3VsZCByZWNlaXZl
IGNvbW1lbnRzIGZyb20gbW9yZSBXRyBwYXJ0aWNpcGFudHMNCnRoYW4ganVzdCBvbmUgb2YgdGhl
DQo+IGRyYWZ0J3MgZWRpdG9ycy4NCg0KSG93ZXZlciwgSSBjYW4gZ2l2ZSBteSBwZXJzb25hbCBv
cGluaW9ucyAobXkgaW5pdGlhbA0KPiB0aG91Z2h0cyBhdA0KbGVhc3QpIG9uIHRoYXQgbWF5IG5l
ZWQgZnVydGhlcg0KY29uc2lkZXJhdGlvbiBiZWZvcmUgYmVpbmcNCj4gaW5jb3Jwb3JhdGVkLiAg
SSBkb24ndCBtZWFuIHRvIGltcGx5IHRoYXQNCl9pZl8gc29tZXRoaW5nIHdlcmUgdG8gYmUgaW5j
bHVkZWQNCj4gd2UgbXVzdCBoYXZlIGFsbCBvZiB0aGUgZGV0YWlscw0Kd29ya2VkIG91dCwgYnV0
IHdlIHNob3VsZCBiZSByZWFzb25hYmx5DQo+IGNvbWZvcnRhYmxlIHdpdGggdGhlIHNjb3BlIG9m
DQpzdWNoIGEgbWVjaGFuaXNtLg0KDQooMSkgRm9yIHdoYXQgZW50aXRpZXMgY2FuIGFuDQo+IEFM
VE8gQ2xpZW50IHJlZ2lzdGVyIGZvciBub3RpZmljYXRpb25zPw0KTmV0d29yayBtYXAgY2hhbmdl
cz8gQ29zdCBtYXAgY2hhbmdlcz8NCj4gQ2hhbmdlcyB0byBvbmx5IGEgc3Vic2V0IG9mIHRoZQ0K
bWFwcyAoZS5nLiwgYXMgcmV0dXJuZWQgYnkgdGhlIE1hcCBGaWx0ZXJpbmcNCj4gU2VydmljZSk/
ICBFbmRwb2ludA0KcHJvcGVydGllcz8gRW5kcG9pbnQgY29zdHM/ICBIb3cgc3BlY2lmaWMgb3Ig
Z2VuZXJhbCBkbw0KPiB5b3UgZW52aXNpb24NCnRoaXMgbm90aWZpY2F0aW9uIG1lY2hhbmlzbSB0
byBiZT8NCg0KKDIpIEhvdyAicGVyc2lzdGVudCIgaXMgdGhlDQo+IHJlZ2lzdHJhdGlvbiBmb3Ig
bm90aWZpY2F0aW9ucz8gIERvZXMgYW4NCkFMVE8gQ2xpZW50IHNpbXBseSByZWdpc3RlciBmb3Ig
dGhlDQo+IF9uZXh0XyBuZXR3b3JrIGV2ZW50LCBhbmQgaXMNCmV4cGVjdGVkIHRvIHJlLXJlZ2lz
dGVyIGFmdGVyIHJlY2VpdmluZyB0aGlzDQo+IHBhcnRpY3VsYXIgbm90aWZpY2F0aW9uPw0KT3Is
IGRvZXMgYW4gQUxUTyBDbGllbnQgcmVnaXN0ZXIgZm9yIG5vdGlmaWNhdGlvbnMNCj4gZm9yIGFs
bCBmdXR1cmUNCm5ldHdvcmsgZXZlbnRzIChpbiB3aGljaCBjYXNlLCBhIG1lY2hhbmlzbSBmb3Ig
dW4tcmVnaXN0ZXJpbmcNCj4gbXVzdA0KYWxzbyBiZSBwcm92aWRlZCk/DQoNCigzKSBXaGF0IGhh
cHBlbnMgaWYgdGhlIEFMVE8gU2VydmVyIGNhbm5vdCByZWFjaCBhDQo+IHBhcnRpY3VsYXIgY2xp
ZW50DQp0aGF0IHJlZ2lzdGVyZWQgZm9yIG5vdGlmaWNhdGlvbnMgLS0gaXMgaXQgcGVybWFuZW50
bHkNCj4gcmVtb3ZlZCBmcm9tDQp0aGUgbm90aWZpY2F0aW9uIGxpc3Q/ICBXaGF0IGlmIHRoZXJl
IGlzIGEgbmV0d29yayBmYWlsdXJlDQo+IGJldHdlZW4gdGhlDQpBTFRPIFNlcnZlciBhbmQgQUxU
TyBDbGllbnQgLSBpcyB0aGUgQUxUTyBDbGllbnQgZXhwZWN0ZWQgdG8NCj4gc29tZWhvdw0KZGV0
ZWN0IHRoaXMgYW5kIHJlLXJlZ2lzdGVyIGZvciBub3RpZmljYXRpb25zPw0KDQooNCkgSSBzZWUg
aW4gdGhlIGRyYWZ0DQo+IHRoYXQgeW91IG1lbnRpb24gIkluIG9yZGVyIHRvIGltcHJvdmUgdGhl
IEFMVE8NCnNlcnZlcidzIGVmZmljaWVuY3ksIG9ubHkgUDJQDQo+IHRyYWNrZXIgYW5kIGFwcGxp
Y2F0aW9uIHNlcnZlciB3aWxsIGJlDQpub3RpZmllZCBieSBBTFRPIHNlcnZlci4iICBIb3cgZG8g
ZG9lcw0KPiB0aGUgQUxUTyBTZXJ2ZXIga25vdyB3aGljaCBBTFRPDQpDbGllbnRzIGFyZSBQMlAg
dHJhY2tlcnMgb3IgYXBwbGljYXRpb24NCj4gc2VydmVycz8gIElzIHRoZXJlIGEgd2hpdGVsaXN0
DQptYWludGFpbmVkIGJ5IHRoZSBBTFRPIFNlcnZpY2UncyBwcm92aWRlcj8NCg0KWW91DQo+IGFs
c28gbWVudGlvbiBiZWxvdyB0aGF0ICJGb3IgdHJhY2tlci1sZXNzIGFwcGxpY2F0aW9uLCBpZiBv
bmUgUElEDQpoZWFkIHdhcw0KPiBlbGVjdGVkIGFzIGRlc2NyaWJlZCBpbg0KPiBkcmFmdA0KaHR0
cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlrcGFyay1hbHRvLXZpcnR1YWwtcDJwdHJhY2tl
ci0wMC50eHQNCnRoZQ0KPiBub3RpZmljYXRpb24gbWVjaGFuaXNtIGNhbiBhbHNvIGFwcGxpZWQg
dG8gaXQuIiAgTG9va2luZyBiYWNrIGF0DQp0aGlzIGRyYWZ0LCBJDQo+IHRoaW5rIHlvdSBhcmUg
YXNzdW1pbmcgdGhhdCB0aGUgQUxUTyBTZXJ2ZXIgbWFpbnRhaW5zDQpzdGF0ZSBpbmZvcm1hdGlv
biBhYm91dA0KPiB0aGUgcGFydGljdWxhciBQMlAgc3dhcm1zIC0tIHRoaXMgd291bGQNCnJlcXVp
cmUgYSByYWRpY2FsIHNoaWZ0IGZyb20gdGhlDQo+IGN1cnJlbnQgZGlyZWN0aW9uIG9mIHRoZSBB
TFRPDQpQcm90b2NvbCBhbmQgdGhlIG11bHRpcGxlIHNvbHV0aW9uIHByb3Bvc2Fscw0KPiB0aGF0
IGZlZCBpbnRvIGl0LiAgTXkNCnBlcnNvbmFsIHByZWZlcmVuY2Ugd291bGQgYmUgdG8ga2VlcCBQ
MlAgc3dhcm0NCj4gaW5mb3JtYXRpb24gb3V0IG9mIHRoZQ0KQUxUTyBTZXJ2ZXI7IGFuIGFsdGVy
bmF0aXZlIG1ldGhvZCBmb3IgdGhlIFAyUA0KPiBhcHBsaWNhdGlvbiB3b3VsZCBiZSB0bw0KdXRp
bGl6ZSBhIGRpZmZlcmVudCBtZWNoYW5pc20gc3VjaCBhcyBhIERIVC4NCg0KQW5vdGhlcg0KPiBh
cmNoaXRlY3R1cmUgZm9yIHByb3ZpZGluZyBub3RpZmljYXRpb25zIChpZiB0aGV5IGFyZSBuZWVk
ZWQNCmluIG9ubHkgY2VydGFpbg0KPiBkZXBsb3ltZW50IHNjZW5hcmlvcykgaXMgdG8gZGVmaW5l
IGl0IGFzIGEgc2VwYXJhdGUNCnByb3RvY29sLiAgIk5vdGlmaWNhdGlvbg0KPiBzZXJ2ZXJzIiBj
b3VsZCBiZSBkZXBsb3llZCBzZXBhcmF0ZWx5IChlaXRoZXINCnBoeXNpY2FsbHkgb3IgbG9naWNh
bGx5DQo+IHNlcGFyYXRlKSBmcm9tIHRoZSBBTFRPIFNlcnZlcnMuIE5vdGlmaWNhdGlvbg0Kc2Vy
dmVycyBjb3VsZCBiZSByZXNwb25zaWJsZSBmb3INCj4gcGVyZm9ybWluZyBtb3JlIGZyZXF1ZW50
bHkgcG9sbGluZw0KdGhlIEFMVE8gU2VydmVyIHRvIGxvb2sgZm9yIGNoYW5nZXMsIGFuZCBhDQo+
IG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gY2FuDQpvcGVyYXRlIGJldHdlZW4gdGhlIE5vdGlmaWNh
dGlvbiBTZXJ2ZXJzIGFuZCBBTFRPDQo+IENsaWVudHMuICBUaGUgc2FtZQ0KcHJvdG9jb2wgY291
bGQgZXZlbiBiZSB1c2VkIGJldHdlZW4gTm90aWZpY2F0aW9uIFNlcnZlcnMsDQo+IGFuZCBiZSB1
c2VkDQpmb3IgZGlzdHJpYnV0aW5nIG5vdGlmaWNhdGlvbnMgaW4gYSBkaXN0cmlidXRpb24tdHJl
ZS1saWtlDQo+IGZhc2hpb24uDQpPZiBjb3Vyc2UsIHRoaXMgd291bGQgbm90IHByb3ZpZGUgInJl
YWx0aW1lIiBub3RpZmljYXRpb25zIChpbg0KPiB0aGUNCnNlbnNlIHRoYXQgaXQgc3RpbGwgb3Bl
cmF0ZXMgYXMgYSBwb2xsaW5nIG1lY2hhbmlzbSksIGJ1dCBJIGp1c3QNCm1lbnRpb24NCj4gaXQg
YXMgYW5vdGhlciBwb3NzaWJpbGl0eSBmb3IgY29uc2lkZXJhdGlvbiB0aGF0IG1pZ2h0IHNhdGlz
ZnkNCnlvdXIgcGFydGljdWxhcg0KPiBkZXNpZ24gZ29hbHMuDQoNClRoYW5rcywNCi0tDQpSaWNo
YXJkIEFsaW1pDQpEZXBhcnRtZW50IG9mIENvbXB1dGVyIFNjaWVuY2UNCllhbGUNCj4gVW5pdmVy
c2l0eQ0KDQoyMDEwLzQvMTYgd2FuZ2FpanVuIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPjoN
Cj4gSGkgQWxpbWksDQo+DQo+DQo+IFdlIGhhdmUgZGlzY3Vzc2VkIGFib3V0IG91cg0KPg0KPiBk
cmFmdChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtc3VuLWFsdG8tbm90aWZpY2F0aW9u
LTAwLnR4dCkgZm9yIHNob3J0DQo+DQo+IHRpbWUgaW4gSUVURiBtZWV0aW5nIGluIEFuYWhlaW0u
IEl0IGEgcGl0eSB3ZSBkaWQgbm90IGdldCB0aGUgY2hhbmNlIHRvDQo+DQo+IGlsbHVzdHJhdGUg
dGhlIHByZXBhcmVkIHBwdChzZWUgYXR0YWNoZWQgZmlsZSlpbiB0aGlzIG1lZXRpbmcuDQo+DQo+
IEFmdGVyIHRoaXMNCj4gbWVldGluZywgSSBkaXNjdXNzZWQgeW91ciBjb21tZW50cyB3aXRoIG15
IGNvbGxlYWd1ZXMsIGFuZCB3ZQ0KPiBzdGlsbCB0aGluaw0KPiB0aGUgInNlcnZlciBub3RpZmlj
YXRpb24iIG1lY2hhbmlzbSBzaG91bGQgYmUgaW5jb3Jwb3JhdGVkIGludG8NCj4gdGhlIGN1cnJl
bnQNCj4gQUxUTyBwcm90b2NvbC4gSXQgbWF5IGFjdCBhcyBvbmUgb3B0aW9uYWwgaW1wbGVtZW50
YXRpb24sIGFuZA0KPiBtYWlubHkgYWltIGF0DQo+IHRoZSB0cmFja2VyLWJhc2VkIGVudmlyb25t
ZW50LiBGb3IgdHJhY2tlci1sZXNzIGFwcGxpY2F0aW9uLA0KPiBpZiBvbmUgUElEIGhlYWQNCj4g
d2FzIGVsZWN0ZWQgYXMgZGVzY3JpYmVkIGluIGRyYWZ0DQo+DQo+IGh0dHA6Ly90b29scy5pZXRm
Lm9yZy9pZC9kcmFmdC1pa3BhcmstYWx0by12aXJ0dWFsLXAycHRyYWNrZXItMDAudHh0LA0KPiB0
aGUNCj4gbm90aWZpY2F0aW9uIG1lY2hhbmlzbSBjYW4gYWxzbyBhcHBsaWVkIHRvIGl0LCBvbiB0
aGUgYXNzdW1wdGlvbiB0aGF0IGl0DQo+IGhhcw0KPiB0aGUgcHVibGljIElQIGFkZHJlc3MuIFRo
ZXNlIGltcGxlbWVudGF0aW9uIGNhbiBjZXJ0YWlubHkgcmVkdWNlIHRoZQ0KPiBidXJkZW4NCj4g
b2YgdGhlIEFMVE8gc2VydmVyIGFuZCBsZXQgdGhlIEFMVE8gY2xpZW50cyBnZXQgdGhlIEFMVE8g
aW5mb3JtYXRpb24NCj4gdGltZWx5Lg0KPiBUaGlzIGV2ZW50dWFsbHkgd2lsbCBsZXQgdGhlIHAy
cCB0cmFmZmljIHRvIGtlZXAgdXAgd2l0aCB0aGUNCj4gYWRqdXN0bWVudCBwYWNlDQo+IG9mIElT
UCdzIHBvbGljeS4NCj4NCj4gV2FpdCBmb3IgeW91IGFuZCBvdGhlciBpbnRlcmVzdGVkIHBlcnNv
bnMnIGNvbW1lbnRzLiBJZg0KPiBwb3NzaWJsZSwgd2UgY2FuDQo+IGRpc2N1c3MgaXQgaW4gdGhl
IGNvbWluZyAiIEludGVyaW0gVmlydHVhbCBNZWV0aW5nICIgb3INCj4gbmV4dCBJRVRGIHBsZW5h
cnkNCj4gbWVldGluZy4NCj4NCj4gQmVzdCByZWdhcmRzLg0KPg0KPiDN9bCuv6ENCj4gzfjC59K1
zvHR0L6/sr8gu/m0oc34wufR0L6/DQo+IMrSDQo+INbQufq159DFILGxvqnR0L6/1LoNCj4gVGVs
OiAwMTAtNTg1NTIzNDcNCj4NCj4gV2FuZyBBaWp1bg0KPiBOZXR3b3JrDQo+IEluZnJhc3RydWN0
dXJlIFJlc2VhcmNoIERpdmlzaW9uDQo+IE5ldHdvcmsgYW5kIFNlcnZpY2UgUmVzZWFyY2ggRGVw
YXJ0bWVudA0KPg0KPiBDaGluYSBUZWxlY29tIENvcG9yYXRpb24gQmVpamluZyBSZXNlYXJjaCBJ
bnN0aXR1dGUNCj4NCj4NCj4NCj4NCj4gVG9kYXkncw0KPiBUb3BpY3M6DQo+DQo+ICAgMS4gSW50
ZXJpbSBWaXJ0dWFsIE1lZXRpbmcgKEVucmljbyBNYXJvY2NvKQ0KPg0KPg0KPg0KPiAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+DQo+DQo+IE1lc3NhZ2U6IDENCj4gRGF0ZTogVGh1LCAxNSBBcHIgMjAxMCAxNToz
NjoxMSArMDIwMA0KPiBGcm9tOiBFbnJpY28gTWFyb2Njbw0KPiA8ZW5yaWNvLm1hcm9jY29AdGVs
ZWNvbWl0YWxpYS5pdD4NCj4gU3ViamVjdDogW2FsdG9dIEludGVyaW0gVmlydHVhbCBNZWV0aW5n
DQo+DQo+IFRvOiAiYWx0b0BpZXRmLm9yZyIgPGFsdG9AaWV0Zi5vcmc+DQo+IENjOiAiVmlqYXkg
Sy4gR3VyYmFuaSINCj4gPHZrZ0BhbGNhdGVsLWx1Y2VudC5jb20+DQo+IE1lc3NhZ2UtSUQ6IDw0
QkM3MTY0Qi4yMDgwNTAxQHRlbGVjb21pdGFsaWEuaXQ+DQo+DQo+IENvbnRlbnQtVHlwZTogdGV4
dC9wbGFpbjsgY2hhcnNldD0iaXNvLTg4NTktMSINCj4NCj4gSGkgYWxsLA0KPg0KPiBhcyBtZW50
aW9uZWQNCj4gZHVyaW5nIHRoZSBsYXN0IG1lZXRpbmcsIHdlIHBsYW4gdG8gaGF2ZSBhbiBpbnRl
cmltIFdlYkV4DQo+IG1lZXRpbmcgYmV0d2Vlbg0KPiBBbmFoZWltIGFuZCBNYWFzdHJpY2h0LiBU
aGUgZGF0ZSB3ZSBoYXZlIGlkZW50aWZpZWQgaXMNCj4gSnVuZSAxNiwgYnV0IGl0IG1heQ0KPiBz
dGlsbCBiZSBzdWJqZWN0IHRvIGNoYW5nZS4NCj4NCj4gSW4gcGFydGljdWxhciwgd2Ugd291bGQg
bGlrZSB0byBmb2N1cyB0aGUNCj4gbWVldGluZyBvbiBwcm9ncmVzc2luZyB0aGUNCj4gd29yayBv
biB0aGUgcHJvdG9jb2wgZG9jdW1lbnQsIGluZm8NCj4gcmVkaXN0cmlidXRpb24sIGRlcGxveW1l
bnQNCj4gY29uc2lkZXJhdGlvbnMgYW5kIHY0L3Y2IGlzc3Vlcy4gSWYgYW55b25lIHdvdWxkDQo+
IGxpa2UgdG8gcHJvcG9zZSBvdGhlcg0KPiB0b3BpY3MsIHBsZWFzZSBjaGVjayB3ZWxsIGluIGFk
dmFuY2Ugd2l0aCB0aGUNCj4gY2hhaXJzLg0KPg0KPiBBbiBvZmZpY2lhbCBlbWFpbCBmcm9tIHRo
ZSBJRVRGIHNlY3JldGFyaWF0IHdpbGwgZm9sbG93IGluIHRoZQ0KPiBmb2xsb3dpbmcNCj4gd2Vl
a3MuDQo+DQo+IC0tDQo+IENpYW8sDQo+IEVucmljbw0KPiAtLS0tLS0tLS0tLS0tLSBuZXh0IHBh
cnQNCj4gLS0tLS0tLS0tLS0tLS0NCj4gQSBub24tdGV4dCBhdHRhY2htZW50IHdhcyBzY3J1YmJl
ZC4uLg0KPiBOYW1lOiBzbWltZS5wN3MNCj4NCj4gVHlwZTogYXBwbGljYXRpb24veC1wa2NzNy1z
aWduYXR1cmUNCj4gU2l6ZTogNTE2MiBieXRlcw0KPiBEZXNjOiBTL01JTUUNCj4gQ3J5cHRvZ3Jh
cGhpYyBTaWduYXR1cmUNCj4gVXJsIDoNCj4NCj4gPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h
cmNoaXZlL3dlYi9hbHRvL2F0dGFjaG1lbnRzLzIwMTAwNDE1LzE4YjQ0YzU2L2F0dA0KPg0KPiBh
Y2htZW50LmJpbj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFsdG8g
bWFpbGluZyBsaXN0DQo+DQo+IGFsdG9AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9hbHRvDQo+DQo+DQo+IEVuZCBvZiBhbHRvDQo+IERpZ2VzdCwgVm9s
IDE4LCBJc3N1ZSA2DQo+DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19fX18NCmFs
dG8gbWFpbGluZw0KPiBsaXN0DQphbHRvQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2FsdG8NCg0KDQo=
From Martin.Thomson@andrew.com Sun Apr 18 16:31:58 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 417D43A6A11 for ; Sun, 18 Apr 2010 16:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.048
X-Spam-Level:
X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-1.153, BAYES_50=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6]
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 sKPinEvb2z6m for ; Sun, 18 Apr 2010 16:31:57 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id CAC5F3A69FF for ; Sun, 18 Apr 2010 16:31:56 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:14429 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S214222Ab0DRXbs (ORCPT ); Sun, 18 Apr 2010 18:31:48 -0500
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 18 Apr 2010 18:31:47 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 19 Apr 2010 07:31:45 +0800
From: "Thomson, Martin"
To: Richard Alimi , wangaijun
Date: Mon, 19 Apr 2010 07:33:12 +0800
Thread-Topic: [alto] Is it possible to incorporate "server notification" mechanism into current ALTO protocol
Thread-Index: AcrdkloU2HWDLJFNS+e4duuUhbjt5gBvNXAQ
Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7D06797@SISPE7MB1.commscope.com>
References: <004201cadd7b$9489b890$bd9d29b0$@org.cn>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: "Zhouky@ctbri.com.cn" , "Wangqian@ctbri.com.cn" , "alto@ietf.org" , Likai
Subject: Re: [alto] Is it possible to incorporate "server notification" mechanism into current ALTO protocol
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: Sun, 18 Apr 2010 23:31:58 -0000
QXNpZGUgZnJvbSB0aGUgQUxUTy1sYXllciBjb25zaWRlcmF0aW9ucywgdGhlcmUgYXJlIGFsc28g
cHJvdG9jb2wgY29uc2lkZXJhdGlvbnMuDQoNCklmIEFMVE8gcmVsaWVzIG9uIEhUVFAsIHRoZW4g
SFRUUCBoYXMgc29tZSBsaW1pdGF0aW9ucyBpbiB0aGlzIHJlZ2FyZC4gIFRoZXJlIGFyZSBzb21l
IG9wdGlvbnM6IA0KDQogLSBsb25nLXBvbGxpbmcgd29ya3MgdXNpbmcgcHVyZSBIVFRQLCBhcyBs
b25nIGFzIGNsaWVudCBhbmQgc2VydmVyIGJvdGggdW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgdGhl
IGRlc2lyZWQgYmVoYXZpb3VyLiAgVGhpcyBpcyBhIGxpdHRsZSBpbmVmZmljaWVudCwgYnV0IGl0
IGlzIGdlbmVyYWxseSByZWdhcmRlZCBhcyB1c2VmdWwuDQoNCiAtIFRoZXJlIGFyZSBvdGhlciBw
cm90b2NvbHMgdGhhdCBtaWdodCBiZSBlbXBsb3llZCwgc2VlIDxodHRwOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1yb2FjaC1zaXAtaHR0cC1zdWJzY3JpYmU+DQoNCi0tTWFydGluDQoNCj4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYWx0by1ib3VuY2VzQGlldGYub3Jn
IFttYWlsdG86YWx0by1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gUmljaGFyZCBB
bGltaQ0KPiBTZW50OiBTYXR1cmRheSwgMTcgQXByaWwgMjAxMCA0OjI2IEFNDQo+IFRvOiB3YW5n
YWlqdW4NCj4gQ2M6IFpob3VreUBjdGJyaS5jb20uY247IFdhbmdxaWFuQGN0YnJpLmNvbS5jbjsg
YWx0b0BpZXRmLm9yZzsgTGlrYWkNCj4gU3ViamVjdDogUmU6IFthbHRvXSBJcyBpdCBwb3NzaWJs
ZSB0byBpbmNvcnBvcmF0ZSAic2VydmVyIG5vdGlmaWNhdGlvbiINCj4gbWVjaGFuaXNtIGludG8g
Y3VycmVudCBBTFRPIHByb3RvY29sDQo+IA0KPiBJIGJlbGlldmUgdGhhdCB0aGlzIGlzIG5vdyBh
IHF1ZXN0aW9uIGZvciB0aGUgV0cgKHNpbmNlIGl0IGlzIGEgV0cNCj4gZG9jdW1lbnQpLCBhbmQg
c2hvdWxkIHJlY2VpdmUgY29tbWVudHMgZnJvbSBtb3JlIFdHIHBhcnRpY2lwYW50cw0KPiB0aGFu
IGp1c3Qgb25lIG9mIHRoZSBkcmFmdCdzIGVkaXRvcnMuDQo+IA0KPiBIb3dldmVyLCBJIGNhbiBn
aXZlIG15IHBlcnNvbmFsIG9waW5pb25zIChteSBpbml0aWFsIHRob3VnaHRzIGF0DQo+IGxlYXN0
KSBvbiB0aGF0IG1heSBuZWVkIGZ1cnRoZXINCj4gY29uc2lkZXJhdGlvbiBiZWZvcmUgYmVpbmcg
aW5jb3Jwb3JhdGVkLiAgSSBkb24ndCBtZWFuIHRvIGltcGx5IHRoYXQNCj4gX2lmXyBzb21ldGhp
bmcgd2VyZSB0byBiZSBpbmNsdWRlZCB3ZSBtdXN0IGhhdmUgYWxsIG9mIHRoZSBkZXRhaWxzDQo+
IHdvcmtlZCBvdXQsIGJ1dCB3ZSBzaG91bGQgYmUgcmVhc29uYWJseSBjb21mb3J0YWJsZSB3aXRo
IHRoZSBzY29wZSBvZg0KPiBzdWNoIGEgbWVjaGFuaXNtLg0KPiANCj4gKDEpIEZvciB3aGF0IGVu
dGl0aWVzIGNhbiBhbiBBTFRPIENsaWVudCByZWdpc3RlciBmb3Igbm90aWZpY2F0aW9ucz8NCj4g
TmV0d29yayBtYXAgY2hhbmdlcz8gQ29zdCBtYXAgY2hhbmdlcz8gQ2hhbmdlcyB0byBvbmx5IGEg
c3Vic2V0IG9mIHRoZQ0KPiBtYXBzIChlLmcuLCBhcyByZXR1cm5lZCBieSB0aGUgTWFwIEZpbHRl
cmluZyBTZXJ2aWNlKT8gIEVuZHBvaW50DQo+IHByb3BlcnRpZXM/IEVuZHBvaW50IGNvc3RzPyAg
SG93IHNwZWNpZmljIG9yIGdlbmVyYWwgZG8geW91IGVudmlzaW9uDQo+IHRoaXMgbm90aWZpY2F0
aW9uIG1lY2hhbmlzbSB0byBiZT8NCj4gDQo+ICgyKSBIb3cgInBlcnNpc3RlbnQiIGlzIHRoZSBy
ZWdpc3RyYXRpb24gZm9yIG5vdGlmaWNhdGlvbnM/ICBEb2VzIGFuDQo+IEFMVE8gQ2xpZW50IHNp
bXBseSByZWdpc3RlciBmb3IgdGhlIF9uZXh0XyBuZXR3b3JrIGV2ZW50LCBhbmQgaXMNCj4gZXhw
ZWN0ZWQgdG8gcmUtcmVnaXN0ZXIgYWZ0ZXIgcmVjZWl2aW5nIHRoaXMgcGFydGljdWxhciBub3Rp
ZmljYXRpb24/DQo+IE9yLCBkb2VzIGFuIEFMVE8gQ2xpZW50IHJlZ2lzdGVyIGZvciBub3RpZmlj
YXRpb25zIGZvciBhbGwgZnV0dXJlDQo+IG5ldHdvcmsgZXZlbnRzIChpbiB3aGljaCBjYXNlLCBh
IG1lY2hhbmlzbSBmb3IgdW4tcmVnaXN0ZXJpbmcgbXVzdA0KPiBhbHNvIGJlIHByb3ZpZGVkKT8N
Cj4gDQo+ICgzKSBXaGF0IGhhcHBlbnMgaWYgdGhlIEFMVE8gU2VydmVyIGNhbm5vdCByZWFjaCBh
IHBhcnRpY3VsYXIgY2xpZW50DQo+IHRoYXQgcmVnaXN0ZXJlZCBmb3Igbm90aWZpY2F0aW9ucyAt
LSBpcyBpdCBwZXJtYW5lbnRseSByZW1vdmVkIGZyb20NCj4gdGhlIG5vdGlmaWNhdGlvbiBsaXN0
PyAgV2hhdCBpZiB0aGVyZSBpcyBhIG5ldHdvcmsgZmFpbHVyZSBiZXR3ZWVuIHRoZQ0KPiBBTFRP
IFNlcnZlciBhbmQgQUxUTyBDbGllbnQgLSBpcyB0aGUgQUxUTyBDbGllbnQgZXhwZWN0ZWQgdG8g
c29tZWhvdw0KPiBkZXRlY3QgdGhpcyBhbmQgcmUtcmVnaXN0ZXIgZm9yIG5vdGlmaWNhdGlvbnM/
DQo+IA0KPiAoNCkgSSBzZWUgaW4gdGhlIGRyYWZ0IHRoYXQgeW91IG1lbnRpb24gIkluIG9yZGVy
IHRvIGltcHJvdmUgdGhlIEFMVE8NCj4gc2VydmVyJ3MgZWZmaWNpZW5jeSwgb25seSBQMlAgdHJh
Y2tlciBhbmQgYXBwbGljYXRpb24gc2VydmVyIHdpbGwgYmUNCj4gbm90aWZpZWQgYnkgQUxUTyBz
ZXJ2ZXIuIiAgSG93IGRvIGRvZXMgdGhlIEFMVE8gU2VydmVyIGtub3cgd2hpY2ggQUxUTw0KPiBD
bGllbnRzIGFyZSBQMlAgdHJhY2tlcnMgb3IgYXBwbGljYXRpb24gc2VydmVycz8gIElzIHRoZXJl
IGEgd2hpdGVsaXN0DQo+IG1haW50YWluZWQgYnkgdGhlIEFMVE8gU2VydmljZSdzIHByb3ZpZGVy
Pw0KPiANCj4gWW91IGFsc28gbWVudGlvbiBiZWxvdyB0aGF0ICJGb3IgdHJhY2tlci1sZXNzIGFw
cGxpY2F0aW9uLCBpZiBvbmUgUElEDQo+IGhlYWQgd2FzIGVsZWN0ZWQgYXMgZGVzY3JpYmVkIGlu
IGRyYWZ0DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pa3BhcmstYWx0by12aXJ0
dWFsLXAycHRyYWNrZXItMDAudHh0DQo+IHRoZSBub3RpZmljYXRpb24gbWVjaGFuaXNtIGNhbiBh
bHNvIGFwcGxpZWQgdG8gaXQuIiAgTG9va2luZyBiYWNrIGF0DQo+IHRoaXMgZHJhZnQsIEkgdGhp
bmsgeW91IGFyZSBhc3N1bWluZyB0aGF0IHRoZSBBTFRPIFNlcnZlciBtYWludGFpbnMNCj4gc3Rh
dGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBhcnRpY3VsYXIgUDJQIHN3YXJtcyAtLSB0aGlzIHdv
dWxkDQo+IHJlcXVpcmUgYSByYWRpY2FsIHNoaWZ0IGZyb20gdGhlIGN1cnJlbnQgZGlyZWN0aW9u
IG9mIHRoZSBBTFRPDQo+IFByb3RvY29sIGFuZCB0aGUgbXVsdGlwbGUgc29sdXRpb24gcHJvcG9z
YWxzIHRoYXQgZmVkIGludG8gaXQuICBNeQ0KPiBwZXJzb25hbCBwcmVmZXJlbmNlIHdvdWxkIGJl
IHRvIGtlZXAgUDJQIHN3YXJtIGluZm9ybWF0aW9uIG91dCBvZiB0aGUNCj4gQUxUTyBTZXJ2ZXI7
IGFuIGFsdGVybmF0aXZlIG1ldGhvZCBmb3IgdGhlIFAyUCBhcHBsaWNhdGlvbiB3b3VsZCBiZSB0
bw0KPiB1dGlsaXplIGEgZGlmZmVyZW50IG1lY2hhbmlzbSBzdWNoIGFzIGEgREhULg0KPiANCj4g
QW5vdGhlciBhcmNoaXRlY3R1cmUgZm9yIHByb3ZpZGluZyBub3RpZmljYXRpb25zIChpZiB0aGV5
IGFyZSBuZWVkZWQNCj4gaW4gb25seSBjZXJ0YWluIGRlcGxveW1lbnQgc2NlbmFyaW9zKSBpcyB0
byBkZWZpbmUgaXQgYXMgYSBzZXBhcmF0ZQ0KPiBwcm90b2NvbC4gICJOb3RpZmljYXRpb24gc2Vy
dmVycyIgY291bGQgYmUgZGVwbG95ZWQgc2VwYXJhdGVseSAoZWl0aGVyDQo+IHBoeXNpY2FsbHkg
b3IgbG9naWNhbGx5IHNlcGFyYXRlKSBmcm9tIHRoZSBBTFRPIFNlcnZlcnMuIE5vdGlmaWNhdGlv
bg0KPiBzZXJ2ZXJzIGNvdWxkIGJlIHJlc3BvbnNpYmxlIGZvciBwZXJmb3JtaW5nIG1vcmUgZnJl
cXVlbnRseSBwb2xsaW5nDQo+IHRoZSBBTFRPIFNlcnZlciB0byBsb29rIGZvciBjaGFuZ2VzLCBh
bmQgYSBub3RpZmljYXRpb24gbWVjaGFuaXNtIGNhbg0KPiBvcGVyYXRlIGJldHdlZW4gdGhlIE5v
dGlmaWNhdGlvbiBTZXJ2ZXJzIGFuZCBBTFRPIENsaWVudHMuICBUaGUgc2FtZQ0KPiBwcm90b2Nv
bCBjb3VsZCBldmVuIGJlIHVzZWQgYmV0d2VlbiBOb3RpZmljYXRpb24gU2VydmVycywgYW5kIGJl
IHVzZWQNCj4gZm9yIGRpc3RyaWJ1dGluZyBub3RpZmljYXRpb25zIGluIGEgZGlzdHJpYnV0aW9u
LXRyZWUtbGlrZSBmYXNoaW9uLg0KPiBPZiBjb3Vyc2UsIHRoaXMgd291bGQgbm90IHByb3ZpZGUg
InJlYWx0aW1lIiBub3RpZmljYXRpb25zIChpbiB0aGUNCj4gc2Vuc2UgdGhhdCBpdCBzdGlsbCBv
cGVyYXRlcyBhcyBhIHBvbGxpbmcgbWVjaGFuaXNtKSwgYnV0IEkganVzdA0KPiBtZW50aW9uIGl0
IGFzIGFub3RoZXIgcG9zc2liaWxpdHkgZm9yIGNvbnNpZGVyYXRpb24gdGhhdCBtaWdodCBzYXRp
c2Z5DQo+IHlvdXIgcGFydGljdWxhciBkZXNpZ24gZ29hbHMuDQo+IA0KPiBUaGFua3MsDQo+IC0t
DQo+IFJpY2hhcmQgQWxpbWkNCj4gRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlDQo+IFlh
bGUgVW5pdmVyc2l0eQ0KPiANCj4gMjAxMC80LzE2IHdhbmdhaWp1biA8d2FuZ2FpanVuQHRzaW5n
aHVhLm9yZy5jbj46DQo+ID4gSGkgQWxpbWksDQo+ID4NCj4gPiBXZSBoYXZlIGRpc2N1c3NlZCBh
Ym91dCBvdXINCj4gPiBkcmFmdChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtc3VuLWFs
dG8tbm90aWZpY2F0aW9uLTAwLnR4dCkNCj4gZm9yIHNob3J0DQo+ID4gdGltZSBpbiBJRVRGIG1l
ZXRpbmcgaW4gQW5haGVpbS4gSXQgYSBwaXR5IHdlIGRpZCBub3QgZ2V0IHRoZSBjaGFuY2UNCj4g
dG8NCj4gPiBpbGx1c3RyYXRlIHRoZSBwcmVwYXJlZCBwcHQoc2VlIGF0dGFjaGVkIGZpbGUpaW4g
dGhpcyBtZWV0aW5nLg0KPiA+DQo+ID4gQWZ0ZXIgdGhpcyBtZWV0aW5nLCBJIGRpc2N1c3NlZCB5
b3VyIGNvbW1lbnRzIHdpdGggbXkgY29sbGVhZ3VlcywgYW5kDQo+IHdlDQo+ID4gc3RpbGwgdGhp
bmsgdGhlICJzZXJ2ZXIgbm90aWZpY2F0aW9uIiBtZWNoYW5pc20gc2hvdWxkIGJlDQo+IGluY29y
cG9yYXRlZCBpbnRvDQo+ID4gdGhlIGN1cnJlbnQgQUxUTyBwcm90b2NvbC4gSXQgbWF5IGFjdCBh
cyBvbmUgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24sDQo+IGFuZA0KPiA+IG1haW5seSBhaW0gYXQg
dGhlIHRyYWNrZXItYmFzZWQgZW52aXJvbm1lbnQuIEZvciB0cmFja2VyLWxlc3MNCj4gYXBwbGlj
YXRpb24sDQo+ID4gaWYgb25lIFBJRCBoZWFkIHdhcyBlbGVjdGVkIGFzIGRlc2NyaWJlZCBpbiBk
cmFmdA0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pa3BhcmstYWx0by12aXJ0
dWFsLXAycHRyYWNrZXItMDAudHh0LA0KPiA+IHRoZSBub3RpZmljYXRpb24gbWVjaGFuaXNtIGNh
biBhbHNvIGFwcGxpZWQgdG8gaXQsIG9uIHRoZSBhc3N1bXB0aW9uDQo+IHRoYXQgaXQNCj4gPiBo
YXMgdGhlIHB1YmxpYyBJUCBhZGRyZXNzLiBUaGVzZSBpbXBsZW1lbnRhdGlvbiBjYW4gY2VydGFp
bmx5IHJlZHVjZQ0KPiB0aGUNCj4gPiBidXJkZW4gb2YgdGhlIEFMVE8gc2VydmVyIGFuZCBsZXQg
dGhlIEFMVE8gY2xpZW50cyBnZXQgdGhlIEFMVE8NCj4gaW5mb3JtYXRpb24NCj4gPiB0aW1lbHku
IFRoaXMgZXZlbnR1YWxseSB3aWxsIGxldCB0aGUgcDJwIHRyYWZmaWMgdG8ga2VlcCB1cCB3aXRo
IHRoZQ0KPiA+IGFkanVzdG1lbnQgcGFjZSBvZiBJU1AncyBwb2xpY3kuDQo+ID4NCj4gPiBXYWl0
IGZvciB5b3UgYW5kIG90aGVyIGludGVyZXN0ZWQgcGVyc29ucycgY29tbWVudHMuIElmIHBvc3Np
YmxlLCB3ZQ0KPiBjYW4NCj4gPiBkaXNjdXNzIGl0IGluIHRoZSBjb21pbmcgIiBJbnRlcmltIFZp
cnR1YWwgTWVldGluZyAiIG9yIG5leHQgSUVURg0KPiBwbGVuYXJ5DQo+ID4gbWVldGluZy4NCj4g
Pg0KPiA+IEJlc3QgcmVnYXJkcy4NCj4gPg0KPiA+IOeOi+eIseS/ig0KPiA+IOe9kee7nOS4muWK
oeeglOeptumDqCDln7rnoYDnvZHnu5znoJTnqbblrqQNCj4gPiDkuK3lm73nlLXkv6Eg5YyX5Lqs
56CU56m26ZmiDQo+ID4gVGVsOiAwMTAtNTg1NTIzNDcNCj4gPg0KPiA+IFdhbmcgQWlqdW4NCj4g
PiBOZXR3b3JrIEluZnJhc3RydWN0dXJlIFJlc2VhcmNoIERpdmlzaW9uDQo+ID4gTmV0d29yayBh
bmQgU2VydmljZSBSZXNlYXJjaCBEZXBhcnRtZW50DQo+ID4gQ2hpbmEgVGVsZWNvbSBDb3BvcmF0
aW9uIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dXRlDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBU
b2RheSdzIFRvcGljczoNCj4gPg0KPiA+ICAgMS4gSW50ZXJpbSBWaXJ0dWFsIE1lZXRpbmcgKEVu
cmljbyBNYXJvY2NvKQ0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiA+DQo+ID4g
TWVzc2FnZTogMQ0KPiA+IERhdGU6IFRodSwgMTUgQXByIDIwMTAgMTU6MzY6MTEgKzAyMDANCj4g
PiBGcm9tOiBFbnJpY28gTWFyb2NjbyA8ZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdD4N
Cj4gPiBTdWJqZWN0OiBbYWx0b10gSW50ZXJpbSBWaXJ0dWFsIE1lZXRpbmcNCj4gPiBUbzogImFs
dG9AaWV0Zi5vcmciIDxhbHRvQGlldGYub3JnPg0KPiA+IENjOiAiVmlqYXkgSy4gR3VyYmFuaSIg
PHZrZ0BhbGNhdGVsLWx1Y2VudC5jb20+DQo+ID4gTWVzc2FnZS1JRDogPDRCQzcxNjRCLjIwODA1
MDFAdGVsZWNvbWl0YWxpYS5pdD4NCj4gPiBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJz
ZXQ9Imlzby04ODU5LTEiDQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBhcyBtZW50aW9uZWQg
ZHVyaW5nIHRoZSBsYXN0IG1lZXRpbmcsIHdlIHBsYW4gdG8gaGF2ZSBhbiBpbnRlcmltDQo+IFdl
YkV4DQo+ID4gbWVldGluZyBiZXR3ZWVuIEFuYWhlaW0gYW5kIE1hYXN0cmljaHQuIFRoZSBkYXRl
IHdlIGhhdmUgaWRlbnRpZmllZA0KPiBpcw0KPiA+IEp1bmUgMTYsIGJ1dCBpdCBtYXkgc3RpbGwg
YmUgc3ViamVjdCB0byBjaGFuZ2UuDQo+ID4NCj4gPiBJbiBwYXJ0aWN1bGFyLCB3ZSB3b3VsZCBs
aWtlIHRvIGZvY3VzIHRoZSBtZWV0aW5nIG9uIHByb2dyZXNzaW5nIHRoZQ0KPiA+IHdvcmsgb24g
dGhlIHByb3RvY29sIGRvY3VtZW50LCBpbmZvIHJlZGlzdHJpYnV0aW9uLCBkZXBsb3ltZW50DQo+
ID4gY29uc2lkZXJhdGlvbnMgYW5kIHY0L3Y2IGlzc3Vlcy4gSWYgYW55b25lIHdvdWxkIGxpa2Ug
dG8gcHJvcG9zZQ0KPiBvdGhlcg0KPiA+IHRvcGljcywgcGxlYXNlIGNoZWNrIHdlbGwgaW4gYWR2
YW5jZSB3aXRoIHRoZSBjaGFpcnMuDQo+ID4NCj4gPiBBbiBvZmZpY2lhbCBlbWFpbCBmcm9tIHRo
ZSBJRVRGIHNlY3JldGFyaWF0IHdpbGwgZm9sbG93IGluIHRoZQ0KPiBmb2xsb3dpbmcNCj4gPiB3
ZWVrcy4NCj4gPg0KPiA+IC0tDQo+ID4gQ2lhbywNCj4gPiBFbnJpY28NCj4gPiAtLS0tLS0tLS0t
LS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0NCj4gPiBBIG5vbi10ZXh0IGF0dGFjaG1lbnQg
d2FzIHNjcnViYmVkLi4uDQo+ID4gTmFtZTogc21pbWUucDdzDQo+ID4gVHlwZTogYXBwbGljYXRp
b24veC1wa2NzNy1zaWduYXR1cmUNCj4gPiBTaXplOiA1MTYyIGJ5dGVzDQo+ID4gRGVzYzogUy9N
SU1FIENyeXB0b2dyYXBoaWMgU2lnbmF0dXJlDQo+ID4gVXJsIDoNCj4gPiA8aHR0cDovL3d3dy5p
ZXRmLm9yZy9tYWlsLQ0KPiBhcmNoaXZlL3dlYi9hbHRvL2F0dGFjaG1lbnRzLzIwMTAwNDE1LzE4
YjQ0YzU2L2F0dA0KPiA+IGFjaG1lbnQuYmluPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA+IGFsdG8gbWFpbGluZyBsaXN0DQo+ID4gYWx0b0BpZXRmLm9yZw0K
PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWx0bw0KPiA+DQo+ID4N
Cj4gPiBFbmQgb2YgYWx0byBEaWdlc3QsIFZvbCAxOCwgSXNzdWUgNg0KPiA+ICoqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gYWx0byBtYWlsaW5nIGxpc3QNCj4gYWx0b0BpZXRm
Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FsdG8NCg==
From richard.alimi@gmail.com Mon Apr 19 11:46:07 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 286D73A6800 for ; Mon, 19 Apr 2010 11:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.04
X-Spam-Level: ****
X-Spam-Status: No, score=4.04 tagged_above=-999 required=5 tests=[AWL=-3.417, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_75=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345]
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 6-DfttugmJWR for ; Mon, 19 Apr 2010 11:46:07 -0700 (PDT)
Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id DF16E3A67C2 for ; Mon, 19 Apr 2010 11:46:06 -0700 (PDT)
Received: by iwn27 with SMTP id 27so446603iwn.5 for ; Mon, 19 Apr 2010 11:45:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Juz7V4R0AhU1qB9+06EFnnHyw7EFIGmITtCRG6GF7vA=; b=n6cuMqUjSPGBH1F+Mi4h5X40+JgRlG4rgjjSup/rN5HXoQSqcz91uTNYoMptnN26yB QpFr5RiP3x064GRsYf1wkc6DXaocwt+SYqqfAp2q5EBAz62cPalfrqhA2SwejS/ePI2H u5oby+lQRjU/mR7+wrfBS3P4cU0G9vejIM/UI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=x9nk9Y4N7ygJ3rOOQQtPLKrTxW8PV+ZDTnAnnR2aJN5L0EOnUIdDKPziykJQ8xMyXX rJR9uT4DYdJLZhjYpkEOsUOXrxJGRAFMFZW5Ccqu4I8AUUaKWIcE1x6sLihsZ8cBs1AH E3McwP3va/W2ivpOynsnLJNoTwpFDD0T1Kowc=
MIME-Version: 1.0
Sender: richard.alimi@gmail.com
Received: by 10.231.169.12 with HTTP; Mon, 19 Apr 2010 11:45:54 -0700 (PDT)
In-Reply-To: <009b01cadfbc$b8395050$28abf0f0$@org.cn>
References: <004201cadd7b$9489b890$bd9d29b0$@org.cn> <009b01cadfbc$b8395050$28abf0f0$@org.cn>
Date: Mon, 19 Apr 2010 14:45:54 -0400
X-Google-Sender-Auth: c12508e22ffc3fdb
Received: by 10.231.147.199 with SMTP id m7mr2020981ibv.87.1271702754996; Mon, 19 Apr 2010 11:45:54 -0700 (PDT)
Message-ID:
From: Richard Alimi
To: wangaijun
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Cc: Jiangzhf@ctbri.com.cn, Zhouky@ctbri.com.cn, Wangqian@ctbri.com.cn, alto@ietf.org, Likai
Subject: Re: [alto] =?gb2312?b?tPC4tDogSXMgaXQgcG9zc2libGUgdG8gaW5jb3Jwb3Jh?= =?gb2312?b?dGUgInNlcnZlciBub3RpZmljYXRpb24iIG1lY2hhbmlzbSBpbnRv?= =?gb2312?b?IGN1cnJlbnQgQUxUTyBwcm90b2NvbA==?=
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, 19 Apr 2010 18:46:07 -0000
Thanks for the explanations. Please see below for some comments:
2010/4/19 wangaijun :
> [ ... snip ... ]
>
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: richard.alimi@gmail.com [mailto:richard.alimi@gmail.c=
om] =B4=FA=B1=ED Richard
> Alimi
> =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA4=D4=C217=C8=D5 2:26
> =CA=D5=BC=FE=C8=CB: wangaijun
> =B3=AD=CB=CD: alto@ietf.org; sunxh@ctbri.com.cn; Zhouky@ctbri.com.cn; Lik=
ai;
> Wangqian@ctbri.com.cn
> =D6=F7=CC=E2: Re: Is it possible to incorporate "server notification" mec=
hanism into
> current ALTO protocol
>
> [ ... snip ... ]
>
> (1) For what entities can an ALTO Client register for notifications?
> Network map changes? Cost map changes? Changes to only a subset of the
> maps (e.g., as returned by the Map Filtering Service)? Endpoint
> properties? Endpoint costs? How specific or general do you envision
> this notification mechanism to be?
>
> Reply: Generally, any change of network condition/policy can lead the upd=
ate
> of cost map or network map=A3=AC so it is appropriate to design the notif=
ication
> mechanism as one for general purpose, that is to say, any change in netwo=
rk
> condition will trigger the server notification message. Once the ALTO
> clients receive this notification message, they can get their specific
> interesting ALTO information via the current ALTO query/response message,
> with the help of Map Filtering Service.
Okay. One property of this design that I would like to point out, is
that the ALTO Server may be sending notifications to clients who do
not care about the particular update that was made. Of course, one
advantage is simplicity and it may in fact be reasonable to make this
tradeoff in some cases.
> For information about Endpoint costs and Endpoint properties, we think th=
ey
> should be dealt by p2p tracker or p2p application themselves, the ISP sho=
uld
> not consider these things because they are not relevant to the network(th=
ere
> are also a lot discussion about the appropriate usage of these informatio=
n,
> whether it is beneficial or not has not been decided yet.).
Could you be more specific here? I'm not quite sure what you mean by
"not relevant to the network."
> (2) How "persistent" is the registration for notifications? Does an
> ALTO Client simply register for the _next_ network event, and is
> expected to re-register after receiving this particular notification?
> Or, does an ALTO Client register for notifications for all future
> network events (in which case, a mechanism for un-registering must
> also be provided)?
>
> Reply: It is apparently that the ALTO server should aware the state chan=
ge
> of registered ALTO clients.
I don't believe this is apparent quite yet, mostly because I'm not
convinced the ALTO Server needs to keep track of this and I don't know
what exactly is meant by "state change" of an ALTO Client. Do you
mean application restarts? Network connectivity changes?
> The re-reigster process as you described is more
> appropriate. But according to our current draft, it is unnecessarily to
> redesign the re-register message: when the ALTO server send one
> notification, it is expected the ALTO client will send one query message
> immediately or in short time(this time can be configured). This query
> message can be treated as one re-register message. If the server does not
> receive any message from the listed ALTO Clients, then it will be deleted
> from the register table in ALTO Server.
I don't believe all ALTO Queries should be regarded as an implicit
registration. This can be extremely wasteful; I believe it should be
the _ALTO Client_ who decides whether or not it wishes to receive
notifications. For example, if a set of ALTO Clients are using
redistribution, it can be wasteful for the ALTO Server to notify all
of them; the redistribution process may have its own notification
mechanism.
I strongly believe that explicit registration is preferred here.
> (3) What happens if the ALTO Server cannot reach a particular client
> that registered for notifications -- is it permanently removed from
> the notification list? What if there is a network failure between the
> ALTO Server and ALTO Client - is the ALTO Client expected to somehow
> detect this and re-register for notifications?
>
> Reply: When the ALTO Clients startup, it will first query the ALTO serve=
r.
So, in this event, the ALTO Client would be left without notifications
until it restarts?
Related to this, what happens if an ALTO Server crashes? Do you
envision prescribing guidelines on the storage for the notification
list (take a look at NFS's requirements on stable storage to see what
might be involved here if you go down this road)? If there is no
stable storage for maintaining the list, I presume the ALTO Client
would at least need to periodically check that it is still registered.
(If it does not check periodically, you may be leaving an P2P tracker
that runs for weeks or months at a time without any updated ALTO
information.)
Another related possibility is if the ISP decommissions one ALTO
Server (or even temporarily shuts it down for maintenance); is it
responsible for re-allocating "registered" clients to other ALTO
Servers?
> Once the ALTO server receive this query message, it will register the ALT=
O
> Clients' contact information(ip addresses/ports pair).
I presume that you mean adding at least the peer's listening port to
each query message sent to the ALTO Server.
> If the ALTO server
> does not receive the new query message after its notification message, th=
e
> ALTO client will be removed from the notification list. The client can
> re-activated the register/notification process by sending the query messa=
ge
> in any time.
With this implicit mechanism, each peer that is behind a NAT will
incur a wasted notification message from the ALTO Server (unless the
ALTO Client configures port-forwarding, or other adjustments for NAT
traversal are made).
> (4) I see in the draft that you mention "In order to improve the ALTO
> server's efficiency, only P2P tracker and application server will be
> notified by ALTO server." How do does the ALTO Server know which ALTO
> Clients are P2P trackers or application servers? Is there a whitelist
> maintained by the ALTO Service's provider?
>
> Reply: Here the application server is mainly referred other Client/Serve=
r
> style application, in which the application server can notify its client =
for
> the change of network information. The ALTO server need not distinguish t=
he
> differences between them.
Sure it does, unless the ALTO Server is prepared to send out at
notifications to each ALTO Client that has requested information from
it. Tracker-based applications are not the only P2P applications in
the world.
> You also mention below that "For tracker-less application, if one PID
> head was elected as described in draft
> http://tools.ietf.org/id/draft-ikpark-alto-virtual-p2ptracker-00.txt
> the notification mechanism can also applied to it." Looking back at
> this draft, I think you are assuming that the ALTO Server maintains
> state information about the particular P2P swarms -- this would
> require a radical shift from the current direction of the ALTO
> Protocol and the multiple solution proposals that fed into it. My
> personal preference would be to keep P2P swarm information out of the
> ALTO Server; an alternative method for the P2P application would be to
> utilize a different mechanism such as a DHT.
>
> Reply: Currently, our draft is mainly for tracker-based p2p application. =
It
> is more complex in tracker-less environment because the ALTO clients that
> are embedded in p2p clients are very unstable. One alternative solution
> except the above proposal is that let the ALTO clients/p2p clients decide
> whether they need the notification or not themselves. If it is true(for s=
ome
> stable p2p peer), they can register directly to the ALTO server, or else
> just use the traditional query/response mechanism.
I would personally much prefer this design and it solves some of the
concerns above.
> Another architecture for providing notifications (if they are needed
> in only certain deployment scenarios) is to define it as a separate
> protocol. "Notification servers" could be deployed separately (either
> physically or logically separate) from the ALTO Servers. Notification
> servers could be responsible for performing more frequently polling
> the ALTO Server to look for changes, and a notification mechanism can
> operate between the Notification Servers and ALTO Clients. The same
> protocol could even be used between Notification Servers, and be used
> for distributing notifications in a distribution-tree-like fashion.
> Of course, this would not provide "realtime" notifications (in the
> sense that it still operates as a polling mechanism), but I just
> mention it as another possibility for consideration that might satisfy
> your particular design goals.
>
> Reply: This architecture has the same pros and cons of our embed solutio=
n.
> The current notification mechanism will not lay much extra burden to the
> ALTO server, the notification protocol between ALTO servers and
> distribution-tree-like fashion can still be designed accordingly, because=
in
> realty, the network information will come authoritatively from one
> administration point for one ISP and the ALTO servers will be deployed in
> distributed in future.
I guess the disagreement comes down to how much "burden" the
notification is on the ALTO Server. With regards to the amount of
messaging and state storage, I tend to agree that both architectures
would be equivalent. However, with regards to implementation complexity, I
believe that separating them can be preferred. The ALTO Server can
remain as a clean design without per-client state. Notification
servers have their own jobs regarding storing per-client state and
failure recovery with regards to this per-client state (see above),
and perhaps NAT traversal logic as well.
--
Richard Alimi
Department of Computer Science
Yale University