Subject: [p2pi] After-BoF charter

From: Enrico Marocco <[email-masked]>
Date: Thu, 7 Aug 2008 21:06:08 +0200

We have tried to collect all comments received during the meeting, in
mailing list and hallway discussions. The new version of the charter,
available as always at http://alto.tilab.com/docs/charter.txt, should
reflect at least some of them. Please take a look and comment. Feel free
to say if you don't like it -- entirely or partially -- and why; or if
you like it. And why.

Major changes include:
+ terminology: dropped terms like "the oracle" and "best peer";
+ scope: removed cache/TURN/whatever service discovery;
+ path selection: stressed the importance of routing preferences and
  peering policies;
+ forbidden third-party queries;
+ mentioned IRTF for analysis on more sophisticated metrics.

The current version of the charter is also more explicit about what
pieces of information will be provided by an ALTO service; I'll start a
separate thread specifically for this discussion.

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 8 Aug 2008 09:55:44 +0300

Hi,

I believe that the new charter text is a huge step in the right  
direction - thank you for not being discouraged from continuing to  
work on this after the BOF.

I have a few comments on specific bits of text:

> DRAFT CHARTER
> $Id: charter.txt 71 2008-08-07 17:15:10Z enrico $

What area are you targeting for the WG? (I assume APP.)

> A significant part of the Internet traffic is today generated by
> peer-to-peer (P2P) applications used for file sharing, real-time
> communications and live media streaming.  In contrast to client/server
> architectures, P2P applications access resources distributed across
> the Internet (e.g. files or media relays) and exchange large amounts
> of data in connections that they establish directly with nodes hosting
> such resources.
>
> One of the advantages of P2P systems comes from the fact that the
> resources they access are often made available through multiple
> instances.  Yet, applications have at best incomplete information
> about the topology of the network.  Empirical measurements of peer
> communication performance help a great deal, but this is not always an
> option nor does it always arrive at an optimal arrangement of peers in
> a reasonable time, thus causing reduced perfomormance and excessive
> cross-domain traffic.  Optimizing peer selection will improve P2P
> performance and lower ISP costs.

The first two paragraphs are a bit wordy for an IETF charter. If we  
can condense this down, good, if not, not really too problematic.

> The Working Group will design and specify an Application-Layer Traffic
> Optimization (ALTO) service that will provide applications with
> information to perform better-than-random peer selection.

Hm. There are research results (Peter Key, etc.) that show that random  
peer selection based on observed performance over time approximates an  
optimal peer selection, at least for some metrics. It seems like the  
best ALTO could do is help P2P systems converge on a good set of peers  
faster (maybe much faster) that performance-based random selection  
over time would?

>  The WG will
> consider BitTorrent, tracker-less P2P, and other applications, such as
> content delivery networks (CDN) and mirror selection.
>
> The WG will focus on the following items:

For each of these items, it's be good to indicate in the charter what  
kinds of documents (PS, Experimental, Informational, BCP) the WG is  
expected to produce.

> - A requirements document.  This document will list requirements for a
>   peer selection service, identifying, for example, what kind of
>   information P2P applications will need for optimizing their choices.
>
> - A request/response protocol for querying the ALTO service to obtain
>   information useful for peer selection, and a format for requests and
>   responses.

I'd like to suggest that at least the initial protocol should run over  
TCP.

> - A schema for such a protocol to communicate routing preferences to
>   applications, including IP ranges to prefer and avoid.

Your email also talks about AS numbers (as do charter paragraphs  
below), but the work item above is only about IP ranges and no other  
work item talks about AS numbers - missing work item?

> - In order to query an ALTO service, clients must first know one or
>   more hosts that might provide useful information.  The WG will look
>   at service discovery mechanisms that are in use or defined elsewhere
>   (e.g. based on DNS SRV records or DHCP options); in case some of
>   them could be reused, the WG will produce a document to specify how
>   they may be adopted for locating such hosts.  However, a new,
>   general-purpose service discovery mechanism is not in scope.
>
> Other tasks the WG may take on at lower priority than its initial
> deliverables are the following:

