Subject: [alto] Comments on requirements draft

From: Spiros Spirou <[email-masked]>
Date: Wed, 25 Feb 2009 10:02:14 +0200

> + requirements: draft-kiesel-alto-reqs was discussed during the last two
>   meetings, but it seems there is still no fundamental agreement in the
>   WG about the approach the requirements document should adopt. The
>   situation has now been stale since Minneapolis: if you want to
>   contribute to this work and have an opinion, this is the very right
>   time to let the group hear it;

The draft takes mainly the P2P system point of view. A peer/tracker 
accesses the ALTO service and gets some info that can enhance peer 
selection. This is good for a P2P system, but what's in this for the 
provider of the ALTO service? In the current draft, info seems to flow 
only from the ALTO service to the P2P system. I feel that there is (or 
should be) a reverse flow of info as well: the P2P system informs the 
provider of the ALTO service (realistically, a network operator) about 
P2P system traffic, so that the operator can do efficient traffic 
management. This might be the missing, complementary incentive that will 
make deployment and use of an ALTO service logical for both players: P2P 
systems and operators.

Also, to reflect the varying needs of P2P systems and their users, I 
think there must be a way for an ALTO client to signal to the ALTO 
service preferences regarding rating criteria to be used in calculating 
recommendations. (I think this has been already proposed by various 
people on the list).

Finally, neighboring domains might agree it makes business sense to 
optimize P2P traffic in collaboration. An interface between ALTO 
services that would facilitate the exchange of (summarized) topological 
info to increase the optimization scope of either, would be helpful in 
this case.

Specific changes to the draft that reflect the above are:

- Abstract: replace "The goal of Application-Layer Traffic Optimization 
(ALTO) is to provide guidance to applications, which have to select one 
or several hosts from a set of candidates, that are able to provide a 
desired resource. These recommendations shall be based on parameters 
that affect performance and efficiency of the data transmission between 
the hosts, e.g., the topological distance." with "Lack of network 
information at the application layer makes replica selection inefficient 
and suboptimal. At the same time, lack of application traffic 
information at the network layer makes network resource management 
difficult and expensive. The goal of Application-Layer Traffic 
Optimization (ALTO) is to guide applications in selecting hosts from a 
set of resource-providing candidates, while providing network entities 
with information about application traffic."

- sec#2, par#3, add after 1st sentence: "At the same time, ALTO aims in 
providing the network with information about P2P traffic, which is 
normally hard to attain, in order to help traffic management."

- sec#2, par#4, add after last sentence: "Similarly, it would be 
difficult for network entities to acquire application information by 
other mechanisms (e.g. Deep Packet Inspection), because of increased 
cost or obfuscation of application flows."

- sec#2, par#5, in 1st sentence: replace "provide the ALTO service" with 
"facilitate the exchange of information between the application and the 
network".

- REQ. 1: replace "queried" with "accessed".

- sec#4.1, add after REQ. 1 and re-number accordingly: "REQ. 2: An ALTO 
service MAY implement a well-defined interface, which can be used by 
other ALTO Services to extend their scope of optimization."

- sec#4.1, add after REQ. 2 and re-number accordingly: "REQ. 3: The ALTO 
clients MUST be able to submit to the ALTO service information that can 
be used by network operators to optimize network resource consumption."

- REQ. 4, par#3: remove duplicate "a" before "host".

- REQ. 5: replace "as well as protocol versioning support to clearly 
distinguish between incompatible major versions of the protocol." with 
"protocol versioning support to clearly distinguish between incompatible 
major versions of the protocol, as well as additional modes of operation."

- REQ. 6: replace "MUST" with "SHOULD"; otherwise the ALTO service MUST 
preclude non-complying applications.

- REQ. 12: replace "to discard" with "discarded".

- sec#4.2, add after REQ 13 and re-number accordingly: "REQ. 13: The 
ALTO protocol MAY have a mechanism by which the ALTO service can specify 
the level and precision of application information required from the 
ALTO client."

- sec#4.2, add before REQ 14 and re-number accordingly: "REQ. 13: The 
ALTO protocol MAY have a mechanism by which the ALTO client can specify 
preferences and relative importance of rating criteria to be used by the 
ALTO service in calculating recommendations for resource provider 
selection."

- sec#5, par#1: replace "The goal of ALTO is to provide guidance to 
resource consumers that have to select resource providers." with "The 
goal of ALTO is to provide guidance to application resource consumers 
that have to select application resource providers, while assisting 
network operator in optimizing network resource consumption."

Thanks,

