Subject: [alto] Comments to "draft-ietf-alto-problem-statement-01"

From: Linda Dunbar <[email-masked]>
Date: Mon, 01 Jun 2009 11:01:02 -0500

Jan and Eric, 

I have following comments to the "draft-ietf-alto-problem-statement-01:

The Figure 1 of the draft (i.e. the ALTO server providing client protocol to
peers and Resource Directory) demonstrates a solution for the problem. But
the title of the draft says that it is a Problem Statement, which should not
dictate how solution should be. There are multiple ways for network layer to
provide needed information to the application layer to optimize P2P traffic.

Just from pure technical point of view, it is difficult for the ALTO
server/client model to work well when the application peers are in different
service provider domains for the following reasons:

*        Most likely the peers are in different ISPs. The proposed ALTO
server/client model assumes that ALTO servers belong to certain ISPs. It is
not a trivial task for one ISP's ALTO server to keep track of which ISPs the
other peers belong to. 

*        There is really no incentive for one ISP to optimize traffic for
other ISPs. Why should one ISP invest effort to optimize other ISP's
traffic?

The ALTO group would allow people to explore different types of architecture
to optimize the P2P traffic. Therefore, the description of the ALTO
server/client and related protocol should not be part of this "Problem
Statement" document. 

Best Regards, Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon
Peterson
Sent: Friday, May 29, 2009 3:00 PM
To: [email-masked]
Subject: [alto] WGLC: draft-ietf-alto-problem-statement-01

The chairs would like to declare a Working Group Last Call for
draft-ietf-alto-problem-statement-01, beginning Monday June 1st and ending
Monday June 15th.

Please do review the latest version of the draft, and send any comments to
the list before the expiry of WGLC so we can get this document ready for the
IESG.

Jon Peterson   
NeuStar, Inc.

---

From: Eric Burger <[email-masked]>
Date: Tue, 2 Jun 2009 09:31:20 -0400

You are entirely correct that the goal of this document is to lay out  
the problem and not the solution.  Moreover, it is unfortunate, yet  
true, that one may interpret any pictorial representation of an  
instantiation of ALTO services as a preferred method of deploying ALTO.

I would offer that your assertion that there may be issues with cross- 
domain ALTO services is correct.  I would also offer that these issues  
are both solvable and possibly out of scope for ALTO.

However, we would offer that Figure 1 is only representative of the  
situation and, in particular, does NOT enumerate any particular or  
favored implementation strategy.  Moreover, at a very high level, this  
figure embodies the general approach taken by the work group and what  
the IESG enumerated in our charter.  At this point, our alternative is  
to remove the figure.  However, we put the figure in because a number  
of people commented in prior drafts that we needed a figure.  It is  
our opinion (as members of the work group) that this is the best we  
can do.  If one has a better figure, please submit it.  Otherwise, I  
believe we have work group consensus to go forward with the document  
as is.

On Jun 1, 2009, at 12:01 PM, Linda Dunbar wrote:

> Jan and Eric,
>
>
>
> I have following comments to the “draft-ietf-alto-problem- 
> statement-01:
>
>
>
> The Figure 1 of the draft (i.e. the ALTO server providing client  
> protocol to peers and Resource Directory) demonstrates a solution  
> for the problem. But the title of the draft says that it is a  
> Problem Statement, which should not dictate how solution should be.  
> There are multiple ways for network layer to provide needed  
> information to the application layer to optimize P2P traffic.
>
>
>
> server/client model to work well when the application peers are in  
> different service provider domains for the following reasons:
>
>
>
> ·        Most likely the peers are in different ISPs. The proposed  
> ALTO server/client model assumes that ALTO servers belong to certain  
> ISPs. It is not a trivial task for one ISP’s ALTO server to keep  
> track of which ISPs the other peers belong to.
>
> ·        There is really no incentive for one ISP to optimize  
> traffic for other ISPs. Why should one ISP invest effort to optimize  
> other ISP’s traffic?
>
>
>
> The ALTO group would allow people to explore different types of  
> architecture to optimize the P2P traffic. Therefore, the description  
> of the ALTO server/client and related protocol should not be part of  
> this “Problem Statement” document.
>
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Jon Peterson
> The chairs would like to declare a Working Group Last Call for draft- 
> ietf-alto-problem-statement-01, beginning Monday June 1st and ending  
> Monday June 15th.
>
> Please do review the latest version of the draft, and send any  
> comments to the list before the expiry of WGLC so we can get this  
> document ready for the IESG.
>
> Jon Peterson
> NeuStar, Inc.
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 02 Jun 2009 10:05:22 -0500

Eric, 

Thank you very much for the explanation. Since I haven't participated in the
ALTO discussion until recently, I am not aware that working group has
already reached consensus on the document. Seeing the document is only at
its Version 1, I thought the document is still at its early stage and open
for input. 

I will take you suggestion on trying to draw a "better picture" and submit
to the working group for review.  If no better picture can be agreed by the
working group, I would like to take your offer on putting the following
words into the document:

		Figure 1 is only representative of the situation and, in
particular, does NOT enumerate any particular or favored implementation
strategy

Thanks, Linda Dunbar

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Tuesday, June 02, 2009 8:31 AM
To: Linda Dunbar
Cc: alto
Subject: Re: Comments to "draft-ietf-alto-problem-statement-01"

On Jun 1, 2009, at 12:01 PM, Linda Dunbar wrote:

> .        Most likely the peers are in different ISPs. The proposed  
> ISPs. It is not a trivial task for one ISP's ALTO server to keep  
> .        There is really no incentive for one ISP to optimize  
> other ISP's traffic?
> this "Problem Statement" document.
>
>
>

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 2 Jun 2009 12:57:21 -0400 (EDT)

When a home customer purchases a [high speed] Internet plan from an ISP, 
the ISP typically promises a certain upload/download link capacity for the 
plan.

In the old days of dialup, a device using a modem established a 
point-to-point connection with the ISP and knew the link capacity which 
was 14.4, 33, or 56kb/s.

Increasingly, devices at home are connected to a WiFi router which in turn 
is connected to a [A]DSL/cable modem. The devices no longer have a 
point-to-point connection similar to dialup and cannot use the link 
capacity estimate for WiFi router because it is completely different than 
the link capacity between ISP and high speed modem.

A device may run different application such as peer-to-peer applications 
which need capacity estimates for voice relaying, p2p video etc.

Currently, these applications must determine the link capacity by 
performing measurements. Also, there is no way for applications to share 
the capacity information with each other.

My question is whether it is within the scope of ALTO to design a 
mechanism to pass the link capacity, that ISP promised to the customer at 
the time of the purchase of the plan, to the [A]DSL/high speed modem which 
passes it to the devices upstream?

-salman

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 2 Jun 2009 10:14:32 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Salman Abdul Baset
> Sent: Tuesday, June 02, 2009 9:57 AM
> To: alto
> Subject: [alto] 'Link capacity' in scope?
> 
> 

Well, DSL providers use dynamic spectrum management tools to adjust the bitrate/FEC on the DSL line. So, things (may) change over time. The DSL modem is aware of these provisioning changes, but all that stays in the link layer. I am not sure how you can get that from the app layer. Note that in newer DSL specs like ADSL2+, there is also seamless bitrate adaptation where the bitrate of the link will change based on the SNR.

As you indicated, people use measurement techniques to figure out the link speed, etc. 

-acbegen

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

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 2 Jun 2009 18:06:22 -0400 (EDT)

> As you indicated, people use measurement techniques to figure out the link speed, etc.

Indeed, measurement techniques can be used to determine link capacity. 
However, they must be done on a per application basis.

The congestion and SNR can impact the link speed, so the transient link 
speed will not be the same as the link speed purchased as part of the 
high speed Internet plan.

Nevertheless, applications greatly benefit when they can determine the 
link speed without measurements, especially if they are running on 
a machine which is connected to a WiFi router which in turn is 
connected to a DSL/cable modem. Passing the purchased link speed is a 
useful hint for p2p applications and for diagnostic purposes.

