Nicholas Weaver | 1 Mar 17:08 2009
Picon

Re: Comments on requirements draft

Looking at the current draft, a few thoughts....

The usage cases may be too broad.  EG, local mirror/caching discovery  
for conventional CDN operation doesn't need to rely on alto, and would  
probably not benefit, as the conventional CDNs have solved the problem  
"good enough", and it also interacts with their OWN secret-sauce.

My thought would be focus on the two useage cases which count:

Bulk data P2P peer localization, and P2P hashtable localization, where  
the first is about saving cost while providing the same service, while  
the latter is reducing latency.

On security considerations, any open-world P2P system per file can be  
tracked from one or more nodes by creating sybils, so ALTO doesn't  
make the problem easier, and any P2P system which deliberately hides  
this (eg, by onion-routing data) is not going to WANT localization and  
increased localization increases the power of traffic analysis.

Thus I believe that ALTO should NOT attempt to be privacy preserving,  
because the protocols that use it won't be privacy preserving anyway.
Y. R. Yang | 1 Mar 18:23 2009
Picon

Re: Comments on requirements draft


On Sun, 1 Mar 2009, 8:08am -0800, Nicholas Weaver wrote:

> Looking at the current draft, a few thoughts....
> 
> The usage cases may be too broad.  EG, local mirror/caching discovery 
> for conventional CDN operation doesn't need to rely on alto, and would 
> probably not benefit, as the conventional CDNs have solved the problem 
> "good enough", and it also interacts with their OWN secret-sauce.
> 
> My thought would be focus on the two useage cases which count:
> 
> Bulk data P2P peer localization, and P2P hashtable localization, where 
> the first is about saving cost while providing the same service, while 
> the latter is reducing latency.

Can you elaborate some more on reducing latency only for P2P hashtable?

> On security considerations, any open-world P2P system per file can be 
> tracked from one or more nodes by creating sybils, so ALTO doesn't make 
> the problem easier, and any P2P system which deliberately hides this 
> (eg, by onion-routing data) is not going to WANT localization and 
> increased localization increases the power of traffic analysis.
> 
> Thus I believe that ALTO should NOT attempt to be privacy preserving, 
> because the protocols that use it won't be privacy preserving anyway.

You mean no privacy preserving only for P2P clients. I have to disagree. 
Here are some reasons: (1) Giving ALTO Servers such information will make 
it possible for some parties to demand that such information be collected; 
(Continue reading)

Y. R. Yang | 1 Mar 18:34 2009
Picon

Re: Comments on requirements draft


On Sat, 28 Feb 2009, 1:11pm +0200, Spiros Spirou wrote:

> Hi Sebastian, all,
> On 25 ??? 2009, at 3:18 ??, Sebastian Kiesel wrote:
> 
> > On Wed, Feb 25, 2009 at 10:02:14AM +0200, Spiros Spirou wrote:
> >> In the current draft, info seems to flow only
> >> from the ALTO service to the P2P system. I feel that there is (or  
> >> should
> >> be) a reverse flow of info as well: the P2P system informs the  
> >> provider of
> >> the ALTO service (realistically, a network operator) about P2P system
> >> traffic, so that the operator can do efficient traffic management.
> >
> > The extension you propose here sounds interesting but is rather
> > substantial, so I kindly ask you to give us more information (if you
> > have any), and the other folks here on the list to comment on it:
> >
> > - Are there any field trial or simulation results, which show that
> > this mode of operation can improve the situation?
> 
> When an ALTO Client contacts the ALTO Service it indirectly provides  
> two pieces of info: host identity (e.g. IP address) and application  
> type (e.g. P2P). When the ALTO Client also submits a list of Transport  
> Addresses of candidate Resource Providers to be ranked by the ALTO  
> Service, it provides several pieces of additional info: host  
> identities and application type of other nodes. When all these pieces  
> are combined, the ALTO Service can deduce a set of specific  
> application flows. This information, as has been shown by several  
(Continue reading)

Y. R. Yang | 1 Mar 19:52 2009
Picon

Re: Comments on requirements-01


Hi Reinaldo,

Thanks a lot for the wonderful feedback! Kiesel is the editor, and sure 
will respond to your great suggestions. Here are my take. Please see 
below.

On Fri, 27 Feb 2009, 12:57pm -0800, Reinaldo Penno wrote:

> Hello,
> 
> As a general comment, the draft does not feel like requirements and more
> like a possible protocol solution and at the same time many REQs need to be
> more specific about what the requirement actually is.
> 
> I think this draft needs quite a bit of work. Are there plans for an update
> for the next IETF?
> 
> Specific comments:
> 
> 1) "ALTO Interface"
> 
> What is an ALTO interface?

How about change to ALTO Query/Response Protocol?

> 2)
> 
> "   REQ. 1: The ALTO service MUST implement one or several well-defined
>    interfaces, which can be queried from ALTO clients."
(Continue reading)

Reinaldo Penno | 2 Mar 00:08 2009
Picon

Re: Comments on requirements-01

Thanks for the comments Richard. Responses online....

On 3/1/09 10:52 AM, "Y. R. Yang" <yry <at> cs.yale.edu> wrote:

> 
> Hi Reinaldo,
> 
> Thanks a lot for the wonderful feedback! Kiesel is the editor, and sure
> will respond to your great suggestions. Here are my take. Please see
> below.
> 
> On Fri, 27 Feb 2009, 12:57pm -0800, Reinaldo Penno wrote:
> 
>> Hello,
>> 
>> As a general comment, the draft does not feel like requirements and more
>> like a possible protocol solution and at the same time many REQs need to be
>> more specific about what the requirement actually is.
>> 
>> I think this draft needs quite a bit of work. Are there plans for an update
>> for the next IETF?
>> 
>> Specific comments:
>> 
>> 1) "ALTO Interface"
>> 
>> What is an ALTO interface?
> 
> How about change to ALTO Query/Response Protocol?