Spiros

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 25 Feb 2009 14:18:14 +0100

Spiros,

Thank you for your comments on the requirements draft. More sse inline.

On Wed, Feb 25, 2009 at 10:02:14AM +0200, Spiros Spirou wrote:
> In the current draft, info seems to flow only 
> from the ALTO service to the P2P system. I feel that there is (or should 
> be) a reverse flow of info as well: the P2P system informs the provider of 
> the ALTO service (realistically, a network operator) about P2P system 
> traffic, so that the operator can do efficient traffic management.

The extension you propose here sounds interesting but is rather
substantial, so I kindly ask you to give us more information (if you
have any), and the other folks here on the list to comment on it:

- Are there any field trial or simulation results, which show that
  this mode of operation can improve the situation?
- Would ALTO server operators (i.e., network operators according to your
  assertion) be willing to receive information from customers (users)
  via this interface, or will they only trust their own traffic
  monitoring systems? How big is the risk of this interface being abused?
- Who is willing to contribute to this work at this point in time?

> Also, to reflect the varying needs of P2P systems and their users, I think 
> there must be a way for an ALTO client to signal to the ALTO service 
> preferences regarding rating criteria to be used in calculating 
> recommendations. (I think this has been already proposed by various people 
> on the list).

Indeed. Some days ago I posted a summary of such rating criteria,
which have already been proposed during former discussions, to this
mailing list. I am planning to include them in the next version of
the requirements draft, so comments are most welcome. That mail was:

Message-ID: <[email-masked]>
Date: Wed, 11 Feb 2009 14:54:57 +0100
Subject: [alto] list of possible attributes (was: Re: differences
        among applications)

> optimize P2P traffic in collaboration. An interface between ALTO services 
> that would facilitate the exchange of (summarized) topological info to 
> increase the optimization scope of either, would be helpful in this case.

Sure. The fact that this is one part of the big picture has been
discussed in the past (see, e.g., the slides from the Dublin meeting)
but so far the main focus was on the interface to the clients.
Can you propose requirements regarding this interface, or even a
solution approach?

> Specific changes to the draft that reflect the above are:

Thanks. I will consider them when we produce the next revision of the
draft.

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: Laird Popkin <[email-masked]>
Date: Wed, 25 Feb 2009 08:47:54 -0500 (EST)

The last P4P field test (from which Comcast has distributed results) compared the two communication models that Spiros describes.

In one case we implemented a "generic" model that applied the ISP guidance to the p2p network with no input from the p2p network.

In the other case, the p2p network reported peer distribution and throughput information and used that to produce guidance that was "tuned" to the specifics of the swarm at that point in time.

We did not see large improvements in performance. In addition, the first model was significantly easier to implement - there are fewer, simpler messages sent much less often, much less data to compute and store, etc. Importantly, the one-way information flow does not raise privacy concerns. Given this, we (the P4P Working Group) are focusing on the first model for now.

That being said, there's certainly a potential for deeper knowledge of the swarm distribution to provide superior guidance, so we would envision this capability as an optional extension that could be utilized when business and technical issues align.

The idea of communications between ISPs on this front is very interesting - this is worth pursuing, IMO.

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

----- Original Message -----
From: "Sebastian Kiesel" <[email-masked]>
To: "spiros spirou" <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, February 25, 2009 8:18:14 AM (GMT-0500) America/New_York
Subject: Re: [alto] Comments on requirements draft

Spiros,

Thanks,
Sebastian

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

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 27 Feb 2009 12:57:12 -0800

Hello,

As a general comment, the draft does not feel like requirements and more
like a possible protocol solution and at the same time many REQs need to be
more specific about what the requirement actually is.

I think this draft needs quite a bit of work. Are there plans for an update
for the next IETF?

Specific comments:

1) "ALTO Interface"

What is an ALTO interface?

2)

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

This seems a recipe for interoperability issues. Standardization means in a
basic level lack of flexibility so people can interoperate.

So, "ALTO must implement _one_ well-defined interface as specified in....".
Only one interface must be a MUST, otherwise people can pick and choose.

3)

"   REQ. 4: One mode of ALTO operation is that ALTO clients may be
   embedded directly in the resource consumer (e.g., peer of an
   unstructured P2P application), which wants to access a resource.

   However, another mode of operation is to perform ALTO queries
   indirectly, via resource directories.  These translate a resource
   identifier to a list of resource providers with their corresponding
   transport addresses.  The resource directories may issue ALTO queries
   to solicit preference on such lists, considering the respective
   resource consumer."

