Subject: [p2pi] ALTO BoF - generalize the problem

From: Damien Saucez <[email-masked]>
Date: Tue, 08 Jul 2008 14:30:00 +0200

Dear all,

We believe that the ALTO problem can't be restricted to the P2P case
only. As already discussed on this mailing list, we must consider the
problem to be addressed by ALTO in its whole in order to build a
solution that is application independent. In other words, the techniques
that will be developped in ALTO must not rely on a particular kind of
application or traffic. This approach is required in order to build a
traffic optimization scheme that is future-proof and can thus address
future application needs. Indeed, experience has known that global
trends in applications and traffic can dramatically change within a few
years and even less sometimes.

However, being application independant is not sufficient. As some works
already investigate (see summary in the ALTO survey), traffic
optimization can be improved by allowing cross layer cooperation.

For these purposes, we propose 

1. To extend the scope of ALTO so as to consider a global framework that
allows traffic optimization. This framework should not only be
application independant but also layer independant. Layer independence
should allow for cooperation between applications and operators (with or
without a third party involved).

2. To phase the workplan. Firstly, a crisp outline must be given for the
problem we are trying to solve. Secondly, a set of design goals must be
written to facilitate consensus. Finally, an application/layer
independant architectural framework must be worked on to solve the
problem with the current but also the future Internet traffic.

Regards,

Damien Saucez

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 07, 2008 2:00 PM
To: [email-masked]
Subject: I-D Action:draft-saucez-alto-generalized-alto-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Why should the Traffic Optimization not be restricted to the Application-Layer?
	Author(s)       : D. Saucez, D. Papadimitriou
	Filename        : draft-saucez-alto-generalized-alto-00.txt
	Pages           : 8
	Date            : 2008-07-07

The Application-Layer Traffic Optimization (ALTO) problem is being
discussed within the IETF and more globally by the research community
and some enterprises.  In this memo, we argue that it is important to
conceive general-purpose mechanisms to solve this problem.  By
general-purpose we say not only application independent but also
layer independent mechanism.  The generality can be obtained because
the underlying problem is the same regardless the application or the
layer.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saucez-alto-generalized-alto-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft. 

_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 8 Jul 2008 15:42:03 +0200

> As already discussed on this mailing list, we 
> must consider the problem to be addressed by ALTO in its 
> whole in order to build a solution that is application 
> independent. In other words, the techniques that will be 
> developped in ALTO must not rely on a particular kind of 
> application or traffic. This approach is required in order to 
> build a traffic optimization scheme that is future-proof and 
> can thus address future application needs. Indeed, experience 
> has known that global trends in applications and traffic can 
> dramatically change within a few years and even less sometimes.
> However, being application independant is not sufficient. As 
> some works already investigate (see summary in the ALTO 
> survey), traffic optimization can be improved by allowing 
> cross layer cooperation.

I do not get your point, ALTO is already application independent
as such. I do not see any application-specific wording in the
problem statement.

Also it is indeed cross-layer since it will consider applications
gathering info from IP layer and routing to make better decisions,
in addition to decide based on application-layer metrics.

For conveying requirements from the application layer to lower layers
you can also check out the various QoS framework proposals by IETF
and other bodies.

If you want to consider other layer then maybe this BoF is not the
right one for you, for transport issues you should better refer to
the TANA BoF.

> 1. To extend the scope of ALTO so as to consider a global 
> framework that allows traffic optimization. This framework 
> should not only be application independant but also layer 
> independant. Layer independence should allow for cooperation 
> between applications and operators (with or without a third 
> party involved).

Traffic optmization is already in the scope of ALTO, ALTO is starting
from a real-world problem that is documented, before extending it too
broadly beyond that to make "THE GENERAL FRAMEWORK" you should state
better what is the motivation for that and reflect carefully if it is
possible to get such a work chartered at all.

ALTO instead addresses a clear operational discussed already in the
P2P-I meeting in May and we all agree we need solutions for this, while
I do not see why I would need yet another traffic optimization framework
to control QoS in operators networks (maybe better go to ETSI TISPAN?)

> 2. To phase the workplan. Firstly, a crisp outline must be 
> given for the problem we are trying to solve. Secondly, a set 
> of design goals must be written to facilitate consensus. 
> Finally, an application/layer independant architectural 
> framework must be worked on to solve the problem with the 
> current but also the future Internet traffic.

The problem statement is there and is much more clear than
"let's build the general traffic optimization framework"

As I said I think ALTO is already application-independent and
cross-layer thus I see no point discussing this issue further.

Cheers,
Saverio

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> 	Title           : Why should the Traffic Optimization 
> not be restricted to the Application-Layer?
> The Application-Layer Traffic Optimization (ALTO) problem is 
> being discussed within the IETF and more globally by the 
> research community and some enterprises.  In this memo, we 
> argue that it is important to conceive general-purpose 
> mechanisms to solve this problem.  By general-purpose we say 
> not only application independent but also layer independent 
> mechanism.  The generality can be obtained because the 
> underlying problem is the same regardless the application or 
> the layer.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft. 
> 

============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

---

From: stefano previdi <[email-masked]>
Date: Tue, 08 Jul 2008 16:04:20 +0200

Damien,

We've clearly specified in the requirements draft that p2p application is
one possible but not the only one (this should partially address your
concerns). 

So, ALTO being already application agnostic, nothing prevents you to
consider ALTO providing a service which can be consumed by any other entity
residing in any other layer (even the one where ALTO operates).

s.

> From: Damien Saucez <[email-masked]>
> 
> Dear all,
>

---

From: Laird Popkin <[email-masked]>
Date: Tue, 8 Jul 2008 10:21:26 -0400 (EDT)

I'd like to second this:

- ALTO is application independent. That is, while the ALTO was inspired by the issues raised by p2p applications, there's nothing specific to p2p applications in the ALTO proposal, and it's intended to be useful for other applications. In particular, we ALTO being very useful for (for example) identifying relays for NAT traversal for VOIP, or connecting players optimally in MMORPGs. If there any requirements that assume p2p, please point them out so that they can be generalized.
- ALTO is focused on the application level, as there is another effort (TANA) addressing transport level issues. The two efforts are (hopefully) being coordinated.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "stefano previdi" <[email-masked]>
To: "Damien Saucez" <[email-masked]>, [email-masked]
Cc: "PAPADIMITRIOU Dimitri" <[email-masked]>, "Olivier Bonaventure" <[email-masked]>
Sent: Tuesday, July 8, 2008 10:04:20 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO BoF - generalize the problem