I'd like to suggest that taking on any additional work items other  
than the ones above require a WG rechartering.

> - Defining an API mapping to the request/response protocol.
>
> - Other schemas, for requesting and communicating other information
>   from the ALTO service.
>
> When the WG considers standardizing schemas, measures or other
> information that the ALTO service could provide, the following
> criteria are important to ensure real feasibility.
>
> - Can an ALTO service technically provide that information?
>
> - Is the ALTO service willing to obtain and divulge that information?
>
> - Is it information that some client will find useful?
>
> - Can that client get that information without excessive privacy
>   concerns (e.g. by sending large lists of peers)?
>
> - Is it information that clients cannot find easily some other way?
>
> After these criteria are met, the generality of the data will be
> considered for prioritizing standardization work, for example how many
> operators and how many clients are likely to be able to provide or use
> that particular data.
>
> This WG will focus solely on the interface exposed to applications
> (both P2P and client/server) by peer selection services; if, in the
> future, the IETF will consider the opportunity to work on protocols
> for actually implementing such services (e.g. application-layer
> protocols for Internet coordinate systems, routing protocol extensions
> for ISP-based solutions), such work will be done in strict
> coordination with the appropriate WGs.
>
> Protocols used for peer selection optimization will carry information
> related to the topology and the policies of the querying peer's
> network (i.e. queries on behalf of other peers are not allowed).  It
> is reasonable to expect that applications will use such protocols to
> discover Autonomous System (AS) numbers and approximate geographic
> location of peers hosting the needed resources, as well as priority
> values assigned by the ALTO service, such values having been derived
> from particular knowledge the service may be in possession of
> (e.g. location of caches and/or network peering policies), and routing
> preferences.  If the WG will happen to consider additional and more
> sophisticated schemas like, for example, some notion of network
> distance, in some network coordinate system, such effort will be
> coordinated with the proper IRTF research group.  In any case,
> solutions proposed in this WG will not deal with frequently changing
> performance-related information, for example about traffic
> congestions; instead, mechanisms addressing transport-related issues
> developed in other IETF areas will be referenced whenever appropriate.
>
> Issues related to the content exchanged in P2P systems are also
> excluded from the WG's scope, as is the issue dealing with enforcing
> the legality of the content.

Lars

---

From: John Leslie <[email-masked]>
Date: Fri, 8 Aug 2008 12:17:10 -0400

Basically, I agree with Lars... Some additional notes:

Lars Eggert <[email-masked]> wrote:
> [ext Enrico Marocco <[email-masked]> wrote:]
> 

   They're well-written, IMHO: I wouldn't worry about condensing them
yet.

> faster (maybe much faster) that performance-based random selection  

   The speed of convergence to optimal is the critical issue: we want