At this day and age of v4<->v6 transition we should try to avoid embedding
IP addresses from a client in a control protocol. You have NATs everywhere
and if we uphold the second mode of operation we would be asking for ALGs in
devices, and more importantly v4<->v6 ALGs.

4)

"   REQ. 6: The information available from the ALTO service is not a
   replacement for congestion control mechanisms.  Applications using
   ALTO MUST ensure that they do not cause congestion in the network,
   e.g., by using TCP transport, which includes congestion control
   mechanisms."

This does not seem to belong here. What we have here is basically an ALTO
draft mandating through a "MUST" how clients behave in the transport layer
in a requirements draft.

5)

"   REQ. 7: Any application designed to use ALTO MUST also work
   reasonably if no ALTO servers can be found or if no responses to ALTO
   queries are received, e.g., due to connectivity problems or overload
   situation."

The word "reasonably" gives a wrong idea here. How reasonable? I suggest
just saying the "protocol should be robust..."

6)

"   REQ. 9: An ALTO client MAY retransmit an unanswered ALTO query after
   a reasonable amount of time, or it MAY query a different server.
   Otherwise, or if all retransmissions or queries to different servers
   have failed as well, the ALTO client MUST report to the application
   that no ALTO information is available.  In this case, the application
   has to perform the resource provider selection without ALTO guidance."

The application is always free to perform resource provider selection
without ALTO guidance with or without failures. One does not follow from the
other. 

Moreover, this seems very protocol specific. I would bundle this with "ALTO
protocol must implement a retransmission strategy...". I suggest staying
away from exactly how it will be done, this would be in the protocol or some
other spec. 

7)

"  REQ. 10: An ALTO client MUST limit the total number of unanswered
   ALTO queries on a per-server basis.  This limit MUST be reduced if a
   request times out and MAY be increased if several subsequent queries
   succeed without a timeout."

This is really, really implementation specific on both client and servers.
It is the same as dictating how HTTP client and servers will behave in
overloaded situations. Also, you seem to imply some sort to incremental
increase in the protocol if responses are received on time. Are we
implementing some sort of congestion control and backoff on application
level?

8)

I would suggest leaving REQ-10, REQ-11 and REQ-12 our of this draft and work
on these items in a future "overloading draft" where we hash out
requirements, specific messages, etc. These requirements will complicate the
protocol unnecessarily at this stage. I'm not saying we should not do it,
just saying to postpone it for this iteration of the charter or leave to
possible extensions by vendors.

Again, protocol design needs to allow us to build upon it (already covered
in another REQ), but the implementation needs to start simple.

9)

"   REQ. 13: The ALTO protocol MAY have a mechanism by which the ALTO
   client can specify the required level of precision.  If only a medium
   amount of data has to be exchanged, it may be sufficient to get a
   quick answer from the ALTO service, which results in a certain
   improvement compared to a resource provider selection without any
   ALTO guidance.  If, however, very large amounts"

This is very vague. What is medium, what is large? For which networks,
types? Mobile, FTTH? I think this should be rewritten without talking about
precision. There are other reasons to want less information such as less
reduced memory and power such mobile devices.

10)

"   REQ. 16: Different instances of the ALTO service operated by
   different providers must be able to coexist."

Why this is under security and privacy? Can you expand on this req?

11)

   "REQ. 17: The ALTO protocol MUST support mechanisms for mutual
   authentication and authorization of ALTO clients and servers."

Must support "a" mechanism....Otherwise we are saying the protocol will be
able to negotiate between different authentication and authorization
schemes. Are we?

I'm not even sure this needs to be a MUST but I have no strong feelings
about this. ALTO will probably be a add-on to protocols like Bittorrent
running in the background, so in practical terms, are we assuming the user
will put username and password, implement TLS, etc? How does this
requirement translate to the actual protocol, ISP and user experience?

12)

"   REQ. 21: If the ALTO protocol supports including privacy-sensitive
   information (such as resource identifiers or transport addresses) in
   the ALTO queries or replies, the protocol MUST also support
   encryption, in order to protect the privacy of users with respect to
   third parties."

Quite a tall order. The user might be using a legal P2P streaming service
and does not care about privacy and confidentiality.

I think this needs to be reworded. Just because a resource identifier is
present in the query, does not mean encryption is automatically needed. If
we say ALTO is going to work over TLS or something like it, we need to
specify how exactly this will work. It took quite some time for SIP over TLS
to converge.

Are we going to do that on the protocol spec, an ALTO over TLS spec?

Thanks,

Reinaldo