Subject: [alto] General comment about draft-penno-alto-protocol-03.txt

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 28 Jul 2009 10:55:49 +0200

Hi all,

I have a general comment about draft-penno-alto-protocol-03.txt after reading it and some more  comments:

The draft tries to incorporates now all other in parallel existing approaches (i.e., P4P, ALTO Info Export, Query/Response, ATTP, and Proxidor) but without any major discussion about the usefulness of this. All approaches have their pros and cons, and they are quite different ways of tackling with ALTO. The discussion about the various proposal just started and IMHO it was not clear which of the many does actually address the general challenges of ALTO. 

This means (taking some as example):
- P4P addresses the challenges out of the P4P project, which the specific mechanics of Comcast and Pando. I do see the value of P4P, but it is one case how you could do it, i.e., I'm not saying that this is bad. I like the approach very much. However, I do not (yet) see the evidence that P4P works for tracker-less P2P and in other deployments, even though most of the people believe this. 

- Proxidor has a different view IMHO to ALTO, i.e., very operator driven. By solely integrating this, there might be a loss of functionality, e.g., Proxidor works also tracker-less p2p.

- ATTP was a bit orthogonal to the other approaches and less to do with ALTO (even though it is related).

Second, I couldn't really find out what parts are from the various other incorporated protocols, other than this looks as an evolved P4P proposal without explicitly saying what the benefits of the merger from the various protocols are.

The protocol claims to "At the same time, it introduces additional techniques  to address potential scalability and privacy issues." (first paragraph, 2nd sentence of Section 2). However, I'm clueless after reading what these techniques are and why they're not discussed in the security section (privacy as term pops up in this sentence, and nowhere else).

Thanks,

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 28 Jul 2009 14:01:50 +0200

I've just learned in the session that there is actually a loss of functionality in the merger between Proxidor & P4P: the sorting server-based oracle is just gone.

Any reason that this is not documented?

  Martin