My question to the chairs and to the authors of problem statement draft is 
whether it is within the scope of ALTO to design a mechanism to pass the 
link capacity, that ISP promised to the customer at the time of the 
purchase of the plan, to the [A]DSL/high speed modem which passes it to 
the devices upstream?

-s

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 2 Jun 2009 20:20:49 -0400

Salman,

I don't remember if the WG ever decided whether the 'provisioned link
speed' was in scope or not.

But as an ISP, I have always been uncomfortable in sharing this data
item in an ALTO service. In North America, broadband connectivity may
cost between ~$15/month and ~$250/month, depending largely on the
provisioned speed. The subscriber's speed (especially for the higher
speed tiers) may imply the subscriber's ability to pay for that speed,
which in turn may imply the subscriber's household income.

So I worry that this information may be in conflict with this criteria
from the ALTO charter: "Can a client get that information without
excessive privacy concerns?"
http://www.ietf.org/html.charters/alto-charter.html

But that is only my opinion. Others have noted that it may make sense
for ALTO to differentiate between DSL and FTTH, perhaps without
revealing the speed tier of the subscriber (and reducing the privacy
concern).

There was a very long thread on the now-defunct p2pi mailing list on
this topic:
http://www.ietf.org/mail-archive/web/p2pi/current/msg00576.html. In
fact, I believe you made a posting then. :)

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Salman Abdul Baset
Sent: Tuesday, June 02, 2009 6:06 PM
To: Ali C. Begen (abegen)
Cc: alto
Subject: Re: [alto] 'Link capacity' in scope?

>> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Salman Abdul Baset
> Well, DSL providers use dynamic spectrum management tools to adjust
the bitrate/FEC on the DSL line. So, things (may) change over time. The
DSL modem is aware of these provisioning changes, but all that stays in
the link layer. I am not sure how you can get that from the app layer.
Note that in newer DSL specs like ADSL2+, there is also seamless bitrate
adaptation where the bitrate of the link will change based on the SNR.

My question to the chairs and to the authors of problem statement draft
is 
whether it is within the scope of ALTO to design a mechanism to pass the

-s

---

From: Eric Burger <[email-masked]>
Date: Tue, 2 Jun 2009 21:39:55 -0400

Inline.

On Jun 2, 2009, at 11:05 AM, Linda Dunbar wrote:
> Eric,
>
> Thank you very much for the explanation. Since I haven't  
> participated in the ALTO discussion until recently, I am not aware  
> that working group has already reached consensus on the document.  
> Seeing the document is only at its Version 1, I thought the document  
> is still at its early stage and open for input.
>
More important: thanks for the review!  The document went through  
quite a few revisions at the draft-marocco stage.
> I will take you suggestion on trying to draw a "better picture" and  
> submit to the working group for review.  If no better picture can be  
> agreed by the working group, I would like to take your offer on  
> putting the following words into the document:
>
>
> Figure 1 is only representative of the situation and, in particular,  
> does NOT enumerate any particular or favored implementation strategy
>
Both (either a new figure or the disclaimer text) works for me.  Any  
one else in the group have thoughts?

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 2 Jun 2009 23:02:12 -0400 (EDT)

Clearly, a third party querying an ISP for provisioned link speed 
associated with any IP address has tremendous privacy concerns.

However, what I am thinking is that an ISP managed ALTO server (at the 
edge router) disseminates this information only to a DSL/cable modem when 
the modem attempts to obtain an IP address. This mechanism may also be 
accomplished using DHCP. Such a mechanism cannot be used to bulk-get 
the link speeds by anonymous clients and thus it does not have the 
associated privacy concerns.

You are probably right that WG did not decide on this. This is precisely 
why I am asking this question before problem statement draft is finalized :)

-s

---

From: Randy Turner <[email-masked]>
Date: Tue, 2 Jun 2009 22:09:33 -0700

The ADSL2 Line MIB contains the upstream and downstream information  
that is "current" within an ADSL2+ modem. A similar table is present  
in the original ADSL line MIB as well (Full-rate DMT modems for  
example).

Devices in the home could query the MIB objects to obtain upstream and  
downstream info, but this would only work for DSL modems. I'm not sure  
if these MIBs are accessible over IP from the LAN side of the modem,  
but the existence of the MIB objects would serve as a starting point  
for providing this information to LAN-side hosts.

It's not clear to me how an application would use this information.  
Can someone present a use-case for how this information (given its'  
availability) would be used?

I don't think a P2P app would be interested in just the bandwidth to  
the "head-end" of the connection, but more interested in "end-to-end"  
bandwidth availability.  I know some apps (like the Kontiki P2P  
client) that can be configured with the uplink speed of the broadband  
connection, and they can be configured to only use a certain  
percentage of the available uplink bandwidth, but this is crude since  
it can limit its' own performance, even when no other app is running.   
The modem or residential gateway that manages the uplink itself is in  
a much better position to open or limit the bandwidth of certain  
applications, based on available uplink bandwidth.

Randy

On Jun 2, 2009, at 9:57 AM, Salman Abdul Baset wrote:

>
> When a home customer purchases a [high speed] Internet plan from an  
> ISP, the ISP typically promises a certain upload/download link  
> capacity for the plan.
>
> point-to-point connection with the ISP and knew the link capacity  
> which was 14.4, 33, or 56kb/s.
>
> Increasingly, devices at home are connected to a WiFi router which  
> in turn is connected to a [A]DSL/cable modem. The devices no longer  
> have a point-to-point connection similar to dialup and cannot use  
> the link capacity estimate for WiFi router because it is completely  
> different than the link capacity between ISP and high speed modem.
>
> A device may run different application such as peer-to-peer  
> applications which need capacity estimates for voice relaying, p2p  
> video etc.
>
> performing measurements. Also, there is no way for applications to  
> share the capacity information with each other.
>
> mechanism to pass the link capacity, that ISP promised to the  
> customer at the time of the purchase of the plan, to the [A]DSL/high  
> speed modem which passes it to the devices upstream?
>
> -salman

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 3 Jun 2009 10:13:32 +0200

On Tue, Jun 02, 2009 at 09:39:55PM -0400, Eric Burger wrote:
>> Thank you very much for the explanation. Since I haven't participated 
>> in the ALTO discussion until recently, I am not aware that working 
>> group has already reached consensus on the document. Seeing the 
>> document is only at its Version 1, I thought the document is still at 
>> its early stage and open for input.
>>
> More important: thanks for the review!  The document went through quite a 
> few revisions at the draft-marocco stage.
> Both (either a new figure or the disclaimer text) works for me.  Any one 
> else in the group have thoughts?

I think the current figure is adequate (but looking forward to see a
proposal for a better one).

regarding the caption/disclaimer: I think that although there are lots
of approaches for dealing with the ALTO problem, the figure was not
chosen randomly and coincidences with actual protocol proposals are not
completely unintentional. maybe something like:

Figure 1 illustrates the situation and components for one of several
possible high-level solution approaches for dealing with the ALTO
problem, namely the one which the ALTO WG has agreed to work on and
which is reflected in the ALTO WG charter.

(hoping that the "illustrates" gives enough hints that this figure
is not normative and does not mandate that there must be a single
ALTO server implemented as a physical box, etc.)

Thanks,
Sebastian

-- 
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

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 3 Jun 2009 11:21:31 +0200

On Tue, Jun 02, 2009 at 12:57:21PM -0400, Salman Abdul Baset wrote:
> the time of the purchase of the plan, to the [A]DSL/high speed modem 
> which passes it to the devices upstream?

Passing bandwidth information from the ISP via the modem (or other
devices in the access network) to upstream devices is IMO not the goal
of ALTO, although there might be situations where an "ALTO client
protocol proxy" in the residential gateway or "cable/DSL-router" might
make sense.