(Continue reading)

stefano previdi | 2 Mar 20:10 2009
Picon

Fwd: New Version Notification for draft-akonjang-alto-proxidor-00

FYI

s.

Begin forwarded message:
> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: March 2, 2009 5:46:43 PM GMT+01:00
> To: obi <at> net.t-labs.tu-berlin.de
> Cc: anja <at> net.t-labs.tu-berlin.de, sprevidi <at> cisco.com,  
> bsd <at> cisco.com, damien.saucez <at> uclouvain.be
> Subject: New Version Notification for draft-akonjang-alto-proxidor-00
>
>
> A new version of I-D, draft-akonjang-alto-proxidor-00.txt has been  
> successfuly submitted by Obi Akonjang and posted to the IETF  
> repository.
>
> Filename:	 draft-akonjang-alto-proxidor
> Revision:	 00
> Title:		 The PROXIDOR Service
> Creation_date:	 2009-03-02
> WG ID:		 Independent Submission
> Number_of_pages: 16
>
> Abstract:
> Several applications, such as peer-to-peer (P2P), content
> distribution and realtime services rely on selection mechanisms in
> order to select the peer or server from which to request the service.
> Examples of such services are: file sharing, media streaming and
> voice gateways.
(Continue reading)

Martin Stiemerling | 3 Mar 11:17 2009
Picon

FW: I-D Action:draft-stiemerling-alto-h1h2-protocol-00.txt

Hi folks,

Just FYI and there is also a related draft. Coming as next email :)

This draft tries to sketch the current situation that there might be dilemma.

  Martin

stiemerling <at> nw.neclab.eu

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England
2832014 

> -----Original Message-----
> From: i-d-announce-bounces <at> ietf.org [mailto:i-d-announce-
> bounces <at> ietf.org] On Behalf Of Internet-Drafts <at> ietf.org
> Sent: Monday, March 02, 2009 2:45 PM
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-stiemerling-alto-h1h2-protocol-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : ALTO H1/H2 Protocol
> 	Author(s)       : M. Stiemerling, S. Kiesel
> 	Filename        : draft-stiemerling-alto-h1h2-protocol-00.txt
> 	Pages           : 10
> 	Date            : 2009-03-02
> 
(Continue reading)

Martin Stiemerling | 3 Mar 11:18 2009
Picon

FW: I-D Action:draft-kiesel-alto-h12-00.txt

Hi,

This the second draft, relating also to ALTO H1/H2 Protocol. 

This draft takes a step back and tries to get the best out of the two ways of H1/H2.

  Martin

stiemerling <at> nw.neclab.eu

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England
2832014 

> -----Original Message-----
> From: i-d-announce-bounces <at> ietf.org [mailto:i-d-announce-
> bounces <at> ietf.org] On Behalf Of Internet-Drafts <at> ietf.org
> Sent: Tuesday, March 03, 2009 10:00 AM
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-kiesel-alto-h12-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : ALTO H12
> 	Author(s)       : S. Kiesel, M. Stiemerling
> 	Filename        : draft-kiesel-alto-h12-00.txt
> 	Pages           : 11
> 	Date            : 2009-03-03
> 
(Continue reading)

Nicholas Weaver | 4 Mar 16:37 2009
Picon

New draft submitted...

http://www.ietf.org/internet-drafts/draft-weaver-alto-edge-caches-00.txt

I just submitted a new draft on why I think P2P edge caches are  
necessary, and how localization interacts with edge-caches.

Among other things, edge-cache support requires associating filename  
information with requests (and therefore has privacy implications), etc.

Abstract:
    Without caches in the infrastructure, peer to peer content  
delivery's
    primary effect is cost shifting rather than cost savings.  Even with
    perfect localization, depending on the relative cost of last-mile
    uplink bandwidth verses transport bandwidth, P2P may substantially
    increase aggregate cost.  Yet the addition of edge caches, caches
    located in the ISPs near the customers, radically change the
    economics of P2P content delivery.  Edge caches interact very
    strongly with localization services for P2P content delivery, and  
any
    localization service must be tightly integrated into edge-cache
    operation.

Comments greatly appreciated.
TOMSU, Marco | 4 Mar 13:58 2009
Picon

[Fwd: New Version Notification for draft-wang-alto-discovery-00]

Folks,
the following draft on ALTO Service Discovery has been submitted.

Marco

-------- Original-Nachricht --------
Betreff:        New Version Notification for draft-wang-alto-discovery-00
Datum:  Tue, 3 Mar 2009 18:01:44 -0800 (PST)
Von:    IETF I-D Submission Tool <idsubmission <at> ietf.org>
An:     yu-shun.wang <at> microsoft.com
CC:     ggb <at> tid.es, marco.tomsu <at> alcatel-lucent.com



A new version of I-D, draft-wang-alto-discovery-00.txt has been successfuly submitted by Yu-Shun Wang and posted to the IETF repository.

Filename:        draft-wang-alto-discovery
Revision:        00
Title:           ALTO Discovery Protocols
Creation_date:   2009-03-03
WG ID:           Independent Submission
Number_of_pages: 13

Abstract:
The Application-Layer Traffic Optimization service aims to provide
applications with information to perform better-than-random initial
peer selection when multiple peers in the network are available to
provide a resource or service. This document discusses the discovery
protocols for the service.
                                                                                 


The IETF Secretariat.



_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto

Gmane