[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Stiemerling
> Sent: Tuesday, July 28, 2009 10:56 AM
> To: alto
> Subject: [alto] General comment about draft-penno-alto-protocol-03.txt
> 
> Hi all,
> 
> The draft tries to incorporates now all other in parallel existing
> approaches (i.e., P4P, ALTO Info Export, Query/Response, ATTP, and
> Proxidor) but without any major discussion about the usefulness of
> this. All approaches have their pros and cons, and they are quite
> different ways of tackling with ALTO. The discussion about the various
> proposal just started and IMHO it was not clear which of the many does
> actually address the general challenges of ALTO.
> 
> - P4P addresses the challenges out of the P4P project, which the
> specific mechanics of Comcast and Pando. I do see the value of P4P, but
> it is one case how you could do it, i.e., I'm not saying that this is
> bad. I like the approach very much. However, I do not (yet) see the
> evidence that P4P works for tracker-less P2P and in other deployments,
> even though most of the people believe this.
> 
> - Proxidor has a different view IMHO to ALTO, i.e., very operator
> driven. By solely integrating this, there might be a loss of
> functionality, e.g., Proxidor works also tracker-less p2p.
> 
> Second, I couldn't really find out what parts are from the various
> other incorporated protocols, other than this looks as an evolved P4P
> proposal without explicitly saying what the benefits of the merger from
> the various protocols are.
> 
> The protocol claims to "At the same time, it introduces additional
> techniques  to address potential scalability and privacy issues."
> (first paragraph, 2nd sentence of Section 2). However, I'm clueless
> after reading what these techniques are and why they're not discussed
> in the security section (privacy as term pops up in this sentence, and
> nowhere else).
> 
> Thanks,
> 
>   Martin
> 
> 
> [email-masked]
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: stefano previdi <[email-masked]>
Date: Tue, 28 Jul 2009 14:13:27 +0200

On Jul 28, 2009, at 2:01 PM, Martin Stiemerling wrote:
> I've just learned in the session that there is actually a loss of  
> functionality in the merger between Proxidor & P4P: the sorting  
> server-based oracle is just gone.

Proxidor capability of ranking/rating paths is still there and  
functionality
is entirely preserved.

See section 4 of the draft for details.

s.

>> - ATTP was a bit orthogonal to the other approaches and less to do  
>> with
>> ALTO (even though it is related).
>>
>>

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 28 Jul 2009 14:37:10 +0200

Stefano,

> See section 4 of the draft for details.

hmm, which part of section 4?

I assume that still the sorting feature *at the server* is lost. I remember Anja being keen on having that, and I do also remember that the ISPs liked this very much. 

I personally didn't like this too much, but still the server could do some sorting during the query time (see also the H12 draft).

  Martin

---

From: stefano previdi <[email-masked]>
Date: Tue, 28 Jul 2009 14:43:28 +0200

On Jul 28, 2009, at 2:37 PM, Martin Stiemerling wrote:

> I assume that still the sorting feature *at the server*

I'm not sure I understand  "at the server"...

if you refer to the case where:
- client send list of addresses
- server rank/rate/sort them
- server replies with an ordered list

then, this is what we do in section 4.

s.

> is lost. I remember Anja being keen on having that, and I do also  
> remember that the ISPs liked this very much.
>
> I personally didn't like this too much, but still the server could  
> do some sorting during the query time (see also the H12 draft).
>
>  Martin

---

From: Obi Akonjang <[email-masked]>
Date: Tue, 28 Jul 2009 15:22:00 +0200

Hi Martin,

To add to what Stefano has already stated, the server is not obliged to
use a topology map in this particular case. This should be in line with
what most ISPs desire.

Best regards,
Obi

---

From: Richard Alimi <[email-masked]>
Date: Tue, 28 Jul 2009 10:08:54 -0400

Hi Martin,

Thank you for the comments.

> hmm, which part of section 4?

In addition to Stefano's response, see Section 7.3 and slides 36-38 of the 
slides from today:
  http://www3.ietf.org/proceedings/75/slides/alto-5.ppt

These depict how the use case works in some more detail.

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 28 Jul 2009 11:10:11 -0400

Hi Martin,

I really need to say that this is an excellent, fundamental comment!

Let me start with your second comment ("Second, I couldn't really find 
out what parts are from the various other incorporated protocols ..."). 
In this sense, we have succeeded in achieving seamless integration :-) 
 From the start,  it is clear to multiple authors of multiple proposals 
that there is not an inherent conflict of the many proposals. There is 
much synergy, in terms of service model, among many proposals already (I 
remember saying this at last IETF :-). The presentation slides listed 
key features of contributing proposals, and you can see large overlap. 
During our merge, we made an effort to *not* do a non-overlapping 
partition of ideas to different previous proposals.
As someone working on P4P, I would say that the current design has 
improved substantially over original P4P both in terms of service model 
and protocol. Designers of other contributing proposals sure can share 
how they think the current design improves over their previous 
proposals. Let me list some key *protocol/implementation* features that 
substantially improved over the very original P4P design and thus show 
the benefits. Of course, this list is my personal opinion and is by no 
means complete:

- A general, flexible protocol framework (e.g., server capability query 
as some kind of negotiation, generic endpoint property, reverse map) for 
extension
- XML protocol encoding for flexibility
- HTTP caching
- Possibility of batched distribution of ALTO info, for example, as a file

As a general rule, I feel that protocol design should be flexible, 
extensible, and consider implementation efficiency. Many good ideas of 
contributing proposals are reflected in the current, merged design, IMHO :-)

In terms of service model, you raised an excellent point as well. I see 
two basic service models in terms of providing path rating service:

- Network location map (clustering) to (implicitly) indicate 
coarse-grained proximity/preference (i.e., if same location, then it is 
preferred); preferred by some ISPs such as China Telecom as a starting 
point;

- Explicit rating of communication patterns: even here it can provide 
info in two ways (batched cost map or ranking list).

It is amazing to see that the preceding service models integrated quite 
cleanly in the current design without loss or substantial complexity. So 
I worry less about losing functionality, but more about providing 
guidelines to ISPs on how to use the ALTO service in their scenarios. 
Clearly a use-case document can be helpful.

Again, thank you so much for the excellent comment!

Richard