The goal of ALTO is to give guidance to applications (in particular P2P
file sharing applications) that leads to "better-than-random peer
selection". I think that there is consensus that the ALTO solution
should support multiple rating criteria that define this "better", and
that it should be possible to add new criteria later. For an enumeration
and discussion of rating criteria that have been proposed in the past
(this includes the provisioned access bandwidth), please refer to
section 5 of the ALTO requirements document:
http://www.ietf.org/internet-drafts/draft-ietf-alto-reqs-00.txt
This is still work in progress and any comments and feedback regarding
this list of criteria are highly appreciated (but I think discussing the
usefulness of a particular rating criteria should not have an impact on
the progress of the problem statement document).

Thanks,
Sebastian

---

From: Eric Burger <[email-masked]>
Date: Wed, 3 Jun 2009 05:51:32 -0400

Sounds even better.

On Jun 3, 2009, at 4:13 AM, Sebastian Kiesel wrote:

>>> participated
>> quite a

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 3 Jun 2009 17:49:51 +0200

> purchase of the plan, to the [A]DSL/high speed modem which passes it to 

The WG has been chartered to define a protocol to provide applications
with information to perform better than random peer selection; honestly,
I don't see how information about its own link capacity -- assuming it
is feasible to determine it in a meaningful way without recurring to
realtime measurements -- could help a peer in finding good peers to
connect to. So I'd say it is out of scope, but I'd be glad to be proven
wrong.

OTOH, but as I understand it this is not what you're talking about,
information about other peers' link capacity might fall within the scope
of ALTO, as it could be useful in peer selection optimization. However,
as Rich mentioned, there are many reasons why an ALTO server can't or
may not want to pass it.

-- 
Ciao,
Enrico

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 3 Jun 2009 12:05:40 -0400 (EDT)

Applications that can make a good use of provisioned link capacity:

-Voice relaying
-P2P video and audio conferencing

-s

On Tue, 2 Jun 2009, Randy Turner wrote:

>
> The ADSL2 Line MIB contains the upstream and downstream information that is 
> "current" within an ADSL2+ modem. A similar table is present in the original 
> ADSL line MIB as well (Full-rate DMT modems for example).
>
> downstream info, but this would only work for DSL modems. I'm not sure if 
> these MIBs are accessible over IP from the LAN side of the modem, but the 
> existence of the MIB objects would serve as a starting point for providing 
> this information to LAN-side hosts.
>
> It's not clear to me how an application would use this information. Can 
> someone present a use-case for how this information (given its' availability) 
> would be used?
>
> I don't think a P2P app would be interested in just the bandwidth to the 
> "head-end" of the connection, but more interested in "end-to-end" bandwidth 
> availability.  I know some apps (like the Kontiki P2P client) that can be 
> configured with the uplink speed of the broadband connection, and they can be 
> configured to only use a certain percentage of the available uplink 
> bandwidth, but this is crude since it can limit its' own performance, even 
> when no other app is running.  The modem or residential gateway that manages 
> the uplink itself is in a much better position to open or limit the bandwidth 
> of certain applications, based on available uplink bandwidth.
>
> Randy
>
>
>> point-to-point connection with the ISP and knew the link capacity which was 
>> 14.4, 33, or 56kb/s.
>> 
>> My question is whether it is within the scope of ALTO to design a mechanism 
>> to pass the link capacity, that ISP promised to the customer at the time of 
>> the purchase of the plan, to the [A]DSL/high speed modem which passes it to 
>> the devices upstream?
>> 
>> -salman

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 3 Jun 2009 12:20:52 -0400 (EDT)

> connect to. So I'd say it is out of scope, but I'd be glad to be proven

Examples of applications that can make use of provisioned link capacity:
-voice relaying
-p2p video and audio conferencing

> as Rich mentioned, there are many reasons why an ALTO server can't or

It is a protocol design issue whether/how provisioned link capacity should 
be advertised to other peers. I can design a p2p audio conferencing 
protocol where a peer, based on its provisioned link capacity or its 
fraction, only advertises the number of audio streams that it can mix.

I do not think that such an advertisement is any worse in the privacy 
sense than an advertisement which uses measured link capacity to 
determine the number of audio streams.

-s

---

From: John Leslie <[email-masked]>
Date: Wed, 3 Jun 2009 13:11:49 -0400

Enrico Marocco <[email-masked]> wrote:
> connect to.

   I'm confused why you would think that assumption justified...

> So I'd say it is out of scope, but I'd be glad to be proven wrong.

   I would hope that for any path or sub-path, maximum bandwidth and
minimum latency numbers would be in-scope -- though I of course agree
that not all ALTO servers would be willing to supply these numbers to
all clients.

   How these numbers compare to actual bandwidth and actual latency
seem to be our best available indication of congestion -- if we're not
getting maximum bandwidth and minimum latency we probably need to be
careful to yield to higher-priority traffic.

   That said, there may be far better indicators of which peers our
ISP would prefer us to try first; and I don't expect either of these
to be a primary selector.

   In practice, the uplink capacity is likely to be the bandwidth
limit for a large fraction of actual peers; so limiting total traffic
sent upstream will yield better real-time bandwidth-available
information -- as well as keeping the ISP happier.

   (I honestly don't see why any ISP would be unwilling to supply
that information _to_ its own customer.)

--
John Leslie <[email-masked]>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 3 Jun 2009 19:17:13 +0200

Hi,

On 2009-6-2, at 18:57, Salman Abdul Baset wrote:
> customer at

how useful would that information be? At best, it provides an upper  
bound for what throughput could be achievable if the access link was  
the path bottleneck for a given connection. But the path bottleneck is  
often elsewhere, and even when it is the access link, with increasing  
multiplexing (= larger home networks), the information doesn't seem to  
be so useful anymore.

In other words, I'd rather communicate with a peer on a DSL access  
that is full idle rather than a peer on a FTTH access that is badly  
congested.

Lars

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Jun 2009 10:39:34 -0700

> that information _to_ its own customer.)

The problem is, it may not be really stable or meaningful.

EG, Comcast's PowerBoost trick gives a temporary increase to available  
bandwidth by a token bucket technique.  The net result is that for  
small transfers, the available bandwidth is significantly larger.

How do you express an uplink capacity that varies based on usage  
history?

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 3 Jun 2009 14:02:59 -0400 (EDT)

The discussion is focused on 'provisioned link capacity' and not the 
transient or instantaneous capacity.

-s

On Wed, 3 Jun 2009, Nicholas Weaver wrote:

> bandwidth by a token bucket technique.  The net result is that for small 
> transfers, the available bandwidth is significantly larger.
>
> How do you express an uplink capacity that varies based on usage history?
>

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Jun 2009 11:05:23 -0700

> transient or instantaneous capacity.

But my point is that provisioned link capacity may be a volatile  
quantity.

---

From: John Leslie <[email-masked]>
Date: Wed, 3 Jun 2009 14:20:19 -0400

> The problem is, it may not be really stable or meaningful.

   Actually, nothing is "stable" forever...

> How do you express an uplink capacity that varies based on usage  

   Three quite different ways come to mind:

1) Express the maximum you will (ever) see in the foreseeable future;

2) Express the maximum you will see for (all of) an extended period;

3) Express the maximum right now with a "time-to-live".

   I have no horse in that race, but I commend #3 to your consideration.

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 3 Jun 2009 20:51:36 +0200

> -p2p video and audio conferencing

I don't actually understand how knowing *its own* provisioned link
capacity could help a peer in selecting a good voice relay or conference
node. I agree that it could be useful for the application itself, e.g.
to select a default codec, but to me that's just not peer selection
optimization, i.e. not ALTO.

-- 
Ciao,
Enrico

---

From: Randy Turner <[email-masked]>
Date: Wed, 3 Jun 2009 11:51:39 -0700

Hi,

Of the methods expressed below...

#1 is basically unusable.

#2 and #3 seem the same...where the "extended time" is the value of  
the TTL

It seems like the suggestion is that knowing the link speed of the  
broadband pipe provides 2 advantages:

1. The P2P app may want to "back off" it's use of the pipe to allow  
fair share to the bandwidth for other apps

2. The P2P app may be able to tune it's performance, to make maximum  
use of available bandwidth, to improve
     P2P user experience.