a "better-than-random" initial set of peers to try (and possibly an
ordered list to try if they prove unsatisfactory.

   I think adding the word "inital" would help:
" 
" information to perform better-than-random initial peer selection.

> I'd like to suggest that at least the initial protocol should run over  

   I agree. We might benefit from trying peers in the order received,
and adding as more are received.

> work item talks about AS numbers - missing work item?

   In practice, the correlation of ASN to topology is spotty. I'm
not sure that ASN will satisfy the "important criteria" to follow.

> than the ones above require a WG rechartering.

   Leaving these out may be wise.

>> - Other schemas, for requesting and communicating other information

   (Note, however, that expandability of an ALTO protocol is important.)

>> - Is it information that some client will find useful?

   Good criteria, but I'd suggest uniformity of the indefinite article:

- "an" ALTO service technically provide
- "an" ALTO service willing to obtain and divulge
- "a" client will find useful

>>   concerns (e.g. by sending large lists of peers)?

   (Clearly there are other obscuring tactics: we don't need to list
them.)

>> operators and how many clients are likely to be able to provide or use

   We should standardize what we understand now; but we shouldn't
expect every ALTO server to implement everything.

>> network (i.e. queries on behalf of other peers are not allowed).

   We should perhaps be careful about this last prohibition. I'm not
sure the obvious mechanism (matching the source IP address of a query)
is wise (though I certainly wouldn't prohibit implementations from
trying it).

   There are obvious potential benefits from letting particular
trackers read an ISP's policies (by prior arrangement, usually). A
blanket prohibition of this seems unnecessary.

>> It is reasonable to expect that applications will use such protocols
>> to discover Autonomous System (AS) numbers and approximate geographic
>> location of peers hosting the needed resources,

   I don't even _understand_ this.

   Current trackers _do_ try to find these pieces of information, but
IMHO they're suboptimal substitutes for information ISPs could provide.
I see no reason to include such text in a charter.

>> as well as priority
>> preferences.

   These are more reasonable, but they don't seem necessary in a charter
either.

>> If the WG will happen to consider additional and more
>> coordinated with the proper IRTF research group.

   Folks would prefer (IMHO) that we don't even mention such work.

>> In any case, solutions proposed in this WG will not deal with
>> frequently changing performance-related information, for example
>> about traffic congestions;

   Congestion is the whole issue here -- we'd better not rule it out of
scope.

   ISPs will cooperate in this effort if it helps their congestion
problems -- and probably won't if it doesn't.

   That said, we _should_ recognize that the p2p application is in a
better position to evaluate instantaneous congestion than any ALTO
server: thus asking the ALTO server for congestion level is unwise.

   But ISPs probably _will_ implement some variety of "penalty box"
for customers that "cause" too much congestion; and IMHO we'd be
well advised to allow for an ISP's ALTO server to report how close
a customer is to the penalty box. (This could change from second to
second, in principle.)

   I don't have any specific proposal -- it just seems unwise to rule
this information out of scope.

>> instead, mechanisms addressing transport-related issues

   This text is confusing. Does it really help anything to say this?

>> the legality of the content.

   I absolutely agree.

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

---

From: Laird Popkin <[email-masked]>
Date: Fri, 8 Aug 2008 12:43:43 -0400 (EDT)

Comment below.

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

----- Original Message -----
From: "John Leslie" <[email-masked]>
To: "Lars Eggert" <[email-masked]>
Cc: [email-masked], "Lisa Dusseault" <[email-masked]>
Sent: Friday, August 8, 2008 12:17:10 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] After-BoF charter

[laird] The distinction is (IMO) that the ALTO server makes slow-moving recommendations, while the application can be decisions based on real-time conditions. Congestion as an example is (IMO) causing a little confusion, because it's both a real-time condition (e.g. "is the TCP stream from peer A congested right now?") and an input into slow-moving recommendations (e.g. "the link to ISP X is typically heavily congested during the day, so don't connect peers across that link"). Perhaps it would be better not to provide the congestion example in the write-up?

---

From: David R Oran <[email-masked]>
Date: Fri, 8 Aug 2008 13:34:09 -0400

> problems -- and probably won't if it doesn't.
Not necessarily. If they can increase their revenue by selling a  
tiered service that optimizes P2P completion times that might be the  
hook irrespective of congestion.
It is of course desirable that ISPs cooperate and even lead the  
charge; on the other hand we need to make ALTO succeed in the absence  
of direct ISP deployment. Read: business opportunity.

> server: thus asking the ALTO server for congestion level is unwise.
Agree.