Damien,

s.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 8 Jul 2008 16:40:46 +0200

> From: Saverio Niccolini [mailto:[email-masked]] 
> Sent: Tuesday, July 08, 2008 3:42 PM
> To: Damien Saucez; [email-masked]
> Cc: Olivier Bonaventure; PAPADIMITRIOU Dimitri
> Subject: RE: [p2pi] ALTO BoF - generalize the problem
> 

as such referring to the problem statement, i see:

Section 1:

"This document describes the problem of optimizing traffic generated
 by P2P applications using information provided by third parties.
 Section 2 introduces the problem and the main issues to keep in mind
 when designing a solution, while Section 3 describes some use cases
 where both P2P users and network operators would benefit from such a
 solution."

Section 2:

"Addressing the Application-Layer Traffic Optimization (ALTO) problem
 means, on the one hand, providing topology information regarding the
 underlying network and, on the other hand, enhancing P2P applications
 in order to use such information to select the best endpoints among
 those that are available for the connections they are going to
 establish."

Section 2.1.1.

"2.1.1. Information Distribution

 As a direct consequence of the total distribution of the Internet, it
 seems almost impossible to centralize all information P2P
 applications may need to optimize traffic they generate.  It is quite
 likely that such information would be highly distributed, for
 example, at an ISP or domain level.  It is also reasonable to expect
 that, in some cases, the same network administrators will control
 provision of such information."

Section 2.1.2

"... therefore, in order to succeed and
 achieve wide adoption, any solution should provide a method to help
 P2P applications in peer selection without explicitly disclosing
 topology of the underlying network."

Section 3, mainly focuses on p2p, three of the 5 sections 3.x have the
word p2p in their first sentence and 3.1 is almost about the same.

> right one for you, for transport issues you should better refer to

So if i understand your reasoning an operator will have to host a
specific entity per requesting "layer" or applicative space ? even if
the mechanism to gather info from IP layer and routing to make better
decisions would be the same ?

> possible to get such a work chartered at all.

simply because without cooperation - the self-fishness vs resource
sharing problem will remain unadressed.  
 
> P2P-I meeting in May and we all agree we need solutions for this
> while I do not see why I would need yet another traffic 
> optimization framework

you are over-reading the initial e-mail i think. 

but very surprisingly you question the issue of cooperation while that
statement is clearly in the problem statement, Section 2, you seem to
support

""cooperating" with external services aware of the network topology
could greatly optimize the traffic they generate.

> cross-layer thus I see no point discussing this issue further.

reading your reply i feel like a BoF wouldn't even be necessary... the
message you do not get apparently is that p2p traffic results in issue
today but tomorrow it will be another type of application. 

-d.

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 8 Jul 2008 17:37:35 +0200

Ok, 

I now get your point:
you do not like P2P as being the application ALTO is focusing on.

Actually:
-- P2P is written in the problem statement and in every motivation of ALTO
because P2P are the type of applications motivating Application Layer Traffic
Optmization. --> this is a real-world problem IETf is here to address

In your draft you are not providing evidence why the general framework would
be needed by other type of applications, thus I do not see why the group should
be considering this option.

As such I see: P2P are motivating this work and there is not evidence that other
type of applications would need what you call "the general framework"