The problem is, in order to really achieve this you need some type of  
realtime algorithm that determines congestion on the link, and I  
haven't heard of an idea expressed so far that allows this. The  
options I've heard so far seem to suggest a way to estimate or guess  
what bandwidth might be available at some point.  However, there is  
very negative consequences for invalid assumptions on the part of a  
P2P app.  Meaning, if there is fuzziness in the method used to  
estimate available bandwidth, the implications on other apps  
(especially voice traffic) is intolerable.

The popular way to properly prioritize traffic from a home network  
outbound is for a residential gateway to manage outbound traffic,  
since it has knowledge of all the types of traffic trying to use the  
link.

If we were to design a protocol that "asks" the gateway about current  
status, and the gateway reports that the P2P app can "go for it" with  
respect to available bandwidth, it's possible that a voice call from a  
SIP endpoint somewhere on the home network may startup just after the  
P2P app receives the response.

Randy

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 3 Jun 2009 15:04:01 -0400 (EDT)

> optimization, i.e. not ALTO.

For relaying, provisioned link capacity (specifically, upstream link 
capacity) is helpful to determine how many voice or video streams a relay 
can admit.

Obviously, a relay may use a fraction (e.g., 50%) of provisioned upstream 
capacity to determine the number of streams to admit. In addition, a relay 
also needs to consider the current load on the link. Spare capacity, 
computed from provisioned capacity and current load, is a metric that can 
effectively guide relay selection.

-s

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 3 Jun 2009 15:14:42 -0400 (EDT)

On Wed, 3 Jun 2009, Lars Eggert wrote:

> how useful would that information be? At best, it provides an upper bound for 
> what throughput could be achievable if the access link was the path 
> bottleneck for a given connection. But the path bottleneck is often 
> elsewhere, and even when it is the access link, with increasing multiplexing 
> (= larger home networks), the information doesn't seem to be so useful 
> anymore.
>
> In other words, I'd rather communicate with a peer on a DSL access that is 
> full idle rather than a peer on a FTTH access that is badly congested.
>

Your congestion example is spot on. Provisioned link capacity (upstream 
and downstream) is not very helpful for peer selection unless the current 
load on the link is considered.

As I mentioned to Enrico, spare capacity, computed from provisioned link 
capacity and current load, can guide peer selection.

-s

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 3 Jun 2009 21:16:08 +0200

> capacity) is helpful to determine how many voice or video streams a relay 

Again, I agree that it could be useful for the application itself, for
example, as you say, for deciding how many streams to relay. But that
has little to do with peer selection optimization ALTO is all about, so
I still don't see how it could be considered in scope for this WG.

-- 
Ciao,
Enrico

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 3 Jun 2009 15:24:00 -0400

>(I honestly don't see why any ISP would be unwilling to supply that
information _to_ its own customer.)

I had thought the Salman was talking about ALTO sharing a peer's
provisioned access bandwidth to the client, which I still think has
privacy concerns. But Salman is talking about ALTO sharing a client's
own provisioned access bandwidth -- so sorry about responding to the
wrong question.

I could see some value in communicating the provisioned access bandwidth
to the client, but it seems a bit out of scope with regards to the
charter. But that could be interesting data to the application
nonetheless - why bother to download a 3.8 Mbps HD video stream if the
provisioned access bandwidth for the subscriber is only 1 Mbps.

Knowing how it works, I'm not sure that I would share the 'Powerboost
bandwidth' at all. I am pretty sure that choice #3 below (the maximum
right now with a "time-to-live") would not be feasible.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Leslie
Sent: Wednesday, June 03, 2009 2:20 PM
To: Nicholas Weaver
Cc: alto
Subject: Re: [alto] 'Link capacity' in scope?

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 3 Jun 2009 21:25:09 +0200

>    I'm confused why you would think that assumption justified...

Actually that was more a question than an assumption: when you have to
select 10 out of 1000 peers to connect to, how does the knowledge of
*your own* provisioned link capacity influence your choice?

> that not all ALTO servers would be willing to supply these numbers to

Yes, I think that to some extent preferences imparted by an ALTO server
will implicitly or explicitly deal with such information; in fact,
improving performance is file-sharing applications basically consists of
maximizing the bandwidth of the peers the querying node is going to
connect to. However, that is definitely not a mechanism any node can use
to retrieve information about its own provisioned bandwidth, is it?

-- 
Ciao,
Enrico

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 3 Jun 2009 15:27:04 -0400

I totally agree.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Enrico Marocco
Sent: Wednesday, June 03, 2009 2:52 PM
To: Salman Abdul Baset
Cc: alto
Subject: Re: [alto] 'Link capacity' in scope?

Salman Abdul Baset wrote:
>> The WG has been chartered to define a protocol to provide 
>> applications with information to perform better than random peer 
>> selection; honestly, I don't see how information about its own link 
>> capacity -- assuming it is feasible to determine it in a meaningful 
>> way without recurring to realtime measurements -- could help a peer 
>> in finding good peers to connect to. So I'd say it is out of scope, 
>> but I'd be glad to be proven wrong.
> 

--
Ciao,
Enrico

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 3 Jun 2009 15:28:25 -0400 (EDT)

> I still don't see how it could be considered in scope for this WG.

Nodes (clients) can use the spare capacity (provisioned - current load) of 
relay candidates as a metric to guide their search of relays. I think 
such a usage is peer selection optimization. What do you think?

-s

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 3 Jun 2009 21:49:20 +0200

> such a usage is peer selection optimization. What do you think?