> a customer is to the penalty box. (This could change from second to
I am quite un-enthusiastic about this idea, because it's not possible  
for the P2P application (or any individual application) to tell if  
it's the one causing the creep to the penalty box or if it's the 5-way  
video conference the customer is doing, or the HD streaming video  
coming in from from some OTT video service.

I am even more unenthusiastic if the idea is that there is a specific  
penalty box for P2P applications, because that keeps us stuck in the  
DPI world with the customer and the ISP encouraged to engage in spy-vs- 
spy tactics.

Plus, this doesn't help at all with penalty boxes tied to daily/weekly/ 
monthly data volume caps.

A better way to deal with this is full-disclosure by the ISP and  
configurable rate shaping in the home router.

> this information out of scope.
I think it is wise to declare this out of scope. So, we disagree here.

> [laird] The distinction is (IMO) that the ALTO server makes slow- 
> moving recommendations, while the application can be decisions based  
> on real-time conditions.
I think the distinctions are greater and along more dimensions that  
simply the time-averaging interval. Examples: the ALTO server sees a  
different set of data than seen by the application; the privacy  
implications are different; etc.

> Congestion as an example is (IMO) causing a little confusion,  
> because it's both a real-time condition (e.g. "is the TCP stream  
> from peer A congested right now?") and an input into slow-moving  
> recommendations (e.g. "the link to ISP X is typically heavily  
> congested during the day, so don't connect peers across that link").
That isn't congestion; that's traffic engineering. It's irrelevant why  
the ISP thinks links are good or bad; it could simply be the pricing...

> Perhaps it would be better not to provide the congestion example in  
> the write-up?
>
As an example of what NOT to do it is still useful.

Cheers, DaveO.

---

From: John Leslie <[email-masked]>
Date: Fri, 8 Aug 2008 16:25:03 -0400

David R Oran <[email-masked]> wrote:
>> ["John Leslie" <[email-masked]> wrote:]

   Hmm... seems kinda speculative...

   They may well _think_ they can sell it to content suppliers; but
they haven't had many takers so far.

   And IMHO, they can't sell it to consumers unless they first implement
some kind of "penalty box".

> of direct ISP deployment. Read: business opportunity.

   With this, I entirely agree!

>> server: thus asking the ALTO server for congestion level is unwise.

   Good -- we have common ground. :^)

> coming in from from some OTT video service.

   True. But it _is_ in a position to notify the user; and it may be
in a better position than those other apps to find an alternate path.

> DPI world with the customer and the ISP encouraged to engage in spy-vs- 

   I don't worry about that so much... I think ISPs are too lazy to
implement multiple penalty boxes (and are at least a little afraid
that the FCC would slap their wrists for doing so).

> monthly data volume caps.

   Frankly, that's a lousy model for penalty boxes -- and IMHO the ISPs
will learn it doesn't solve their problem.

> configurable rate shaping in the home router.

   Agreed. (Are you holding your breath?)

>> this information out of scope.

   Please understand I mean exactly that. I'd like to be able to talk
about it: very likely it won't lead to anything at all in the first
version of an ALTO standard.

> I think it is wise to declare this out of scope. So, we disagree here.

   If you say so...

   If you mean that no extensions to an ALTO protocol should ever be
able to carry penalty-box info, then I guess we do disagree. If you
mean the first release shouldn't, I don't disagree very much...

---

From: David R Oran <[email-masked]>
Date: Fri, 8 Aug 2008 17:13:08 -0400

>> On Aug 8, 2008, at 12:43 PM, Laird Popkin wrote:
[snip]
> in a better position than those other apps to find an alternate path.
This seems a very good way to the ISP to convince users to throttle  
themselves without actually having actual capacity/congestion  
problems. I really don't see how this can work anywhere near as well  
in practice as ECN or other techniques to give congestion feedback  
that without dropping packets.

> that the FCC would slap their wrists for doing so).
I thought they'd be smart enough to not try to do DPI because of the  
inevitable arms race and the high BTU hot water generator sending TCP  
RSTs turned out to be. The whole thing started by the ISPs trying to  
differentiate applications "on behalf of" the users to "help them"  
keep their web browsing snappy in the presence of all that background  
traffic.

So, I have no idea what the ISPs might or might not do here.

> will learn it doesn't solve their problem.
Like the cellular operators did? (not).

> version of an ALTO standard.
What I'd like to rule out of scope is discussion of billing, data  
volume, or cap-related data in the ALTO schema, because it skirts the  
edge of the IETF mandate to not do billing or account control related  
work. This has served us fairly well in the VoIP arena, and has gotten  
us into trouble the times we tread too close to the line.