Moreover:
-- if you look at the requirements draft (http://tools.ietf.org/id/draft-kiesel-alto-reqs-00.txt) 
there is an explicit sentence where it is written:
"The goal of ALTO is to provide information which can help peer-to-
peer (P2P) applications to make better decisions with respect to peer
selection.  However, ALTO may be useful for non-P2P applications as
well."

In the requirement draft P2P applications are only used as examples
but the requirements are general for every type of application.

This express why I said: "ALTO is not application specific".

As last thing:
I think we do not agree on terminology:
you can not say ALTO is application specific if it considers a class of
applications (P2P ones) and it also meant to be useful for non-P2P ones.

P2P is indeed NOT application-specific, any type of application can use the
P2P paradigm.

Maybe you want to re-phrase your statement?

Cheers,
Saverio

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 8 Jul 2008 17:52:07 +0200

PAPADIMITRIOU Dimitri wrote:
> [...]

Actually the problem statement is application independent (in that it
does not address one particular application), but does not aim at
covering all conceivable applications; instead, it focuses on a subset
of them which share similar characteristics and generally refers to them
as P2P, even if it covers also client/server use cases (in S3.5 in
version 01, more extensively in the version under refinement.)

> decisions would be the same ?

Of course, if the same mechanism developed in ALTO could also be used at
network layers other than the application layer (from what I've read, I
may see a case for using something like ALTO in LISP), there is nothing
wrong in using it.

-- 
Ciao,
Enrico

---

From: Bruce Davie <[email-masked]>
Date: Tue, 8 Jul 2008 12:24:38 -0400

A couple of points:

   - while one can find plenty of quotes in draft-marocco-alto- 
problem-statement-01.txt that reflect the fact that p2p apps are a  
main motivation for this BOF, one could also point to many statements  
in draft-kiesel-alto-reqs-00.txt that indicate the desire to be  
broader than just p2p apps, for example:

    "The goal of ALTO is to provide information which can help peer-to-
    peer (P2P) applications to make better decisions with respect to  
peer
    selection.  However, ALTO may be useful for non-P2P applications as
    well.  For example, clients of client-server applications may use
    information provided by ALTO to select one of several servers or
    information replicas..."

  - a BOF which has too broad a scope is unlikely to lead  
successfully to a working group.

So let's not get carried away with generalizing the problem to the  
point where it is no longer "well-scoped and solvable" (in the words  
of draft-narten-successful-bof-03.txt)

Bruce Davie

---

From: Damien Saucez <[email-masked]>
Date: Tue, 08 Jul 2008 18:30:59 +0200

Saverio,

>you do not like P2P as being the application ALTO is focusing on.
We are not against P2Ps and we know that P2P is a major application for 
the ALTO problem. However, we think that it is really important to focus 
ALTO on all the applications and not on to say "ok, ALTO works also with 
other applications than P2P".

Of course, when I read the drafts and the mails, I can see that you what 
to be independent, but it seems to be a secondary requirement and for me 
the genericity is the key of ALTO.

>Optmization. --> this is a real-world problem IETf is here to address
P2P is not the only real-world problem. We are from the routing world 
and we observe that you have the same problems as us and surprisingly 
the same solutions (the oracle and IDIPS have been designed 
independently and are more or less the same, the oracle was for P2P and 
IDIPS comes from NAROS discussed for the IPv6 multihoming problem), so 
what the draft says is to work together to avoid making systems doing 
the same things independently (waste or ressources).

>P2P is indeed NOT application-specific, any type of application can use the
Sure, we don't say alto is related to application XYZ, but is limited to 
the application layer (AL stands for Application Layer) and people 
working on the problem mainly come from the P2P world. Once again, the 
idea of the discussion is to insist on the fact that ALTO can be very 
generic without sacrifying anything. IDIPS works with LISP, SHIM6, dual 
stack machines, P2P, FTP or CDNs so our solutions (P4P, oracle) should 
probably also work with many different paradigms and what we would like 
is to extend ALTO to that point.

>Maybe you want to re-phrase your statement?

Thanks for your discussion Saverio.

Damien Saucez

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 8 Jul 2008 18:48:01 +0200

Dear Damien,

I see your point but in my opinion it does not make sense to go
broader that what ALTO is already right now.

I see ALTO problem statement and requirements a good trade-off of
trying to be general while trying to address a well scoped problem
area. --> that is the real challenge and I think ALTO people is
doing a great job on this.

As also Bruce pointed out:
- a BOF which has too broad a scope is unlikely to lead  
successfully to a working group. (IETF non-written rule)

I would encourage you to help the ALTO work in getting chartered
instead of claiming for "the general framework" that is most probably
not going to get consensus.

Saverio

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Damien Saucez
> Sent: Tuesday, July 08, 2008 6:31 PM
> To: Saverio Niccolini
> Cc: Olivier Bonaventure; [email-masked]; PAPADIMITRIOU Dimitri
> We are not against P2Ps and we know that P2P is a major 
> application for the ALTO problem. However, we think that it 
> is really important to focus ALTO on all the applications and 
> not on to say "ok, ALTO works also with other applications than P2P".
> 
> Of course, when I read the drafts and the mails, I can see 
> that you what to be independent, but it seems to be a 
> secondary requirement and for me the genericity is the key of ALTO.
> 
> >Actually:
> >-- P2P is written in the problem statement and in every 
> motivation of 
> >ALTO because P2P are the type of applications motivating Application 
> >Layer Traffic Optmization. --> this is a real-world problem IETf is 
> >here to address
> >
> >  
> >
> P2P is not the only real-world problem. We are from the 
> routing world and we observe that you have the same problems 
> as us and surprisingly the same solutions (the oracle and 
> IDIPS have been designed independently and are more or less 
> the same, the oracle was for P2P and IDIPS comes from NAROS 
> discussed for the IPv6 multihoming problem), so what the 
> draft says is to work together to avoid making systems doing 
> >In your draft you are not providing evidence why the general 
> framework 
> >would be needed by other type of applications, thus I do not see why 
> >the group should be considering this option.
> >
> >As such I see: P2P are motivating this work and there is not 
> evidence 
> >that other type of applications would need what you call 
> "the general framework"
> >
> >  
> >
> >Moreover:
> >-- if you look at the requirements draft 
> >(http://tools.ietf.org/id/draft-kiesel-alto-reqs-00.txt)
> >In the requirement draft P2P applications are only used as 
> examples but 
> >the requirements are general for every type of application.
> >
> >P2P is indeed NOT application-specific, any type of 
> application can use 
> >the P2P paradigm.
> >
> >  
> >
> Sure, we don't say alto is related to application XYZ, but is 
> limited to the application layer (AL stands for Application 
> Layer) and people working on the problem mainly come from the 
> P2P world. Once again, the idea of the discussion is to 
> insist on the fact that ALTO can be very generic without 
> sacrifying anything. IDIPS works with LISP, SHIM6, dual stack 
> machines, P2P, FTP or CDNs so our solutions (P4P, oracle) 
> should probably also work with many different paradigms and 
> what we would like is to extend ALTO to that point.
> 
> >NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> >London W3 6BL Registered in England 2832014
> >  
> >
>

---

From: Damien Saucez <[email-masked]>
Date: Tue, 08 Jul 2008 18:56:50 +0200

Saverio,

>I would encourage you to help the ALTO work in getting chartered
Of course I'll do.

>not going to get consensus.
But I'll try because for me it is the key point for the future of the 
Internet. Look at what is happening on the control plane, it's 
completely out of control with protocol redundancy. Control plane is 
ugly because most of the protocols have been design without taking care 
of what is done in other domains (which do the same things but with 
other low level objectives).

Regards,

Damien Saucez

>>>peer (P2P) applications to make better decisions with 
>>>      
>>>
>>respect to peer 
>>    
>>
>>>you can not say ALTO is application specific if it considers 
>>>      
>>>
>>a class of 
>>    
>>
>>>applications (P2P ones) and it also meant to be useful for 
>>>      
>>>
>>non-P2P ones.
>>    
>>

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 8 Jul 2008 19:08:34 +0200

> >I would encourage you to help the ALTO work in getting chartered

Good, this is the most important thing :-)

> But I'll try because for me it is the key point for the 
> future of the Internet. Look at what is happening on the 
> control plane, it's completely out of control with protocol 
> redundancy. Control plane is ugly because most of the 
> protocols have been design without taking care of what is 
> done in other domains (which do the same things but with 

I understand your point and I see you being right in the ideal world
(I used to live in that one as well but facts are bringing me back to
the reality)

at the same time I do not think that ALTO can make order in the
"control plane jungle" and come up with THE ONE.

IETF charters well-scoped work and tries to listen for consensus,
I am sure there is people that thinks like you (and I see you making
reasonable statements) but they also realize there is no point to
try to sove the problem on such a broad scale. It is better do a small
piece of work than do not have the WG at all (that is why people is
fine with ALTO scope as it is).

Cheers,
Saverio

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 9 Jul 2008 00:01:12 +0200

> Sent: Tuesday, July 08, 2008 5:38 PM
> To: PAPADIMITRIOU Dimitri; Damien Saucez; [email-masked]
> Cc: Olivier Bonaventure
> motivation of ALTO

it is a - clear - example from where problems observed today can be
drawn i.e. defines a motivation but not a solution space/scope.

> framework would
> be needed by other type of applications, thus I do not see 
> why the group should be considering this option.

the problem is that the Internet has no means to efficiently address the
challenges posed by applications operating transparently or even trying
to solve networking problems at the applicative level - reason why a
cooperation would be beneficial for both parties.

the proposal is to work on such kind of solution instead of having to
address each application-traffic optimization problem separately

> evidence that other

be "application layer independent" is different from being "not P2P
application specific"    

> a class of applications (P2P ones) and it also meant to be 
> useful for non-P2P ones.
>
> application can use the P2P paradigm.
> 

you should see the position in the other way around. i have the subtle
impression that the real issue is not whether p2p needs a specific
solution but whether the internet at large has to deliver a suitable
answer to accommodate efficiently various application traffic and we
have in the p2p context the most illustrative example.

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 9 Jul 2008 09:56:27 +0200

> address each application-traffic optimization problem separately

ALTO targets applications dealing with resources available at multiple
locations. I agree that the term "P2P applications" is a poor choice
Vijay and I are to blame for, but so far it has proved quite effective
in helping people capture the problem we are tackling here. Suggestions
for a better terminology are of course welcome.

> be "application layer independent" is different from being "not P2P

The concept of layer independence is probably what made people jump from
their chairs. Could you explain, possibly with some examples, what you
mean by it? I guess you are not disputing the fact that protocols
specified in ALTO will be application-level protocols (i.e. built upon
transport protocols like TCP, UDP, or DCCP), right?

---

From: stefano previdi <[email-masked]>
Date: Wed, 09 Jul 2008 11:49:20 +0200

Damien,

> the genericity is the key of ALTO.

As already pointed out, p2p application is going to be the trigger for a WG
constitution so it's normal to emphasize this specific case. I believe we're
all in sync on this, right ?

The fact is that we have to proceed by steps and this one (probably the most
delicate) is to form a WG with a precise scope.
 
> P2P is not the only real-world problem. We are from the routing world

me too...

> and we observe that you have the same problems as us

I'm not fully convinced you can make such a parallel...

> and surprisingly 

that's why I stated (in my first reply to you) that:
    So, ALTO being already application agnostic, nothing prevents
    you to consider ALTO providing a service which can be consumed
    by any other entity residing in any other layer (even the one
    where ALTO operates).

Also, at this stage, we propose to work on the signaling part between ALTO
providers and consumers. There's not (yet) a layering issues here.

[...]

> generic without sacrifying anything.

ALTO services delivered to an application entity do not have the same set of
constraints of an ALTO service delivered to a routing entity.

Example: in the hop-by-hop routing paradigm, routing decisions MUST be
consistent. Interoperability at routing layer is a MUST while application
peer/server/whatever selection may be done orthogonally (even if you
leverage routing databases). For sure (and I probably anticipate your answer
here) using BGP recursion, MPLS/IP encap, and so on, you can also have an
orthogonal approach...

This is just _one_ example where making ALTO generic to any layer implies a
significant differently approach.

Disclaimer: I'm not stating we shouldn't do it... I just want to point out
that the "whole picture" is significantly different.

> IDIPS works with LISP, SHIM6, dual

As specified in the requirements draft, and at this stage, we want to focus
on the signaling part of the picture (between ALTO providers and consumers).

This does not preclude any form of algorithm extensions in order to cope
with other cases but not at this stage of the work. Going for a routing
approach will forces us to work on the algorithms as well... and by
experience (believe me) this would be _very_ long term work.

> completely out of control with protocol redundancy.

Well, stating the control plane is "out of control" looks to me (a bit) as
an overstatement... but I see what you mean (from a routing perspective).

> Control plane is 

I think I have a slight different vision: protocols have been defined,
engineered and deployed with a pragmatical focus in order to address
specific problems and issues.

Maybe you are right: a better understanding of the whole picture would have
helped in defining a better (and maybe less number of) protocols.

The problem is the same: who can claim to have the best view and _now_ ?

Thanks.

s.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 9 Jul 2008 16:40:48 +0200

> From: Enrico Marocco [mailto:[email-masked]] 
> Sent: Wednesday, July 09, 2008 9:56 AM
> To: PAPADIMITRIOU Dimitri
> Cc: Saverio Niccolini; Damien Saucez; [email-masked]; Olivier 
> Bonaventure
> in helping people capture the problem we are tackling here. 
> Suggestions for a better terminology are of course welcome.

something like distributed resource application would do it probably
(but just a suggestion)

> mean by it? 

what is meant here is that cooperation between the "application" and the
"operators" must rely on an abstraction of the different layers
information (in part. network) to the higher layer without having to
know from where the information comes and its actual distribution. so
cooperation from abstration which is a mechanism that can be used for
topology hiding purposes (the latter is mentioned in the ps doc.)

> I guess you are not disputing the fact that protocols

right.

-d.

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 9 Jul 2008 17:05:14 +0200

> topology hiding purposes (the latter is mentioned in the ps doc.)

Well, this seems perfectly in line with what ALTO proposes: a
request/response protocol for querying sources of topology information
and a discovery mechanism for finding such sources. How to provide
topology information -- in form of Vivaldi-like coordinates, for
example, or as a "sorting oracle" -- is not going to be discussed now,
but will be decided by the working group (if we manage to have one
approved).

The only difference I can see is that we want to design such mechanisms
in order to allow also non-operator third-parties to provide the same
kind of service, but I think this would not be an issue for you either.

---

From: Damien Saucez <[email-masked]>
Date: Wed, 09 Jul 2008 17:22:37 +0200

Enrico Marocco wrote:

>and a discovery mechanism for finding such sources.
>
good

> How to provide
maybe even with an inclusive or

>kind of service, but I think this would not be an issue for you either.
We agree as the origine/destination has no importance, it is 
non-operator third-parties capable.

Thanks,

Damien Saucez

---

From: Stanislav Shalunov <[email-masked]>
Date: Wed, 9 Jul 2008 11:37:16 -0700

On Jul 8, 2008, at 9:30 AM, Damien Saucez wrote:
> However, we think that it is really important to focus ALTO on all  
> the applications and not on to say "ok, ALTO works also with other  
> applications than P2P".

How can you focus on all?  You focus on something specific, or you  
don't focus at all.

A BoF without focus is less likely to be successful.  You seem to be  
objecting to the fact that the problem has a real-world motivator.  If  
it did not, it would not be worth solving for the IETF.

-- 
Stanislav Shalunov
http://shlang.com

---

From: "Damien Saucez" <[email-masked]>
Date: Wed, 9 Jul 2008 23:00:02 +0200 (CEST)

> How can you focus on all?  You focus on something specific, or you
I rephrase: focus on being general. In other word: take care of not
solving a subset of the problem that can be solved.

> objecting to the fact that the problem has a real-world motivator.
Not at all, I agree that an important problem exists with P2P and that it
is a real-world problem.

Once again: I agree that there is a problem and what I say is that it
could be interesting to solve the problem using techniques able to solve
other equivalent problem (even if they not seem to be equivalent). But,
for that, it is important to be aware of the other problems (Stefano could
be the "bridge" between P2P and routing).

>  If

So, to close the thread: let's keep ALTO as it is for the moment, just
keep in mind for later that ALTO is also interesting in the routing world
and maybe other worlds.

Cheers,

Damien Saucez

---

From: "Stanislav Shalunov" <[email-masked]>
Date: Wed, 9 Jul 2008 16:47:23 -0700

We're all in agreement, I believe.  ALTO should be applicable to
things beyond P2P.

Another important problem that ALTO is applicable to is the selection
of the closest CDN node.

Or even finding HTTP proxies, SMTP servers, etc., etc.

-- Stas

-- 
Stanislav Shalunov
http://shlang.com/

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 10 Jul 2008 09:22:14 +0200

> I rephrase: focus on being general. In other word: take care 
> of not solving a subset of the problem that can be solved.

What you propose is not IETF.

IETF WGs solve a specific problem, that is what the charter is for.
A general charter will never be approved for a WG.

Thus I think we should stop discussing this "general is nice"
because will not lead anywhere for ALTO (since we are in the IETF,
if you want to write a paper and submit to a conference/magazine
maybe it is fine)

Saverio

> Not at all, I agree that an important problem exists with P2P 
> and that it is a real-world problem.
> 
> Once again: I agree that there is a problem and what I say is 
> that it could be interesting to solve the problem using 
> techniques able to solve other equivalent problem (even if 
> they not seem to be equivalent). But, for that, it is 
> important to be aware of the other problems (Stefano could be 
> the "bridge" between P2P and routing).
> 
> >  If
> So, to close the thread: let's keep ALTO as it is for the 
> moment, just keep in mind for later that ALTO is also 
> interesting in the routing world and maybe other worlds.
> 
> Cheers,
> 
> Damien Saucez
>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 10 Jul 2008 16:38:41 +0200

from this thread, i see the following trend:

1. mechanisms for enabling a request/response protocol for querying
sources of topology information and mechanism for discovering such
sources are within ALTO scope - decision on the actual mechanism will be
discussed in the course of the working group.

2. applicative scope is "ALTO targets applications dealing with
resources available at multiple locations." - with terminology to be
updated (in case). mechanisms/solutions target these apps (without
preventing larger applicability).

-> if BoF chairs can confirm whether this is case or not, this would
greatly help progressing the debate

-d.

> Behalf Of Saverio Niccolini
> Sent: Thursday, July 10, 2008 9:22 AM
> To: Damien Saucez; Stanislav Shalunov
> Cc: [email-masked]

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 10 Jul 2008 16:56:39 +0200

> greatly help progressing the debate

According to me, this reflects pretty well the interest expressed by the
group.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 10 Jul 2008 08:06:06 -0700

I would like some clarification.

I'm not sure I follow the first paragraph as in "querying sources of
topology information" and "discovering such sources".

My understanding was (using P2P terminology) that ALTO would provide means
for a client/peer to query a ALTO 'server' and get list of metrics (whatever
they are) related to a list of peers given by the client. The client would
make some decision based on such metrics.

Or a client might give such a list to the ALTO server and ask such a list to
be ordered according to some policy.  Of course the same list would be
ordered differently if the purpose is streaming media, file sharing,
replication or others.

Is an ALTO 'server' a 'source of topology information'? Topology information
related to peers/clients holding/providing content/resources or something
else?

Thanks,

Reinaldo

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 10 Jul 2008 17:26:30 +0200

ALTO server (or whatever logical function, that in literature
is called "topology oracle" as far as I know) can be one of
the source of information that enables Application Layer Traffic
Optimization.

What it is holding/providing and how will be decided once ALTO
is chartered and we have a WG that works on that, I do not think
this can be decided (nor should be) before or within the BoF.

We should not even discuss this here now.

Correct me if I am wrong,
Saverio

> Behalf Of Reinaldo Penno
> Sent: Thursday, July 10, 2008 5:06 PM
> To: Enrico Marocco; PAPADIMITRIOU Dimitri
> Cc: [email-masked]; Saverio Niccolini
> I'm not sure I follow the first paragraph as in "querying 
> sources of topology information" and "discovering such sources".
> 
> My understanding was (using P2P terminology) that ALTO would 
> provide means for a client/peer to query a ALTO 'server' and 
> get list of metrics (whatever they are) related to a list of 
> peers given by the client. The client would make some 
> decision based on such metrics.
> 
> Or a client might give such a list to the ALTO server and ask 
> such a list to be ordered according to some policy.  Of 
> course the same list would be ordered differently if the 
> purpose is streaming media, file sharing, replication or others.
> 
> Is an ALTO 'server' a 'source of topology information'? 
> Topology information related to peers/clients 
> holding/providing content/resources or something else?
> 
> Thanks,
> 
> Reinaldo
> 
> 
> >> sources are within ALTO scope - decision on the actual 
> mechanism will 
> >> be discussed in the course of the working group.
> >> 
> > According to me, this reflects pretty well the interest 
> expressed by 
> > the group.
>

---

From: Laird Popkin <[email-masked]>
Date: Thu, 10 Jul 2008 11:29:55 -0400 (EDT)

A few comments below.

----- Original Message -----
From: "Reinaldo Penno" <[email-masked]>
To: "Enrico Marocco" <[email-masked]>, "PAPADIMITRIOU Dimitri" <[email-masked]>
Cc: [email-masked], "Saverio Niccolini" <[email-masked]>
Sent: Thursday, July 10, 2008 11:06:06 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO BoF - generalize the problem

LP: The ALTO query could also come from a 'server' as well as a 'peer' in the p2p network. Also, the list provided by the ALTO client is of what I'd suggest we call network locations, not peers. For example, they could be a list of IP prefixes or ASNs. This is an important distinction, in order to preserve the privacy of the p2p network's users.

LP: I would say that there are two layers of communication that ALTO needs to address. One layer is between the ALTO client (e.g. p2p app, p2p server) and the ALTO server, and the second is between the ALTO server and the source of network topology information (e.g. ISP, third-party).

Thanks,

Reinaldo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 10 Jul 2008 10:31:23 -0500

Reinaldo Penno wrote:
> Is an ALTO 'server' a 'source of topology information'? Topology
> information related to peers/clients holding/providing
> content/resources or something else?

Reinaldo: Insofar as the benefits of having an ALTO server be the
source of topology information instead of each peer trying to
figure this out, please see the discussion in the ALTO survey
paper in Section 3
(http://tools.ietf.org/html/draft-hilt-alto-survey-00#section-3).

Now, regarding what type of information the ALTO server will
maintain and to what extent will it be cognizant of the specific
application protocol of the peer (BitTorrent and its content-
hashes, P2PSIP's need to find the nearest relay, etc.) -- I don't
know that we have a concrete answer on these yet at this stage
of the game.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 10 Jul 2008 12:53:48 -0700

Thanks for the answer. I still need to catch up.

A few comments inline.

> (http://tools.ietf.org/html/draft-hilt-alto-survey-00#section-3).

Thanks for the pointer, I believe I was alluding to something else. I was
trying to point out as a problem statement for ALTO that given a set of
metrics for peers or network locations provided by the 'server', who should
order the list? Will the list be ordered by the ALTO 'server' and the client
consumes it as it sees fit.

And/Or the ALTO server provides the metrics and the client decides how to
use/interpret the metrics?

It is worth mentioning that in this example the client is not really doing
any measurements, it is a matter of how information is consumed by client
and provided by the server.

So, even if we assume the server would provide the info, we still reach a
decision point of two (or more) possibilities.

Thanks,

Reinaldo

---

From: stefano previdi <[email-masked]>
Date: Thu, 10 Jul 2008 22:02:02 +0200

> From: Reinaldo Penno <[email-masked]>
> 

couldn't this be an optional argument of the request ?

I know an implementation that gives both types of information:
    - metric
    - ranking

and then the consumer of the service decides on its own.

> and provided by the server.

yes.

> decision point of two (or more) possibilities.

indeed... we have more possibilities...

s.

---

From: Salman Abdul Baset <[email-masked]>
Date: Fri, 11 Jul 2008 03:21:45 -0400 (EDT)

> According to me, this reflects pretty well the interest expressed by the

For (1), "the request/response protocol can be used to query sources of 
topology and 'network' information". The 'network' is important because a 
machine connected to a ethernet switch/hub which in turn is connected to a 
DSL/cable modem cannot determine the access link speed in a 
straightforward way. This information is helpful when selecting a relay 
node for VoIP/video, for example.

-s

---

From: Lars Eggert <[email-masked]>
Date: Fri, 11 Jul 2008 17:51:43 +0300

Hi,

On 2008-7-11, at 10:21, ext Salman Abdul Baset wrote:
> The 'network' is important because a machine connected to a ethernet  
> switch/hub which in turn is connected to a DSL/cable modem cannot  
> determine the access link speed in a straightforward way. This  
> information is helpful when selecting a relay node for VoIP/video,  
> for example.

well, "helpful" is a concept I can't strongly argue with, but please  
note that the nominal capacity of a node's access link does not tell  
you anything about the currently available bandwidth, loss rates,  
delay, or jitter of the end-to-end path. It's not even clear that the  
access link is always the bottleneck for a given path.

Lars

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 11 Jul 2008 08:05:12 -0700

Hello,

The latter does not seem to be part of the charter at this point. It
certainly needs to be part of any working solution but I'm not sure if it
can be easily standardized.

Thanks,

Reinaldo

On 7/10/08 8:29 AM, "Laird Popkin" <[email-masked]> wrote:

> LP: I would say that there are two layers of communication that ALTO needs to
> address. One layer is between the ALTO client (e.g. p2p app, p2p server) and
> the ALTO server, and the second is between the ALTO server and the source of
> network topology information (e.g. ISP, third-party).

---

From: stefano previdi <[email-masked]>
Date: Fri, 11 Jul 2008 17:17:45 +0200

> can be easily standardized.

I tend to agree. 

We could also note that, among the different mechanisms through which an
ALTO server acquires topology information, we have some that are already
standardized for a long time now.

s.

---

From: Laird Popkin <[email-masked]>
Date: Fri, 11 Jul 2008 11:21:10 -0400 (EDT)

Whether ALTO covers one or both depends on the contents of the ALTO messages, which is intentionally quite abstract at the moment. This is intentional, so that ALTO can be used to express a wide range of possible p2p optimization strategies.

To express what P4P does in ALTO, for example, I could imagine that the P4P iTracker is an ALTO client to the ISP's ALTO server, and is an ALTO server to the P2P network's ALTO client, with different levels of information flowing through each ALTO client/server communication. That is, I believe, within the scope of what we expressed in the ALTO requirments.

----- Original Message -----
From: "Reinaldo Penno" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: [email-masked], "Saverio Niccolini" <[email-masked]>, "Enrico Marocco" <[email-masked]>, "PAPADIMITRIOU Dimitri" <[email-masked]>
Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO BoF - generalize the problem

Hello,

Thanks,

Reinaldo

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Fri, 11 Jul 2008 11:32:07 -0400

Hi, all:

Can I propose to change the name of the BoF/WG as "ALTE" where E=Engineering?

The term "optimization" indicates a given one specific thing and does not keep the room for doing something at a broader level. For example, we are doing QOS and performance engineering at the application level and developing protocols that my or may not provide anything "absolute" optimization other than some best estimates for certain circumstances.

Best regards,
Radhika

----- Original Message -----
From: Laird Popkin 
Date: Friday, July 11, 2008 11:23
Subject: Re: [p2pi] ALTO BoF - generalize the problem
To: Reinaldo Penno 
Cc: PAPADIMITRIOU Dimitri , [email-masked], Saverio Niccolini 

> Whether ALTO covers one or both depends on the contents of the 
> ALTO messages, which is intentionally quite abstract at the 
> moment. This is intentional, so that ALTO can be used to express a 
> wide range of possible p2p optimization strategies.
> 
> To express what P4P does in ALTO, for example, I could imagine 
> that the P4P iTracker is an ALTO client to the ISP's ALTO server, 
> and is an ALTO server to the P2P network's ALTO client, with 
> different levels of information flowing through each ALTO 
> client/server communication. That is, I believe, within the scope 
> of what we expressed in the ALTO requirments.
> 
> From: "Reinaldo Penno" 
> To: "Laird Popkin" 
> Cc: [email-masked], "Saverio Niccolini" 
> , "Enrico Marocco" 
> , "PAPADIMITRIOU Dimitri" 
> 
> On 7/10/08 8:29 AM, "Laird Popkin" wrote:
>

---

From: stefano previdi <[email-masked]>
Date: Fri, 11 Jul 2008 21:14:30 +0200

> From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
> 
> Hi, all:
> 

"Traffic Engineering" is a terms that has been highly/heavily used (and
abused) in the routing layer and using it in this context will resurrect a
lot of interpretations of the "TE" words that I warmly recommend to avoid.

Also, there are substantial differences between techniques that:
- engineer the traffic by controlling the path such traffic is going to take
- use topology information in order to determine the best selection of a
  given resource.

Thanks.

s.

> The term "optimization" indicates a given one specific thing and does not keep
> the room for doing something at a broader level. For example, we are doing QOS
> and performance engineering at the application level and developing protocols
> that my or may not provide anything "absolute" optimization other than some
> best estimates for certain circumstances.
> 
> Best regards,
> Radhika
>

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Fri, 11 Jul 2008 15:25:20 -0400

The bottom line is this: We are NOT standardizing the "optimization" algorithms per se. We are developing "protocol" schemes that have the ability for some kind of better topology/routing scheme at the application layer.

So, "O" or "TE" is not the right one, we have to find something else that resonates the actual "goals" of the BoF/WG.

How about ALTOP where P=protocol or something along this line?

RRR

----- Original Message -----
From: stefano previdi 
Date: Friday, July 11, 2008 15:15
Subject: Re: [p2pi] ALTO BoF - generalize the problem
To: "Roy, Radhika R Dr CTR USA USAMC" , Laird Popkin 
Cc: [email-masked], PAPADIMITRIOU Dimitri , [email-masked], Niccolini 

> > From: "Roy, Radhika R Dr CTR USA USAMC" 
> > 
> > Hi, all:
> > 
> "Traffic Engineering" is a terms that has been highly/heavily used 
> (andabused) in the routing layer and using it in this context will 
> resurrect a

---

From: Bruce Davie <[email-masked]>
Date: Fri, 11 Jul 2008 17:05:46 -0400

How about we focus on the charter and worry about the name of the WG  
when and if the WG goes ahead.

Sometimes we have to accept that the name of the WG alone will not  
tell you everything you need to know about the WG's activities. It is  
often necessary to read the WG documents as well.

Bruce

On Jul 11, 2008, at 3:25 PM, Roy, Radhika R Dr CTR USA USAMC wrote:

> The bottom line is this: We are NOT standardizing the  
> "optimization" algorithms per se. We are developing "protocol"  
> schemes that have the ability for some kind of better topology/ 
> routing scheme at the application layer.
>
> So, "O" or "TE" is not the right one, we have to find something  
> else that resonates the actual "goals" of the BoF/WG.
>

---

From: Stanislav Shalunov <[email-masked]>
Date: Fri, 11 Jul 2008 16:47:46 -0700

Or we might even not worry about the name of the possible WG at all  
and just worry about the charter and the quality of the documents the  
WG produces.

After all, when the WG completes, the name is gone, but the documents  
remain.

On Jul 11, 2008, at 2:05 PM, Bruce Davie wrote:

> tell you everything you need to know about the WG's activities. It  
> is often necessary to read the WG documents as well.
>
> Bruce
>

-- 
Stanislav Shalunov
http://shlang.com

---

From: Salman Abdul Baset <[email-masked]>
Date: Sat, 12 Jul 2008 07:35:07 -0400 (EDT)

On Fri, 11 Jul 2008, Lars Eggert wrote:

>> switch/hub which in turn is connected to a DSL/cable modem cannot determine 
>> the access link speed in a straightforward way. This information is helpful 
>> when selecting a relay node for VoIP/video, for example.
>
> well, "helpful" is a concept I can't strongly argue with, but please note 
> that the nominal capacity of a node's access link does not tell you anything 
> about the currently available bandwidth, loss rates, delay, or jitter of the 
> end-to-end path. It's not even clear that the access link is always the 
> bottleneck for a given path.
>

I agree with what you said. As you noted, if access link is not the 
bottleneck, it is useless to determine the capacity of the access link.

I am thinking of scenarios where access maybe the bottleneck. In a P2PSIP 
network, machines with a dialup or low bit-rate DSL will like to know 
their connection type and perhaps access speed so that they never 
advertise themselves as candidates for VoIP or video relays in the 
overlay.

-s

---

From: Lars Eggert <[email-masked]>
Date: Sun, 13 Jul 2008 11:37:00 +0300

Hi,

On 2008-7-12, at 14:35, ext Salman Abdul Baset wrote:
>>> The 'network' is important because a machine connected to a  
>>> ethernet switch/hub which in turn is connected to a DSL/cable  
>>> modem cannot determine the access link speed in a straightforward  
>>> way. This information is helpful when selecting a relay node for  
>>> VoIP/video, for example.
>>
>> well, "helpful" is a concept I can't strongly argue with, but  
>> please note that the nominal capacity of a node's access link does  
>> not tell you anything about the currently available bandwidth, loss  
>> rates, delay, or jitter of the end-to-end path. It's not even clear  
>> that the access link is always the bottleneck for a given path.
>

OK, glad we're in agreement.

> I am thinking of scenarios where access maybe the bottleneck. In a  
> P2PSIP network, machines with a dialup or low bit-rate DSL will like  
> to know their connection type and perhaps access speed so that they  
> never advertise themselves as candidates for VoIP or video relays in  
> the overlay.

Now I'm confused. Above you agreed that it's useless to determine this  
information, but here you want to use it to determine whether a node  
is a relay.

An app knows what type of performance it gets over a path when it uses  
it. Why isn't that sufficient to figure out if there is enough  
capacity to act as a relay? Or to turn this around: Even when the  
access link happens to be the path bottleneck and its type indicates  
to the app that it should have enough capacity so it can relay,  
depending on who else you share that link with and what they are doing  
at the time may well mean there isn't sufficient transient capacity  
available.

Lars

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 14 Jul 2008 03:13:42 -0400 (EDT)

On Sun, 13 Jul 2008, Lars Eggert wrote:

>> network, machines with a dialup or low bit-rate DSL will like to know their 
>> connection type and perhaps access speed so that they never advertise 
>> themselves as candidates for VoIP or video relays in the overlay.
>
> information, but here you want to use it to determine whether a node is a 
> relay.
>
> An app knows what type of performance it gets over a path when it uses it. 
> Why isn't that sufficient to figure out if there is enough capacity to act as 
> a relay? Or to turn this around: Even when the access link happens to be the 
> path bottleneck and its type indicates to the app that it should have enough 
> capacity so it can relay,

Obviously, measuring the path capacity or using the path is required when 
the connection type indicates to the app that it should have enough 
capacity.

When the connection type indicates to the app that it does not have enough 
capacity say for relaying a VoIP or video call, the application does not 
need to measure anything. It knows that it cannot do the requested work 
and will never advertise its relay service thereby avoiding the 
measurement of transient available capacity.

depending on who else you share that link with and 
> what they are doing at the time may well mean there isn't sufficient 
> transient capacity available.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 14 Jul 2008 10:22:46 +0300

On 2008-7-14, at 10:13, ext Salman Abdul Baset wrote:
> Obviously, measuring the path capacity or using the path is required  
> when the connection type indicates to the app that it should have  
> enough capacity.
>
> When the connection type indicates to the app that it does not have  
> enough capacity say for relaying a VoIP or video call, the  
> application does not need to measure anything. It knows that it  
> cannot do the requested work and will never advertise its relay  
> service thereby avoiding the measurement of transient available  
> capacity.

OK, so be conservative and default to off, i.e., only offer to relay  
after your network usage has left you convinced that you have capacity  
to be a relay. This should even have some benefits to the peers,  
because only nodes that have been around for a bit will become relays.

Getting this information from an oracle doesn't save you any work,  
because even if your nominal uplink capacity could let you be a relay,  
you still need to figure out if the current load on it actually lets  
you. Plus, there are obviously uplink types with no stable capacity  
(3G, WiMax, etc.) where this won't work anyway.

Lars

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Mon, 14 Jul 2008 08:48:11 -0400

I tend to agree for working on charter.

In BoF, the name itself is a big test all by itself. I want that BoF to succeed without being mis-understood by the first attendees.

BR/Radhika

----- Original Message -----
From: Bruce Davie 
Date: Friday, July 11, 2008 17:06
Subject: Re: [p2pi] ALTO BoF - generalize the problem
To: "Roy, Radhika R Dr CTR USA USAMC" 
Cc: stefano previdi , PAPADIMITRIOU Dimitri , [email-masked], [email-masked], Niccolini 

> is 
> > Cc: [email-masked], PAPADIMITRIOU Dimitri , 
> [email-masked], 
> > Niccolini
> >
> >>>> Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) 
> America/New_York>>>> Subject: Re: [p2pi] ALTO BoF - generalize the 
> problem>>>>
> >>>> Hello,
> >>>>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 14 Jul 2008 15:49:43 -0400

Laird - It may be helpful to post what you think the precise mapping of
P4P concepts into the ALTO terms will be.  That should help guide some
of the P4Pers and folks doing P4P tests right now. 

Jason 

> Behalf Of Laird Popkin
> Sent: Friday, July 11, 2008 11:21 AM
> To: Reinaldo Penno
> Cc: PAPADIMITRIOU Dimitri; [email-masked]; Saverio Niccolini
> Whether ALTO covers one or both depends on the contents of 
> the ALTO messages, which is intentionally quite abstract at 
> the moment. This is intentional, so that ALTO can be used to 
> express a wide range of possible p2p optimization strategies.
> 
> To express what P4P does in ALTO, for example, I could 
> imagine that the P4P iTracker is an ALTO client to the ISP's 
> ALTO server, and is an ALTO server to the P2P network's ALTO 
> client, with different levels of information flowing through 
> each ALTO client/server communication. That is, I believe, 
> within the scope of what we expressed in the ALTO requirments.
> 
> <[email-masked]>, "Enrico Marocco" 
> <[email-masked]>, "PAPADIMITRIOU Dimitri" 
> <[email-masked]>
> The latter does not seem to be part of the charter at this 
> point. It certainly needs to be part of any working solution 
> but I'm not sure if it can be easily standardized.
> 
> Thanks,
> 
> Reinaldo
> 
> > LP: I would say that there are two layers of communication 
> that ALTO 
> > needs to address. One layer is between the ALTO client 
> (e.g. p2p app, 
> > p2p server) and the ALTO server, and the second is between the ALTO 
> > server and the source of network topology information (e.g. 
> ISP, third-party).
> 
>