Ok, I'm totally lost now. I thought your initial question was about a
mechanism any node can use to query its own provisioned bandwidth
(wasn't this what you asked in the first place?).

I agree that information about other nodes' link capacity could be
useful in peer selection optimization; however, as Rich, Lars and others
mentioned, such information could be very tricky to obtain and use in a
useful way ("current load" in you equation, other than the querying p2p
application's load, also includes the load of all other applications
running on the same local network).

-- 
Ciao,
Enrico

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 3 Jun 2009 16:11:44 -0400 (EDT)

> (wasn't this what you asked in the first place?).

I have not changed my question :) The description was an example of how 
nodes will make use of provisioned link capacity. I did not describe how 
current load can be calculated and I totally agree that ALTO must *not* 
describe a mechanism to determine current load.

Nevertheless, it is not impossible to use the number of [TCP] bits sent 
and received from a machine on which an ALTO enabled application is running to 
gauge current load. Yes, this is not a precise number but is reasonable 
enough to be useful.

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 3 Jun 2009 22:35:03 +0200

Salman Abdul Baset wrote:
> nodes will make use of provisioned link capacity.

No, the description was an example of how a node will make use of other
nodes' link capacity; it does not justify the need for a mechanism a
node can use to discover its own provisioned bandwidth.

-- 
Ciao,
Enrico

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 3 Jun 2009 17:44:30 -0400

> it is not impossible to use the number of [TCP] bits sent and received
from a machine on which an ALTO enabled application is running to gauge
current load.

Yes, but assuming that the machine is the only machine contributing load
to the broadband link.

Many folks have multiple computers in a household sharing a single
broadband link.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Salman Abdul Baset
Sent: Wednesday, June 03, 2009 4:12 PM
To: Enrico Marocco
Cc: alto
Subject: Re: [alto] 'Link capacity' in scope?

Nevertheless, it is not impossible to use the number of [TCP] bits sent 
and received from a machine on which an ALTO enabled application is
running to 
gauge current load. Yes, this is not a precise number but is reasonable 
enough to be useful.

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 3 Jun 2009 17:48:03 -0400 (EDT)

> node can use to discover its own provisioned bandwidth.

You are probably thinking a centralized ALTO server. There is no reason 
why peers cannot act as ALTO servers which inturn obtain their 
link capacity information from ISP managed ALTO servers.

Each peer as an ALTO server can obtain its provisioned link capacity from 
ISP and may distribute this information to other peers on request in a 
privacy preserving way. Spare capacity is one way to distribute this 
information.

-s

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 03 Jun 2009 15:10:57 -0700

> Many folks have multiple computers in a household sharing a single
And many ISPs have multiple links provisioned at speeds that combined 
would exceed the total available capacity to/from the box the links 
terminate in.

Knowing that your computer is plugged into a LAN served by a 1.5 Mbps 
down 384 kbps up ADSL line tells you approximately nothing about how 
much capacity you have between your computer and any other computer.

For starters, you might decide to exchange data with someone on that 
same LAN, in which case it wouldn't make sense to throttle. And if you 
do send traffic over the ADSL line, there's no guarantee that you'll 
have that much capacity on the very next hop, which might even be the 
very next layer 2 hop.

Matthew Kaufman

(Really that's "all ISPs"...)

---

From: John Leslie <[email-masked]>
Date: Wed, 3 Jun 2009 19:38:21 -0400

> *your own* provisioned link capacity influence your choice?

   It's more a matter of deciding _whether_ to try 10 or some other
number...

> maximizing the bandwidth of the peers the querying node is going to

   We are, I think, discussing the particular case where the bottleneck
is (probably) the upstream link. Once you hit that bandwidth, you know
it won't get any better.

> However, that is definitely not a mechanism any node can use to retrieve
> information about its own provisioned bandwidth, is it?

   "Retrieve" implies that some server already has that number. I see
no reason to forbid passing the number (within the ALTO protocol) if
the server already has it. I suspect non-ISP ALTO servers will want to
estimate that number; and I see no reason to forbid passing the estimate,
either.

   That said, I suspect the "minimum latency" number would be more
useful than "maximum bandwidth"...

---

From: Randy Turner <[email-masked]>
Date: Wed, 3 Jun 2009 16:51:13 -0700

I think the real question to ask is, why burden the WG with a protocol  
(for obtaining bandwidth from "somewhere") when the utility of
that information is going to be limited, at best, and on the average,  
probably unusable or even harmful to other apps on a home network?

I would focus on hop-count, locality, and maybe end-to-end congestion  
information...and maybe some type of favorable routing information
that an ISP could give you...

The only possible enforcement point to "throttle" how much broadband  
bandwidth is being used is at the device that owns the broadband  
upstream link (modem), or possible a residential gateway just behind  
the modem. It's the only device on the network that can aggregate  
usage information for all egress traffic out of the home network/LAN.

Randy

---

From: John Leslie <[email-masked]>
Date: Wed, 3 Jun 2009 20:02:37 -0400

> #1 is basically unusable.

   It seems suboptimal to me, too, but "unusable" overstates the case.
If you hit it, you know you won't get any more bandwidth.

> #2 and #3 seem the same...where the "extended time" is the value of  

   But with #3 you _know_ the TTL, while #2 leaves you guessing. The
advantage of #2 over #1 (when TTL isn't explicitly available) is that
the ISP can request a bandwidth limit for the P2P application to obey
(instead of needing to "enforce" it).

> use of available bandwidth, to improve P2P user experience.

   Also:

3. The P2P app can converge faster to the actual available bandwidth.

> realtime algorithm that determines congestion on the link,

   I thought this was already needed, though not in scope for ALTO.

> and I haven't heard of an idea expressed so far that allows this.

   LEDBAT seems to be progressing slower than ALTO... Nonetheless,
I'm sure folks there have ideas on how to find the bottleneck
bandwidth.

> The options I've heard so far seem to suggest a way to estimate or
> guess what bandwidth might be available at some point.

   "Guess" is, by definition, suboptimal.

> However, there is very negative consequences for invalid assumptions
> on the part of a P2P app. Meaning, if there is fuzziness in the method
> used to estimate available bandwidth, the implications on other apps  

   LEDBAT is specifically chartered to avoid excessive latency.

> since it has knowledge of all the types of traffic trying to use the  

   That sounds out-of-scope...

> P2P app receives the response.

   Agreed. But the plan, as I understand it, is for that to be LEDBAT's
problem; and LEDBAT is merely obliged to back off when latency increases.

   My concern, BTW, is far more for learning the mininmum-latency
number than for learning maximum-bandwidth. And what I want to do with
that number is pass it to LEDBAT.

   Thus, I want ALTO to be _able_ to report such numbers, whether or
not they're useful for choosing the order in which peers should be
tried. It strikes me as silly to interpret the ALTO charter so
narrowly as to forbid passing maximum bandwidth and minimum latency.

---

From: Randy Turner <[email-masked]>
Date: Wed, 3 Jun 2009 17:10:06 -0700

So it sounds like you're looking at the problem from the "other  
direction"...instead of trying to figure out what peers to use, your  
intended use
for minimum latency is to try and figure out what peers to "avoid" ?

Randy

---

From: Randy Turner <[email-masked]>
Date: Wed, 3 Jun 2009 17:11:15 -0700

Never mind, I had a logic seizure there for a moment in my last msg :)

Randy

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 3 Jun 2009 21:06:17 -0400 (EDT)

I am not sure if the utility of provisioned link capacity is limited. For 
applications such as voice or video relaying (which Skype does) or 
conference mixing, the provisioned uplink capacity provides a simple upper 
bound on the number of streams a link can support so that a peer does not 
send useless probes into the network to explore the capacity that does not 
exist.

As it has been discussed, there are caveats/dependency to using this 
information and understandably so. These include (1) detecting whether the 
link is idle which can only be precisely determined at the [A]DSL/cable 
modem, (2) instantaneous network variations, and (3) privacy concerns.

I think that applications should be able to query a [A]DSL/cable modem 
to determine the history of network connectivity; it is a separate 
question whether such querying is done by ALTO or any other protocol.

An application such as voice or video relaying or conferencing cannot 
ignore the instantaneous rate variations and must use this information in 
determining whether to admit a new stream or drop an existing one, just as 
the AS number of an IP address is not a definitive guide on latency. The 
provisioned link capacity and AS number information are useful hints that 
taken together with instantaneous load, guide peer selection.

In general, the information that can potentially guide peer selection 
exists at various points in the network such as machine's network link, 
residential gateway, edge router (for latency and AS number), multiple 
routers (hop counts). It is probably useful to think of querying this 
information from these distributed points.

-salman

On Wed, 3 Jun 2009, Randy Turner wrote:

>
> I think the real question to ask is, why burden the WG with a protocol (for 
> obtaining bandwidth from "somewhere") when the utility of
> bandwidth is being used is at the device that owns the broadband upstream 
> link (modem), or possible a residential gateway just behind the modem. It's 
> the only device on the network that can aggregate usage information for all 
> egress traffic out of the home network/LAN.
>
> Randy
>
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 4 Jun 2009 09:55:03 +0200

> load on the link is considered.

Agreed, but I understood that that was the information you were trying  
to propose for ALTO.

> capacity and current load, can guide peer selection.

Even if you could do this computation (which is difficult enough,  
because traffic at the access router may arrive form multiple  
different nodes in the local network, not just the box the P2P client  
is running on), you still only get a potential upper bound. Whether  
you will actually be able to use all or even most of that computed  
spare capacity will entirely depend on whether the access link happens  
to be the bottleneck resource of the path to the peer you end up  
choosing.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 4 Jun 2009 09:56:51 +0200

> gauge current load. Yes, this is not a precise number but is  

Not if you have multiple machines actively sharing the same access link.

Lars

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 4 Jun 2009 10:12:11 +0200

> link capacity information from ISP managed ALTO servers.

Uh? I'm thinking of a protocol clients can use to query servers in
distributed, peer-to-peer, or centralized systems. That protocol, as
people on this list agreed at chartering time, will be used to carry
network preferences (i.e. something along the line of "from net1 prefer
net2, avoid net3, select address X with priority Y...") to help peers in
peer selection optimization. Now, also considering the candidate
solutions that have been discussed so far (P4P/Infoexport, PROXIDOR,
H12...), what you are talking about sounds like a totally different
beast; I'm not saying that it would not be great to have that too, but
it is just not what a bunch of researchers, ISPs, P2P software
developers and network equipment vendors have agreed to work on.

-- 
Ciao,
Enrico

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 4 Jun 2009 10:20:21 +0200

> narrowly as to forbid passing maximum bandwidth and minimum latency.

It seems reasonable to allow the ALTO protocol to carry, in addition to
topology and cost-related information, also other information like
minimum and perhaps estimated latency (I'll let others argue whether
both would be feasible or not) about the target networks/endpoints. The
querying peer will then be able to make any use of such information,
including an initial tuning of the congestion control mechanism at the
transport layer. However, it will be hard to justify any significant
efforts in ALTO not aimed at improving peer selection with the current
charter (that, BTW, as a result of many discussion about the topic,
lists a set of widely agreed criteria to follow when considering what
information to put in the protocol).

-- 
Ciao,
Enrico

---

From: Lars Eggert <[email-masked]>
Date: Thu, 4 Jun 2009 10:51:10 +0200

On 2009-6-4, at 10:20, Enrico Marocco wrote:
> both would be feasible or not) about the target networks/endpoints.

Given that with the current queueing schemes and buffer sizes in use,  
path latencies to a large degree are a function of the path load, I  
don't see how this would be too useful. The best you could get is  
again a lower bound latency if the path happened to not have standing  
queues.

Lars

---

From: John Leslie <[email-masked]>
Date: Thu, 4 Jun 2009 07:53:45 -0400

Lars Eggert <[email-masked]> wrote:
>> It seems reasonable to allow the ALTO protocol to carry, in addition  
>> to topology and cost-related information, also other information like

   It's only the minimum latency that I'm interested in.

> path latencies to a large degree are a function of the path load,

   Instantaneous latencies, yes; minimum latency, no.

> I don't see how this would be too useful.

   Consider the algorithm of first trying paths with lowest minimum
latency...

> The best you could get is again a lower bound latency if the path
> happened to not have standing queues.

   Exactly!

   But we also get a decent measure of instantaneous queue length by
subtracting minimum latency from instantaneous latency.

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 4 Jun 2009 17:59:28 -0400 (EDT)

On Thu, 4 Jun 2009, Lars Eggert wrote:

> Agreed, but I understood that that was the information you were trying to 
> propose for ALTO.
>
> Even if you could do this computation (which is difficult enough, because 
> traffic at the access router may arrive form multiple different nodes in the 
> local network, not just the box the P2P client is running on), you still only 
> get a potential upper bound. Whether you will actually be able to use all or 
> even most of that computed spare capacity will entirely depend on whether the 
> access link happens to be the bottleneck resource of the path to the peer you 
> end up choosing.
>

As I mentioned earlier, applications cannot simply ignore network feedback 
comprising of packet losses and higher latencies. But using such a 
feedback is also necessary in existing ALTO scenarios.

Access vs. network can be determined through the use of network feedback, 
provisioned capacity, and current load.

It seems reasonable for applications to query the traffic at the 
[A]DSL/cable modem/residential gateway. Some one mentioned using MIBs 
for it and it is certainly plausible.

A reasonable application design strategy is to use X percent of spare 
capacity rather than attempting to fill it up. It is mostly file-sharing 
like applications that need to fill up the spare capacity.

-s

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 4 Jun 2009 19:04:31 -0400 (EDT)

> developers and network equipment vendors have agreed to work on.

If the goal of ALTO is to only improve the performance of Bittorrent-like 
applications, it will be useful to clarify that.

However, it seems reasonable to consider application-level-traffic-optimization
techniques for applications which may not be Bittorrent like. Real-time 
applications such as voice or video relaying or p2p conferencing are 
examples of these.

Provisioned link capacity, when used with current load, and network level 
feedback is useful for real-time p2p applications that need to select a 
peer for relaying or conferencing.

Determining current load on [A]DSL/cable modem seems like a problem for 
another WG. But it should not rule out passing provisioned link capacity 
in ALTO.

I have only asked if provisioned link capacity is in scope for ALTO. If 
not, it will be helpful to clarify which WG is more appropriate for 
determining this information.

In addition to provisioned link capacity, it is useful for end points to 
determine how much of their upload/download quota has been consumed 
(assuming ISPs that have a montly bandwidth cap). Like provisioned link 
capacity, this information is *indirectly* used by the peers to avoid 
peers that are running out of their quota or better select peers with no 
quota restriction. Such a usage is a form of application level traffic 
optimization in my opinion.

Also, like provisioned link capacity, peers do not have to explicitly 
share their remaining monthly quota but may only give an indication if 
they can support a stream or not.

-s

---

From: "Jan Seedorf" <[email-masked]>
Date: Fri, 5 Jun 2009 08:15:05 +0200

Dear Salman,

> optimization in my opinion.

I have been following the discussion, and I think it is an important observation (and maybe distinction from other use cases) that your use case suggests **indirect** guidance in peer selection. I think the ALTO WG so far has considered **direct** help in peer selection, meaning that the response from the ALTO server is sufficient for the ALTO client to select proper peers without any further communication among peers. In your "P2P real-time communication relay" use case, the ALTO client would query information from the server which per se would not help it select its peers. The client rather could use the information obtained from an ALTO server to either a) calculate other information (which btw also would not be much help to the client without knowing information about its peer candidates) or b) advertise the obtained information about himself to its peers so they can select it depending on this information (clearly **indirect** peer selection guidance).