> mean the first release shouldn't, I don't disagree very much...
I think it should be explicitly out until the WG chairs and area  
directors decides it should be in.

My 2cents, FWIW...

DaveO.

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 09 Aug 2008 00:37:39 +0100

At 22:13 08/08/2008, David R Oran wrote:
>At 21:25 08/08/2008, John Leslie wrote:

I agree with Dave that info in how close a customer is to a penalty 
box should be out of scope of this charter completely.

Reason: It's a different service completely.

ALTO is about giving hints on initial hosts to connect to - that's a 
service about the network that could feasibly be operated by a 3rd 
party, not the ISP (perhaps gathering info from multiple ISPs and 
from p2p networks etc).

Penalty box status is about giving the status of the ISP's retail 
service itself, so it can only be operated by the ISP (or an agent of the ISP).

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 09 Aug 2008 01:40:23 +0100

Enrico,

Charter generally looks good.
Generally agree with Lars, Dave's & Laird's responses so far.
My additional 3 penny's worth:

1/ Server operator issues
-------------------------
The charter should say that there is no assumption that the 
requester's ISP operates the server.

But the requester needs to be able to access a server that will give 
info relative to the network to which she is attached.

And there may be competing ALTO servers that could serve the same requester.

So there is also a requirement that a requester should be able to 
choose the server operated by the one she prefers.

There is also a requirement that the requester can authenticate the 
operator of the server she has accessed (otherwise a spoof server 
could junk an ISPs network by giving out perverse responses).

2/ Empirical measurement wordsmithing

Current text:
>Empirical measurements of peer communication performance help a 
>great deal, but this is not always an option nor does it always 
>arrive at an optimal arrangement of peers in a reasonable time, thus 
>causing reduced perfomormance and excessive cross-domain traffic.

Proposed text:
>Empirical measurements of peer communication performance helps a 
>great deal, but this does not always arrive at an optimal 
>arrangement of peers in a reasonable time, thus causing reduced 
>performance both for the peers and other network users.

Reasoning:
- Empirical measurement is always an option.
- see next point for why I've proposed scrubbing the implication that 
only cross-traffic is bad.

3/ What does optimal mean, and what does better mean?

The charter has hidden assumptions about what optimal is, and what 
better is. From whose perspective? It needs to either say what these 
assumptions are, or say that the w-g will define what optimal means 
in a w-g document.

As I have to keep saying, and as Richard Woundy from ComCast has 
agreed, excessive cross domain traffic is much less bad than 
excessive local traffic.

I agree that the /current/ traffic arrangement resulting from p2p has 
excessive cross-domain traffic. But this is the 
not-seeing-beyond-the-first-step problem I tried to explain at the 
mic in the ALTO BoF.

Once traffic is sitting in an optimum arrangement (possibly 
bootstrapped by ALTO then optimised by e2e congestion control), the 
best place to add the /next/ connection will likely be cross-domain 
not local. Because the optimium is a /balance/ of light congestion 
across both. This is why the goal MUST NOT be unconditional 
localisation. That could eventually drive the network /beyond/ the 
balance, persistently trying to drive up congestion in the access and 
backhaul. That will be much worse than excessive cross-domain traffic.

You might say it would be nice to have that problem.

But if this service only does localisation, it will only be safe /if/ 
it is used by a minority. If the popularity of an ALTO service goes 
beyond a certain point, it will start to kill the ISP's local 
network. Of course, then less people will use it and an equilibrium 
might be reached. But that's what I said. Optimisation is a process, 
not just a first step. ALTO has to be able to move traffic out, not just in.

\
  \
   \      /\
    \    /  \ ^----- <<<---goal
     \  /    V
      \/

NOT
\
  \
   \
    \          <<<---goal
     \
      \
       \
        \
         \
          \

Bob

---

From: Bruce Davie <[email-masked]>
Date: Mon, 11 Aug 2008 09:51:48 -0400

