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

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 7 Aug 2009 16:30:06 +0200

Hi folks,

Sorry for being so slow with coming back to this, I got sidetracked with other stuff.

> -----Original Message-----
> From: Richard Alimi [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 2:50 PM
> To: [email-masked]
> Cc: Martin Stiemerling; stefano previdi
> Subject: Re: [alto] General comment about draft-penno-alto-protocol-
> 03.txt
> 
> Hi Martin,
> 
> Thank you for the comments.
> 
> On Tuesday 28 July 2009 8:37:10 am Martin Stiemerling wrote:
> > Stefano,
> >
> > > 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.
> >
> > 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.

The use case is explained but I still cannot understand how this is handled in the protocol specification. I.e., a use case is not a protocol spec. 

  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: Fri, 7 Aug 2009 16:33:41 +0200

Hi Stefano, 

> From: stefano previdi [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 2:43 PM
> To: Martin Stiemerling
> Cc: alto
> On Jul 28, 2009, at 2:37 PM, Martin Stiemerling wrote:
> 
> > Stefano,
> >
> >>
> > 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.

Section 4 is about path rating but not about "rating at the server" as you've described above and I was also referring to. Or I cannot find the part where it is defined.

  Martin

---

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 10 Aug 2009 10:31:47 +0200

Hi all,

I have the severe doubt that the integration of all existing ALTO protocol proposals into one protocol is a good idea at all, after spending some cycles on the P4P draft over the weekend.

The beauty of P4P seems to be (IMHO) that the server itself can calculate all information beforehand based on the PIDs. I.e., there is actually no calculation needed during the runtime, leaving the load on the server to serving the HTTP GET requests (we know how to handle this by today for a large request volume). 

However, there is a shift in protocol heaviness, by introducing the oracle approach to the protocol proposal. The oracle requires calculations during the runtime, i.e., the server needs to serve the requests and do extra cycles on calculating the guidance. The oracle also turns the argument of caching upside down, as the responses are not meaningful to caching anymore.

I would leave the P4P proposal without the oracle or is the goal to generate a protocol that can do all, but with too many caveats?

Thanks,

  Martin

[email-masked]

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Y. Richard Yang
> Sent: Tuesday, July 28, 2009 5:10 PM
> To: Martin Stiemerling
> Cc: alto
> 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
> 
> Martin Stiemerling wrote:
> > 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 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
> >
> 
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Obi Akonjang <[email-masked]>
Date: Mon, 10 Aug 2009 12:48:32 +0200

Hi Martin,

We do understand your concerns about the inclusion of the Oracle
approach in the currently merged ALTO proposal and would like to address
them the best we can.

First, though the approaches may differ, we're all trying to resolve a
common problem and do understand the need for a common protocol. We thus
decided to work with the other groups together to achieve this goal.

Second, the Oracle (likewise P4P) MUST NOT calculate all information
on-the-fly, since it uses and maintains a back-end database that gets
updated at pre-determined intervals or when adjusting to sudden
changes. 

Third, the Oracle's ranking approach does not need topology maps, which
immensely simplifies interactions between the server and potential
clients. This (IMHO) adds more weight to the protocol's heaviness.

It would be good if you could explain what you mean by the Oracle
turning the argument of caching upside down. We instead see lots of
potentials and common grounds between the Oracle approach and caches.

Hope this clarifies your concerns about the Oracle merge :-)

Kind regards,
Obi

---

From: stefano previdi <[email-masked]>
Date: Mon, 24 Aug 2009 11:58:33 +0200

Hi Martin,

<sorry for being late>

On Aug 7, 2009, at 4:33 PM, Martin Stiemerling wrote:
> Section 4 is about path rating but not about "rating at the server"  
> as you've described above and I was also referring to. Or I cannot  
> find the part where it is defined.

As Obi already explained on a separate email, the method for computing
path rating is not specified and can be either on-the-fly or through
pre-computation. We didn't put any detail on the computation itself as
we believe it is not in the scope of the protocol specification.

thanks.

s.

---

From: Ingmar Poese <[email-masked]>
Date: Tue, 25 Aug 2009 10:18:51 +0200

Hi Martin,

sorry for the late reply to this e-mail. I hope the original thoughts
are still present.
> However, there is a shift in protocol heaviness, by introducing the oracle approach to the protocol proposal. The oracle requires calculations during the runtime, i.e., the server needs to serve the requests and do extra cycles on calculating the guidance.
If i understand the proposal correctly, the additional load the Oracle
approach introduces is generated by the sorting of the candidates list.
Having this in mind, the scheme is actually very similar to the other
approaches, i.e. the cached lookup in the DB and socket Handling is the
same. Since sorting is a well known problem and can be done fairly fast
i don't see this as a huge overhead. But it introduces extra stress on
the server.
Furthermore, at least as far as i understand it, the sorting is not
introduced by the Oracle scheme, but by the ordinal ranking defined in
section 4.1.2 in the draft. My understanding of this section is to
introduce a possibility to "replace" the actual weights from the cache
by a numbered ordering in the reply. Since the lists of IP's/PID's
change with every request, the ordering will have to be done every time
a query comes in (there are special cases when this might not be
neccessary, but in general i think it is). The Oracle use-case is, in my
opinion, a special case of the ordinal ranking.

Cheers,
Ingmar

-- 
Ingmar Poese                             [email-masked]
TU Berlin / Deutsche Telekom Labs            
Sekr. TEL 4, FG INET                        www.net.t-labs.tu-berlin.de
Ernst-Reuter-Platz 7
10587 Berlin, Germany

---

From: "Damien Saucez" <[email-masked]>
Date: Tue, 25 Aug 2009 10:30:08 +0200

Ingmar,

>> However, there is a shift in protocol heaviness, by introducing the
>> oracle approach to the protocol proposal. The oracle requires
>> calculations during the runtime, i.e., the server needs to serve the
>> requests and do extra cycles on calculating the guidance.
If the sorting time becomes long, you can de activate sorting as the rank
value is in the answer, then, the client has to rank. We should document
this, except if the sorting of the answer is a MUST.

Regards,

Damien Saucez

---

From: Ingmar Poese <[email-masked]>
Date: Tue, 25 Aug 2009 14:18:59 +0200

> this, except if the sorting of the answer is a MUST.

If i understand the draft correct both cases *must* be implemented and
supported by the server - however, the section is not 100% clear on that
- so maybe we want to state that one of the two *must* be supported
instead of both.
Currently i am not seeing these queries getting really large, so the
sorting should not put a lot of stress on the server. A BitTorrent
tracker can just download the map and do it's own ranking, while for a
single client it might be too much overhead to download the map entirely
to do just a few rankings. Since clients will not query very often this
should not be a problem.
However, the Oracle approach is dependent on the ordinal query/answer
type to be present since it does not want to give out specific weights
(in the current state anyway). It just does ranking and *must* sort the
answer to remove the original weights.

Cheers,
Ingmar