All of the above is merely an observation which I think might help the discussion.

 - Jan

> Sent: Freitag, 5. Juni 2009 01:05
> To: Enrico Marocco
> Cc: alto

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 5 Jun 2009 10:24:47 +0200

> applications, it will be useful to clarify that.

The goal of ALTO is to help all applications that have to select a
subset of nodes to connect to out of a fairly big set of candidates, and
to help them to do better-than-random initial peer selection. The
charter is pretty clear about that.

So far you have made the point that information about candidate peers'
link capacity can help a node that needs to select among them: I don't
have a strong opinion about that and would certainly welcome a
discussion, possibly based on the five question of the litmus test we
put in the charter to provide guidance in a situation like this.
However, what you ask is not a means for a node to retrieve information
about other peers' bandwidth, but instead a mechanism for a node to
query *its own* provisioned link capacity. Yet you have not provided any
evidence that it would be useful in peer selection optimization.

> determining this information.

Let me try to answer this clearly. Link capacity -- or, according to
charter terminology, "maximum bandwidth" -- of peer/network candidates
is a kind of information whose inclusion in ALTO responses is worth
discussing (starting from the litmus test). A mechanism alternative to
SNMP for nodes to ask their broadband router / ISP what's their
provisioned link capacity is hard to consider in scope, unless you can
argument why it, in Jan's words, *directly* impacts peer selection.

-- 
Ciao,
Enrico

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 06 Jun 2009 21:17:53 -0700

Hi Jan, Eric, Enrico, and Vijay,

Thanks for the work on the problem statement document!