Good points Bob, most of which I agree with. A little clarification  
below:

[snip]

> better is. From whose perspective? It needs to either say what  
> these assumptions are, or say that the w-g will define what optimal  
> means in a w-g document.

I would suggest that there will be different views of optimal for  
different providers, and the WG should work on capturing that fact  
and developing solutions that can deal with it.

> agreed, excessive cross domain traffic is much less bad than  

I believe you have just stated what is optimal for two providers, but  
I'm not convinced that the entire universe of providers agrees with  
you. I think the WG needs to deal with the fact that some providers  
will care about reducing backhaul traffic and others will care about  
reducing inter-domain traffic.

Rather than trying to get this all nailed down in the charter, I  
think it would be good if the charter mentioned the problem of  
defining optimality from a variety of perspectives as one of its work  
items.

I also note that the charter is ultimately intended only to specify  
the interface between clients and "peer selection services"  - so we  
need to make sure that the information carried across that interface  
is sufficiently rich to allow for a range of different definitions of  
optimality. We don't need to get everyone to buy into a single  
definition of optimality.

The rest of your email below finds me in complete agreement.

Bruce

>
> I agree that the /current/ traffic arrangement resulting from p2p  
> has excessive cross-domain traffic. But this is the not-seeing- 
> beyond-the-first-step problem I tried to explain at the mic in the  
> ALTO BoF.
>
> balance, persistently trying to drive up congestion in the access  
> and backhaul. That will be much worse than excessive cross-domain  
> traffic.
>
> But if this service only does localisation, it will only be safe / 
> if/ it is used by a minority. If the popularity of an ALTO service  
> goes beyond a certain point, it will start to kill the ISP's local  
> might be reached. But that's what I said. Optimisation is a  
> process, not just a first step. ALTO has to be able to move traffic  
> out, not just in.
>
> \
>  \
>   \      /\
>    \    /  \ ^----- <<<---goal
>     \  /    V
>      \/
>
> NOT
> \
>  \
>   \
>    \          <<<---goal
>     \
>      \
>       \
>        \
>         \
>          \
>
>
> Bob
>

---

From: Laird Popkin <[email-masked]>
Date: Mon, 11 Aug 2008 10:31:19 -0400

I agree. Because every ISP has their own preferences and policies, I  
don't think that it's too productive to try to come up with a specific  
definition of 'best'. Instead we should focus on creating a  
sufficiently general mechanism that it allows ISPs to express a  
reasonable range of policies, with an extension mechanism to allow  
people to cover cases that we didn't think of up front.

On the topic of "third party queries", can someone explain what the  
concern is? Third party ALTO queries seem extremely useful, and I'm  
having trouble thinking of a counter-example.

- LP

On Aug 11, 2008, at 9:51 AM, Bruce Davie wrote:

> I believe you have just stated what is optimal for two providers,  
> but I'm not convinced that the entire universe of providers agrees  
> with you. I think the WG needs to deal with the fact that some  
> providers will care about reducing backhaul traffic and others will  
> care about reducing inter-domain traffic.
>
> defining optimality from a variety of perspectives as one of its  
> work items.
>
> is sufficiently rich to allow for a range of different definitions  
> of optimality. We don't need to get everyone to buy into a single

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 11 Aug 2008 18:54:54 -0700

This is quite obvious, but I thought it might be worth stating in the  
context of this discussion:

As an ISP, you can't put up a server that answers short questions with  
short answers or publish some information for the public or your  
customers and expect the amount of upload P2P capacity used by your  
customers to drop much below the amount of download P2P capacity.   
Every downloaded bit is someone's uploaded bit.  For the swarm, the  
upload/download ratio is always 1.  You can try to encourage your  
customers to be leeches, but that doesn't work too well, because then  
their download rates go down as they are chocked or snubbed by more  
and more people.

The only way to break the 1:1 ratio is by introducing caches.

