Subject: [p2pi] Information in an ALTO protocol

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

As some people suggested, it may be useful to try to understand what
kind of information will be provided by an ALTO service.

Current version of the charter lists four pieces of information:
+ routing preferences and priority values. The network operator is
  usually the only entity in possession of such information, but it is
  in its interests to share at least part of it with applications, in
  order to reduce traffic on critical links. On the other hand, if
  following such preferences leads to better-than-random choices, it is
  also in applications' interest to follow them;
+ AS numbers and approximate geographic locations. Such information is
  today (partially) available and, in fact, is in some cases already
  used for peer selection. However, since there is no standard way to
  obtain it, it is not easy for applications to switch from an
  information provider to another.

The charter does not preclude any other kind of information entirely,
but it sets the bar pretty high, requiring that:

  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?

Thoughts?

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

---

From: Stanislav Shalunov <[email-masked]>
Date: Thu, 7 Aug 2008 21:24:13 -0700

For what it's worth, I think this is the right kind of information to  
convey.

--
Stanislav Shalunov

---

From: Vinay Aggarwal <[email-masked]>
Date: Mon, 11 Aug 2008 16:35:31 +0200

Hello,

Regarding what information the ALTO service can provide:

I think an estimate of "last-hop bandwidth" can be an interesting metric
of information for peer selection.
It has been shown that selecting peers with high last-hop bandwidth lead
to improvements in download performance. And this is information that is
rather hard for peers to find out themselves. As far as I can see, it
also satisfies all the bars set up by the ALTO service.

Any thoughts?

Thanks,
Vinay.

-----------------
Vinay Aggarwal
Deutsche Telekom
Germany.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 11 Aug 2008 18:00:47 +0300

Hi,

> also satisfies all the bars set up by the ALTO service.

Uplink or downlink bandwidth?

Provisioned bandwidth (i.e., the nominal bandwidth a user is paying  
for) or the currently available fraction of it? The latter would be  
something that I doubt an ALTO box can have an accurate view of, since  
it changes on short timescales.

Could you share a reference to papers that show that that information  
is beneficial?

Thanks,
Lars

---

From: Laird Popkin <[email-masked]>
Date: Mon, 11 Aug 2008 11:11:20 -0400 (EDT)

There would certainly be value in differentiating between classes of users in terms of their nominal uplink capacity. For example, an ISP with a mix of DSL and FTTH customers would probably prefer that p2p data download from FTTH rather than DSL sources.

I agree that ALTO shouldn't try to know real-time consumption rates vs. capacity. That's (IMO) a question to ask something local to the user, not from a centralized service.

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

----- Original Message -----
From: "Lars Eggert" <[email-masked]>
To: "ext Vinay Aggarwal" <[email-masked]>
Cc: [email-masked]
Sent: Monday, August 11, 2008 11:00:47 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] Information in an ALTO protocol

Hi,

Thanks,
Lars

---

From: [email-masked]
Date: Mon, 11 Aug 2008 23:37:18 +0800

I think Vinay may mean the last-hop upload bandwidth for the local peer to
select among candidates.
The we can imagine two phases.
At first phase ALTO may prefer to response with remote peers with larger
nominal last-hop cap.
Secondly, it leaves to the local peer to probe for the real available
bandwidth among them and take the best scheduling for piece retrieval.
Maybe it will drop some peers with low consumption upload bandwidth.

On Mon, Aug 11, 2008 at 11:00 PM, Lars Eggert <[email-masked]> wrote:

> Provisioned bandwidth (i.e., the nominal bandwidth a user is paying for) or
> the currently available fraction of it? The latter would be something that I
> doubt an ALTO box can have an accurate view of, since it changes on short
> timescales.
>
> Could you share a reference to papers that show that that information is
> beneficial?
>
> Thanks,
> Lars
>

---

From: Vinay Aggarwal <[email-masked]>
Date: Mon, 11 Aug 2008 18:54:43 +0200