Below are some comments for the version at
(http://www.ietf.org/internet-drafts/draft-ietf-alto-problem-statement-01.txt):

Richard

==============
There are a couple places where I marked with **. These are more important.

- Both abstract and Introduction have this sentence: "Peer-to-peer 
  applications, such as file sharing, real-time communication, and live 
  media streaming ..." It is clear that VoD P2P streaming is becoming much 
  more popular than live. For example, if you check PPLive/UUSee, you will 
  see a few hundres live streaming channels, but a lot more VoD channels.  
  How about changing the sentence to " such as file sharing, real-time 
  communications, live and on-demand media streaming ..."

  Another nit is the word "real-time communication". Is voice/video 
  conferencing more explicit?

- Abstract: "direct peer-to-peer connections". Is the word "direct" necessary?

- Abstract: "This document describes problems related to optimizing 
  traffic generated by peer-to-peer applications and associated issues 
  such optimizations raise in the use of network-layer information."

    This sentence is a bit long and may parse in different ways. For 
    example, for the first "problems", it is not clear the "problems" are 
    caused by not optimizing or optimizing in the wrong way. It may be 
    helpful to revise the sentence a bit.

** Abstract: "may lead to suboptimal choices" and "to optimizing traffic";  
  in the text, it uses the word "best" in many places. I know this is 
  consistent with the working group name (this is a reason I do not like 
  the working group name :-( But on the other hand, the charter is trying 
  to achieve better than random, which may not be "optimizing", may be 
  suboptimal, and may not be the best. I feel that it is necessary to go 
  over the document to address this issue. What do you think?

- Page 1: "resources[WWW.wired.fuel]" need a space before [

- Section 1.1 first paragraph: "Different from the client/server 
  architecture, P2P applications ..." architecture and applications do not 
  match.  A suggestion is to either change architecture to applications 
  or applications to architecture.

- Section 1.1 second paragraph: "One advantage of P2P systems ..." This 
  time it uses the word systems. So we have P2P systems, P2P architecture, 
  and P2P applications. It may be necessary to make sure they are used in 
  a consistent way. I will not point out this later. I feel that the word 
  systems should be architecture here. What do you think?

- Section 1.1 second paragraph: "select among available instances": the 
  preceding sentence uses replicas not instances.

- Section 1.1 second paragraph: "deduce from empirical measurements". How 
  about "deduce from partial observations"?

- Section 1.1 second paragraph: "For example, one popular metric is an 
  estimation of round-trip time." to be consistent with the following 
  sentence, how about 

    "For example, one peer selection algorithm is based 
    only on the measurements during initial connection establishment between 
    two peers. Since actual data transmission does not begin, the algorithm 
    measures only the round-trip time and cannot reliably deduce actual 
    throughput between the peers. A peer selection algorithm that simply 
    uses round-trip time may result in a sub-optimal choice of peers."

- Section 1.1: "network operators or third parties can collect reliable 
  network information": reliable -> "more reliable"

- Section 1.1: "topology or instantaneous bandwidth available": do you 
  want to emphasize "instantaneous"? How about ->

  "topology and bandwidth"

- Section 1.1: "Normally, such information is rather "static", i.e., 
  information which can change over time but on a much longer time scale 
  than information used for congestion control on the transport layer":

 -> 

   "Normally, such information changes on a much longer time scale
   than information used for congestion control on the transport layer"

- Section 1.1: "it would be possible to greatly increase application 
  performance, reduce congestion and optimize the overall traffic across 
  different networks" 

  Do you want to use "would be"? I would remove “greatly”.

- Section 1.1: "presumably, both the application": before this, you always 
  say "applications", not a particular application.

- Section 1.1: "Thus, network operators have an incentive to provide, 
  either directly themselves or indirectly through a third party, such 
  information and applications have an incentive to use such information."

  ->

  "Thus, network operators have an incentive to provide, either directly 
  themselves or indirectly through a third party, such information; 
  applications have an incentive to use such information."

- Section 1.1: "Section 3 introduces the problem.  Section 4 describes 
  some use cases where both P2P applications and network operators benefit 
  from a solution to such a problem." Missing Section 2.

- Section 1.1: "The papers [I-D.bonaventure-informed-path-selection] and 

  [ACM.ispp2p] [WWW.p4p.overview] are ..." 

  Change to "The papers [I-D.bonaventure-informed-path-selection], 
  [ACM.ispp2p], and [WWW.p4p.overview] present". How about move 
  [ACM.ispp2p] to be the first to make them alphabetical order?

* Section 1.2: "better-than-random": this keyword appeared here for the 
  first time. It may make sense to make it appear earlier, as it is a key 
  working group design decision.

- Section 1.2: "It is not easy to foresee how such solutions will perform 
  in the Internet.  A more accurate evaluation requires representative 
  data collected from real systems by a critical mass of users."

  -> P4P field trials are (relatively) large, real systems. How about 

  change to:

  "It is not clear how such solutions will perform if deployed globally on 
   the Internet."

- Section 2: The definitions of the terms depend on hybrid, but hybrid is not
  defined. So some definitions read somehow strange. 

- Section 2: it defines "Overlay Network", but it is used only at defining 
  Application Protocol. Do you really need it?

- Section 2: "Resource Directory:  An entity that is logically separate from the
      resource consumer that assists a resource consumer to identify a
      set of resource providers.  Some P2P applications refer to the
      resource directory as a P2P tracker."

  Only separated from consumer, not provider? How about DHT?

** Section 3: definition of Host Location Attribute: "or any
  other localization attribute. I am not sure if it is necessary to
  specify that it is a localization attribute, because it is not clear
  what is localization. To some readers, localization may mean (e.g., 
  in windows) language used in UI, etc. How about "or any other host 
  connectivity attribute"?

  One issue I am considering is if the term Host Location Attribute 
  reflects our intention well, because it may include both location 
  (point on the topology) and other info such as bandwidth, customer 
  type etc. Unfortunately, we were not able to come up with a good 
  term. In P4P, we named it PID (provider ID, or partition ID) due to 
  lacking of a good term.

- Section 2: “The ALTO service gives guidance to a resource consumer 
  or resource directory about which resource provider(s) to select 
  in order to optimize the client's performance” change 
  “a resource consumer or resource directory” to “a resource consumer 
  and/or resource directory”.

- Section 2: “ALTO Server:  A logical entity that provides interfaces 
  to query the ALTO service.” 

  -> 

  “ALTO Server:  A logical entity that provides interfaces to the 
  queries to the ALTO service.”

- Section 2: “ALTO Client:  The logical entity that sends ALTO 
  queries.  Depending on the architecture of the application one may 
  embed it in the resource consumer or in the resource directory.” 

  Change "or" to "and/or".

* Section 2: “ALTO Response:  A message sent from an ALTO server 
  to an ALTO client, which contains guiding information from the 
  ALTO service.” 

  The Response may not need to directly from an ALTO Server. 
  We are using cache and P2P redistribution. How about:

   “ALTO Response:  A message contains replies for an ALTO query.”

- Section 2: the definitions of Local Traffic, Peering Traffic, 
  and Transit Traffic. I am not sure we need to define these terms. 
  I noticed that Transit Traffic is used once in this doc. But these 
  may not be stable terms. For example, there also can be the concepts 
  of last-mile traffic. I recommend removal. 

- Section 2: “Provisioning Protocol:  A protocol used for populating 
  the ALTO server with topology-related information.” There does not 
  appear to be a need to be so specific that it is only 
  topology-related information. How about just ALTO information?

- Section 2: Why introduce the term of “Inter-ALTO Server Protocol”? 
  It is not used in the document.

- Figure 1: How about not labeling the first entity only “topological
information.” It may also include policy information.

- Figure 1: Since you have introduced the terms already, why label
Peers and Resource Directory, instead of the terms that you have
already introduced, e.g., ALTO Clients?

- Section 3: “… do not benefit much from the above route-based 
  techniques” May not need to label "route-based techniques". Also, 
  it may cause discussions to say that applications cannot benefit. 
  How about change to “cannot directly use the aforementioned techniques”?

- Section 3: “Cooperating with external services aware of the network 
  topology could greatly optimize the traffic the P2P application generates.” 
  Who cooperating?

- Section 3: “the logical target is not a host, but rather a resource 
  (e.g., a file or a media relay) that is often available …” I am not 
  sure about the word “is often”. How about just say “can be available”?

- Section 3: This sentence “Selection of the closest one -- or, 
  in general, the best from an overlay topological proximity -- has much 
  more impact on the overall traffic than the route followed”. This sentence 
  hard to parse.

- Section 3: “Optimization of peer selection is particularly 
  important in the initial phase of the process.” I am not sure if necessary 
  to emphasize “particularly important in the initial phase”. A weaker statement
  can be better. 

- Section 3: “Consider a P2P protocol such as BitTorrent, where a
  querying peer receives a list of candidate destinations where a resource 
  resides.” This is not a correct description of BitTorrent. 

- Section 4.1: “   File sharing applications allow users to search 
  for content shared by other users and download it.” The word “it” 
  is not clear? 

- Section 4.1: “Typically, search results consist of many instances of 
  the same file (or chunk of a file) available from multiple sources.” 
  This is more an EDonkey model. BitTorrent is not this model. 

- Section 4.2: “network location systems or often delegated to the 
  user himself”: himself -> herself

- Section 4.3: “The goal of an ALTO solution is to help peers to find 
  the best sources and the best destinations for media flows they 
  receive and relay.” Source has particular meaning in P2P streaming. 
  How about “The goal of an ALTO solution is to help a peer to find 
  effective communicating peers that exchange the media content”?

- Section 4.4: “In such systems, peers maintain addresses of other
peers participating in the same DHT in a routing table, sorted
according to specific criteria.” A reader may get the impression
of maintaining ALL other peers. How about “a peer maintains the
addresses of a set of other peers participating in the same DHT
in a routing table”?

- Section 4.4: “An ALTO solution will provide valuable information
for DHT algorithms.” I will not say “will”. It is still a tricky
question. How about replace “will” with “can”?

- Section 5.1: “Network operators.  Network operators usually have 
  full knowledge of the network they administer and are aware of 
  their network topology and transit and peering traffic policies.” 

  How about remove “transit and peering traffic policies”? There is 
  no need to limit to them.

- Section 5.1: “Likewise, there are other user communities that 
  expect a service that services P2P applications be itself a 
  distributed, possibly even a P2P, service.” The wording needs change. 

  How about “Likewise, there are other user communities to expect 
  that the ALTO service be a distributed service, possibly even based 
  on or integrating with a P2P service.”?

- Section 5.4: “However, operators often consider such network 
  information to be confidential.”

-> 

  “However, operators often consider such network information to 
  be confidential to be revealed in details.”

- Section 5.5: “Caching is a common approach to optimizing 
  traffic generated by applications that require large data 
  transfers.” How about remove “common”?

  Also, instead of say “large data transfers”, which may be 
  interpreted as large files, how about “large amounts of data transfers”?

- Section 5.5: “Thus, the cache must use the same protocol 
  as the querying peer. Any cache solution for a given protocol 
  needs to present that same protocol to the client. Said differently, 
  each caching solution for a different protocol needs to implement 
  that specific protocol.  For this reason, one can only reasonably 
  expect caching solutions for the most popular protocols, 
  such as HTTP and BitTorrent.”  

  I presented the Data Locker concepts at last IRTF. It shows that 
  this may not need to be the case. It will be a long discussion. 
  How about shorten the preceding sentences to avoid debates?

On Fri, 29 May 2009, 12:59pm -0700, Jon Peterson wrote:

---

From: Salman Abdul Baset <[email-masked]>
Date: Sun, 14 Jun 2009 23:47:34 -0400 (EDT)

Apologies for a bit delayed response.

> evidence that it would be useful in peer selection optimization.

I had given two examples of information which nodes can obtain from 
ALTO servers and exchange them using any p2p protocol in a privacy 
preserving way to guide peer selection. These are:

(1) provisioned link capacity

(2) monthly download/upload usage and cap

Provisioned link capacity, when used with current load on the machine and 
the network, can be used to select a high bandwidth relay from the 
possible candidates (think two relays, one on DSL and the other on fiber). 
Yes, estimating current load can only be done at the residential gateway 
and may be SNMP is feasible for that.

For ISPs that enforce a download/upload cap, current usage is extremely 
helpful to select suitable peers for file transfer, voice/video relaying, 
and conferencing.

Besides peer selection, these information also have diagnostic uses.

(1) and in particular (2) gives an example of traffic optimization which 
is really beneficial for the end user. P2P protocols can use this 
information to select suitable peers. In my opinion, (1) and (2) satisfy 
the litmus test and happy to discuss them in a separate thread. Exclude 
(1) and (2), and application layer traffic optimization likely becomes 
ISP-only-traffic-optimization.

-s

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 15 Jun 2009 10:12:23 +0200

> and may be SNMP is feasible for that.

We are talking past each other. Yes, I agree that information about link
capacity might be used to enhance peer selection. But its knowledge of
other peers' link capacity that matters, you say it yourself: peers
retrieve information about their own provisioned bandwidth and circulate
that among themselves. At the end of the day, it's information about
other peers that you are actually going to consider when have to decide
which relay to connect to, and I think it's that kind of information
that we should start discussing to move forward.

-- 
Ciao,
Enrico

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 16 Jun 2009 00:59:00 -0400 (EDT)

In general, the question is when a node obtains information using ALTO 
about itself (or other nodes), can it fully or partially share this 
information with other nodes using any p2p protocol?

Or what is the incentive for a node to share ALTO-obtained information 
with other nodes using a p2p protocol?

A node has no incentive to share ALTO-obtained information if it can query 
any ALTO server and always get the same response.

However, a node may be restricted from querying any ALTO server. This may 
be due to several reasons such as an ISP ALTO server refusing queries from a 
random IP address. Further, it is quite plausible that responses of 
different ALTO servers may not be the same (multipath routing etc).

Thus, to guide peer selection, a node has an incentive in sharing 
ALTO-obtained information using any p2p protocol with other peers.

And if a node can share ALTO-obtained information with other peers using a 
p2p protocol, it can very well share provisioned link capacity and monthly 
usage.

What do you think?

-s

---

From: Richard Alimi <[email-masked]>
Date: Tue, 16 Jun 2009 12:16:12 -0400

Hi Salman,

> information with other nodes using any p2p protocol?

This is an interesting question.  I don't think it is reasonable for the ALTO 
protocol to dictate whether ALTO Clients can or cannot share the information 
with others.  If the ALTO Protocol were to dictate whether information is 
redistributable or not, then we may find ourselves in a DRM mess.

The part that the ALTO Protocol should address (and indeed it is in the 
requirements document) is the ability to support authentication and 
authorization of ALTO Clients to ALTO Servers.  Whether the provider of the 
ALTO Server asks an ALTO Client to sign some sort of agreement not to 
redistribute information before being granted access would not be a problem 
solved by the ALTO Protocol.  This additional business agreement would be 
entirely outside of the scope of ALTO.

What do you think?

> with other nodes using a p2p protocol?

One benefit is scalability.  Consider a case where millions of peers tune in 
to watch the Spring Festival in China (largely concentrated within only a few 
ISP's).  If each individual peer were to start up just before the event 
started and request ALTO information, there may be a large bottleneck at the 
ALTO Server. If they can redistribute ALTO information amongst themselves, 
then load on the ALTO Server is reduced.  Of course, multiple ALTO Servers 
could be used, but this is additional investment for the ISP.

Some P2P clients actually already have a mechanism for this built-in. For 
example, Vuze distributes plugins and application updates using P2P.

> any ALTO server and always get the same response.

I tend to disagree with this statement. While it may be able to get the 
information, there may be scalability issues with a large number of ALTO 
Clients.  The ALTO Clients may be able to get the information faster by 
redistribution over P2P.  If an ALTO Server cannot meet the demand of a large 
number of ALTO Clients, then some ALTO Clients may not get the ALTO 
Information at all within the desired time.  See the argument above.

> be due to several reasons such as an ISP ALTO server refusing queries from
> a random IP address. Further, it is quite plausible that responses of

One item we have been thinking about in the P4P/InfoExport protocol is how to 
allow for redistribution.  You bring up an important point here.  Ideally, a 
response from an ALTO Server that is redistributable, should be self-
contained.  That is, the entity that is redistributed should (1) Clearly 
indicate the inputs for which the response is valid, and (2) contain all of 
the information required to parse/understand the response.

For example, if the ALTO Server is asked for all of the PIDs and the Network 
Locations (e.g., IP prefixes) within them, then this response may be 
redistributable.  A response containing the set of costs amongst PIDs may also 
be redistributable.

If the ALTO Server is asked to rank a set of candidate IP addresses from the 
perspective of a peer's own IP address, it may not even make sense to 
redistribute this response, since it is dependent on the state of the P2P 
client making the request, and is also more dynamic information.

> ALTO-obtained information using any p2p protocol with other peers.

If a peer is using other peers' retrieved ALTO Information, it must be careful 
to take into account what the ALTO information is, and whether it matters or 
not if the information was obtained from a different "perspective" in the 
network.

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: Eric Burger <[email-masked]>
Date: Thu, 18 Jun 2009 18:24:10 -0400

There is no physical method prevent an ALTO client from sharing query  
results, so there is no point in having it in the protocol.