While this consideration is important to keep in mind to be realistic  
about possible outcomes of ALTO, I agree with all the posters that  
that goal of ALTO should not be unconditional localization but a more  
general mechanism for expressing network routing preferences to the  
application.

-- Stas

--
Stanislav Shalunov

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 14 Aug 2008 19:23:11 +0200

> work on this after the BOF.

Well, the interest shown at the BoF was actually encouraging, even if
having all those people (> 240, according to bluesheets) agree is kind
of a nightmare ;-)

> What area are you targeting for the WG? (I assume APP.)

The proposed WG will target APP, but probably it will need advisors from
other areas as well.

> faster (maybe much faster) that performance-based random selection

Right. The previous paragraph says that it is a time-related issue, but
probably it would be worth reaffirming it with "initial peer selection"
(as John suggested).

> kinds of documents (PS, Experimental, Informational, BCP) the WG is

Sure, we would have specified the type in "goals and milestones". The
only item we are still not sure about is the discovery mechanism, which
could be either Informational, PS or BCP, depending on what it will be
based on. Other documents would be informational (reqs) and standards
track protocols.

> I'd like to suggest that at least the initial protocol should run over

I don't think we should say that in a charter. However, we could still
say that, for example, "if, for some very good reason, the WG will
decide to define a UDP-based protocol, guidelines in
draft-ietf-tsvwg-udp-guidelines must be followed."

> work item talks about AS numbers - missing work item?

Actually it is still not perfectly clear if ASN and geolocation
information should go in the same schema (e.g. as an alternative way to
express routing preferences), or in a different schema.

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 14 Aug 2008 19:24:47 +0200

> " information to perform better-than-random initial peer selection.

Yes, that's better.

> - "a" client will find useful

Ok.

> blanket prohibition of this seems unnecessary.

That's true, but, on the other hand, allowing uncontrolled third-party
queries would be a privacy nightmare, for both users and ISPs. I've
personally had a discussion with Stanislav, who said that having peers
doing the ALTO query and passing the response back to a BitTorrent
tracker would not be too much of a hassle, so, probably, given the costs
that controlling third-party queries in a reasonable way would imply, it
could be wise to just forbid them. However, I would really like to hear
what other people think about this, especially on the P2P side.

> I see no reason to include such text in a charter.

Right, we have let them in exactly because that's the kind of
information a third-party non-ISP ALTO service provider could provide
(ip2location and "looking glass" web services already do, just in a
non-standard way). We could get rid of those pieces of information, but
that would probably reduce the suitability of ALTO for non-ISPs.

---

From: Laird Popkin <[email-masked]>
Date: Thu, 14 Aug 2008 14:07:10 -0400

>> " information to perform better-than-random initial peer selection.

I strongly agree - this clarifies the relationship between ALTO and  
P2P networks quite nicely.

> what other people think about this, especially on the P2P side.

A p2p network can query ALTO information through clients, of course.

If ALTO is used by Trackers to decide which peers to connect, then  
it's a matter of getting the right info to the Tracker.

IMO ALTO should allow the expression of an ISP policy that applies  
more broadly than a single client. For example, if a client can get  
the ALTO guidance that "for all of my customers (defined by an IP  
prefix list), please do p2p transfers with the FTTH users (defined by  
an IP prefix list) before other users.") then the p2p service can  
apply that policy to all peers without them all having to individually  
ask the ALTO server.

If ALTO were limited to telling each client what policy to apply to  
its p2p connections, then every p2p client would have to make an ALTO  
query, then pass the response back to the Tracker to analyze and  
apply. This seems like more work all around, so I hope that we don't  
restrict ALTO to this case.

> that would probably reduce the suitability of ALTO for non-ISPs.

The IP to ASN lookup services are proprietary and somewhat inaccurate.  
If ISPs can provide a standard, precise mechanism for determining  
which users are within their network,  that would probably be better.  
Of course, for other ISPs p2p networks would continue to use the  
existing mechanisms, so this isn't a matter of doing something  
impossible, but more a matter of introducing a more precise, efficient  
mechanism to do what is done now.