Hi,

regarding bandwidth information,
here is a paper that shows that taking last-hop bandwidth into account
helps to improve the download performance of peers. In fact, bandwidth
comes out to be the significant factor to improve download times.

Vinay Aggarwal, Obi Akonjang, Anja Feldmann. Improving User and ISP
Experience through ISP-aided P2P Locality. In Proceedings of 11th IEEE
Global Internet Symposium 2008 (GI'08)

The paper (and other related papers) are available at:
http://www.net.t-labs.tu-berlin.de/research/isp-p2p/

It would make sense to provide information about the "uplink" bandwidth,
as that is much smaller than "downlink" bandwidth, atleast in case of DSL,
and is thus a limiting factor.

The ALTO can consider the uplink bandwidth of peers, and use it in
combination with geographic or parent AS information to sort the peers.

I agree that some ISPs prefer to keep traffic within their network,
while other ISPs would sometimes welcome traffic going to other ISPs.
This is especially true for large ISPs, who get paid for traffic flowing
to other networks, typically their customers. 

Depending on the circumstances, an ISP can prefer peers either with
large uplink or those within its network, or better still, both!
Important is that the user should experience improved performance. 

IMHO, considering just the actual uplink bandwidth will help a great
deal. While estimating the currently "available" bandwidth would be
still better, that is a lot harder to achieve. But if that is reasonably
possible to do for the ALTO server, that is a much better alternative
than having the peer probing for the real available bandwidth and
picking the best one.

Vinay.

---

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

This might be workable and interesting, but here are a few concerns:

1. For this to be useful, an ISP would need to provide an unobfuscated  
third-party service that will tell the world what service plan I  
bought.  As a user, I'd have a bit of discomfort with it, but the ISP  
would probably be a lot more concerned about telling its competitors  
the fraction of its customers whom they upsold on a premium plan.  I  
suspect this might be a real show-stopper.

2. Nominal provisioned bandwidth on DSL is only an upper bound for the  
actual negotiated bandwidth.  The negotiation takes a few seconds  
after the modem starts and routinely results in lower-than-nominal  
rates for longer distances to CO.

3. While it's obvious that an individual peer will, in the current  
world, do better trading with fat-uplink partners, I'm skeptical of  
possibility of substantial increases in swarm throughput, which  
determines the average outcome.  Consider the measure of swarm  
efficiency: total transfer rate divided by total upload capacity.  I  
posit that swarm efficiency is usually quite high, and the only real  
slack is on super-fast peers in colos and such.  Home connection  
uplinks are so narrow that it does not take much to saturate them.

-- Stas

--
Stanislav Shalunov

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 14 Aug 2008 16:59:14 +0200

Hi,

"total transfer rate divided by total upload capacity" is a good measure
of swarm efficiency if the application is file sharing. 

p2p live video streaming (an application which might gain much relevance
till the time when a potential ALTO workgroup would deliver their first
specifications) has differenent metrics: the system can only be stable
if the video stream's bitrate is lower than the average upload capacity,
i.e., not all uplinks will be saturated by this application.

The interesting metric is the lag, i.e., the delay of the video stream
between injection into the swarm and playout (measured individually per
node or as average in the swarm). It can be reduced if nodes with higher
upload capacity or shorter transport delay from the source are placed
closer to the source in the logical topology. The incentive for a user
to offer more upload capacity to the swarm is to get a smaller
individual lag. 

While p2p algorithms can converge to a "good" state, ALTO guidance would
be very beneficial if it could speed up that process. This is very
relevant here as many users switch TV channels (streams) frequently.

Any thoughts?

Thanks,
Sebastian

On Mon, Aug 11, 2008 at 06:16:44PM -0700, Stanislav Shalunov wrote:
> third-party service that will tell the world what service plan I bought.  
> As a user, I'd have a bit of discomfort with it, but the ISP would probably 
> be a lot more concerned about telling its competitors the fraction of its 
> customers whom they upsold on a premium plan.  I suspect this might be a 
> real show-stopper.
>
> actual negotiated bandwidth.  The negotiation takes a few seconds after the 
> modem starts and routinely results in lower-than-nominal rates for longer 
> distances to CO.
>
> 3. While it's obvious that an individual peer will, in the current world, 
> do better trading with fat-uplink partners, I'm skeptical of possibility of 
> substantial increases in swarm throughput, which determines the average 
> outcome.  Consider the measure of swarm efficiency: total transfer rate 
> divided by total upload capacity.  I posit that swarm efficiency is usually 
> quite high, and the only real slack is on super-fast peers in colos and 
> such.  Home connection uplinks are so narrow that it does not take much to 
> saturate them.
>
> -- Stas

-- 
Sebastian Kiesel            mailto:[email-masked]
Network Research Division   tel:+49-6221-4342-232   fax:+49-6221-4342-155
NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 Heidelberg, Germany
--
NEC Europe Limited          Registered in England 2832014
Registered Office           NEC House, 1 Victoria Road, London W3 6BL
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 17 Aug 2008 21:31:32 -0700

Live P2P video streaming is an interesting research problem, so far  
not solved.  The business case has also not been proven, with  
different companies targeting very different uses, from UGC to TV  
distribution to screencasting.

Improving the efficiency of an application that does not yet exist  
should probably not be in scope for ALTO.

As a side note, I don't think the metric of lag is particularly  
interesting to optimize, and, therefore, I'll be happy to have our  
competitors use it.  The two right metrics are in different units.   
But let's not go too far down the path of discussing an interesting  
research topic.

-- Stas

On Aug 14, 2008, at 7:59 AM, Sebastian Kiesel wrote:

>> bought.
>> after the
>> world,

--
Stanislav Shalunov

---

From: Fabio Hecht <[email-masked]>
Date: Mon, 18 Aug 2008 16:49:29 +0200

Hello,

in this case, would an ALTO Server query other ALTO Servers to gather
this information? Because, from an ISP point of view, the ALTO Server
would not know what the last-hop bandwidth is for every other peer.
Would the protocol then be the same used by the overlay applications?

Regards

Fabio

-- 
Fabio Hecht

University of Zurich - Department of Informatics (IfI)
Binzmühlestrasse 14 CH-8050 Zürich, Switzerland
Ph.: +41 44 6357129 / 6350892  Fax: +41 44 6356809
VoIP sip:[email-masked]

---

From: Song Haibin <[email-masked]>
Date: Tue, 19 Aug 2008 11:14:02 +0800

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fabio
>Hecht
>Sent: Monday, August 18, 2008 10:49 PM
>To: Vinay Aggarwal
>
>Hello,
>

I don't think we need the queries between ALTO servers. The overlay
application can have some way to determine which ALTO server it will query,
and then gather all this swarm peers' information needed including last-hop
bandwidth information.

BR,
Song Haibin

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Aug 2008 09:17:19 -0500

> Would the protocol then be the same used by the overlay applications?

Fabio: At this point, not much thought has been given to an Inter-ALTO
server protocol or what its form may be.  We are trying to get our
hands around the needed information that could serve as the building
block for an ALTO server - ALTO client protocol.

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: David R Oran <[email-masked]>
Date: Mon, 25 Aug 2008 15:25:33 -0400

> block for an ALTO server - ALTO client protocol.
This is only tangentially related to the main topic of this thread,  
but since it occurred to me on reading this exchange about server  
chaining I thought I'd mention it here:

Many client/server protocols are were initially designed to be  
strictly two party, with no architectural support for proxies or other  
stateful intermediaries (HTTP and RTSP come to mind...there are likely  
many others).

It may behoove us to build proxy capability into ALTO from day 1,  
since it will almost inevitably have to be added later at some level  
of pain, perhaps large, and almost assuredly some undesirable security  
tradeoffs.

This probably involves at least the following:
- separating our end-to-end from ho--by hop (transport layer?) security
- clear data model separation between things used to "route" requests  
and things used to interpret queries.
- a flexible addressing model
- a way to aggregate and summarize in responses

and likely a bunch of other considerations I'm missing in the above.

DaveO.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Aug 2008 16:01:38 -0500

I strongly agree with Dave. I might suggest a couple of additions:

- the hop-by-hop and end-to-end distinction is important for a lot of other 
stuff besides security, in addition to security, and

- ("snork!") I'm not sure whether a NAT traversal story (which could be "use 
ICE, stupid") would be appropriate, but best to consider that up front as 
well.

Thanks,

Spencer

From: "David R Oran" <[email-masked]>

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 27 Aug 2008 09:51:00 -0700

> of pain, perhaps large, and almost assuredly some undesirable security

You're making the assumption now, that ALTO will need to add proxies  
or intermediaries ("will almost inevitability").  I don't really have  
evidence that you're wrong about that, but I also don't see the use  
cases right now.  Do you have anything specific in mind?

> - a way to aggregate and summarize in responses

These are good architectural principles to remember while writing and  
reviewing drafts, assuming they can be followed without falling into  
the trap of designing the be-all and end-all system.

-- Lisa

---

From: David R Oran <[email-masked]>
Date: Wed, 27 Aug 2008 12:58:09 -0400

On Aug 27, 2008, at 12:51 PM, Lisa Dusseault wrote:

> or intermediaries ("will almost inevitability").  I don't really  
> have evidence that you're wrong about that, but I also don't see the  
> use cases right now.  Do you have anything specific in mind?
>
Yeah:
1. my ISP runs a redirector to their "transparent" ALTO server so I  
can't get directly to the one I want to get to.
2. My P2P "community" wants to cache and do lookaside stuff to provide  
more globally optimized swarm spreading. So, I use their Alto "proxy"  
and let them help decide who needs to be asked for what.

> These are good architectural principles to remember while writing  
> and reviewing drafts, assuming they can be followed without falling  
> into the trap of designing the be-all and end-all system.
>
> -- Lisa
>
>>
>>

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 27 Aug 2008 10:18:51 -0700

On Aug 27, 2008, at 9:58 AM, David R Oran wrote:
>> You're making the assumption now, that ALTO will need to add  
>> proxies or intermediaries ("will almost inevitability").  I don't  
>> really have evidence that you're wrong about that, but I also don't  
>> see the use cases right now.  Do you have anything specific in mind?
>>

This helps, and leads to more questions...

> can't get directly to the one I want to get to.

How does this use case affect protocol design in the short term?   
Other than the agreed principles of good design, I mean.  An ISP can  
run any kind of internal protocol and we're a long way away from  
generalized interoperability between agents deployed within an ISP.

>
> 2. My P2P "community" wants to cache and do lookaside stuff to  
> provide more globally optimized swarm spreading. So, I use their  
> Alto "proxy" and let them help decide who needs to be asked for what.

This is a use case I've been talking to people about in a different  
context, and it's a difficult one.  If the swarm's Alto server can ask  
as itself for useful information, probably public information, then  
that's easy.  But if the swarm's Alto server has to ask for  
information "on behalf of" a swarm member, then we have difficult  
delegation and permission issues.  I had assumed we wouldn't want to  
tackle that in the first batch of ALTO work.

But even if the swarm's Alto server can get information from other  
places, publically or through delegation, and compile that or forward  
it, the next thing to bring into question is whether the end consumer  
of the information needs to know where the information came from  
originally.  I don't even know what lesson one can draw from HTTP but  
I'd probably be able to put up a good argument for learning that proxy  
information is mostly useless.  Most proxy and forwarding information  
that actually appears in HTTP traffic is ignored by clients, and most  
traffic does not even go through non-transparent proxies.  IOW, most  
proxying of HTTP, and all compiling of responses, happens  
transparently, and does not use the protocol headers that were  
designed for handling intermediaries.

As devil's advocate I'm now prepared for my argument to be totally  
demolished...

Lisa

---

From: David R Oran <[email-masked]>
Date: Wed, 27 Aug 2008 13:25:03 -0400

On Aug 27, 2008, at 1:18 PM, Lisa Dusseault wrote:

>>> really have evidence that you're wrong about that, but I also  
>>> don't see the use cases right now.  Do you have anything specific  
>>> in mind?
>>>
>
Like any middlebox, it's helpful if there's a clean separation between  
the things the middlebox can fool with and the things that get  
integrity protected end-to-end.

> context, and it's a difficult one.  If the swarm's Alto server can  
> ask as itself for useful information, probably public information,  
> then that's easy.  But if the swarm's Alto server has to ask for  
I agree this is difficult in general. It's just been my experience  
that adding proxy hooks to a protocol that did not envision them has  
been messy and painful. That's not to say I necessarily believe we  
will need the full generality you talk about below.

> places, publically or through delegation, and compile that or  
> forward it, the next thing to bring into question is whether the end  
> consumer of the information needs to know where the information came  
> from originally.  I don't even know what lesson one can draw from  
> HTTP but I'd probably be able to put up a good argument for learning  
> that proxy information is mostly useless.  Most proxy and forwarding  
> information that actually appears in HTTP traffic is ignored by  
> clients, and most traffic does not even go through non-transparent  
> proxies.  IOW, most proxying of HTTP, and all compiling of  
> responses, happens transparently, and does not use the protocol  
> headers that were designed for handling intermediaries.
>
Do you think this was inherent, or because it was a bolt-on?

>>> and reviewing drafts, assuming they can be followed without  
>>> falling into the trap of designing the be-all and end-all system.
>>>
>>> -- Lisa
>>>
>>>>

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 27 Aug 2008 10:19:51 -0700

I would like to also point out that we should strive to make ALTO as NAT
friendly as possible.

Thanks,

Reinaldo

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 27 Aug 2008 10:37:22 -0700

On Aug 27, 2008, at 10:25 AM, David R Oran wrote:

>>> 1. my ISP runs a redirector to their "transparent" ALTO server so  
>>> I can't get directly to the one I want to get to.
>>
>> Other than the agreed principles of good design, I mean.  An ISP  
>> can run any kind of internal protocol and we're a long way away  
>> from generalized interoperability between agents deployed within an  
>> ISP.
>>
> Like any middlebox, it's helpful if there's a clean separation  
> between the things the middlebox can fool with and the things that  
> get integrity protected end-to-end.
>
>>>
>> delegation and permission issues.  I had assumed we wouldn't want  
>> to tackle that in the first batch of ALTO work.

I agree we agree... :)  I guess we'll see how this plays out in  
protocol design, and it will be at least amusing and perhaps useful to  
do an exercise imagining how an ALTO base protocol can or should be  
extended before it's baked.

>> forward it, the next thing to bring into question is whether the  
>> end consumer of the information needs to know where the information  
>> came from originally.  I don't even know what lesson one can draw  
>> from HTTP but I'd probably be able to put up a good argument for  
>> learning that proxy information is mostly useless.  Most proxy and  
>> forwarding information that actually appears in HTTP traffic is  
>> ignored by clients, and most traffic does not even go through non- 
>> transparent proxies.  IOW, most proxying of HTTP, and all compiling  
>> of responses, happens transparently, and does not use the protocol  

This I do not know.  I have a gut feeling it's inherent.  Perhaps meta- 
information isn't as useful as we programmers usually think it is?   
There's definitely a pattern across protocols, whether the meta- 
information is provided initially or as a bolt-on, of that being less  
used than anticipated.  This might be random rather than a pattern --  
just a natural product of designing a bunch of stuff and being wrong  
about a random selection of features being useful.   It's too loose to  
nail down, at least for me.

Lisa