Hi, Kiesel, thanks for your comments. For the first comment: 'Qos relay' could be executed when it is found the current QoS can't satisfy the service requirement. So, whether Qos relay will be applied or not depends on the Qos measurement result.It happens in both suddenly appearing failures/congestion and chronically congestion cases.
For the second comment: In figure 1, when the Qos of direct IP routing can't meet the service requirement, AS B was selected as the relay AS based on the Qos measurement. While AS B needn't to know the detailed traffic information. Here we give two method of the relay candidate selection in chapter 3.One is "integrating relay service into alto service", relay node is elected by ALTO Server in this method. The other is "cooperation between P2P application provider and ISP", ALTO Server just supply the necessary information to the p2p application provider for the relay node election. I think both of these two methods is necessary to be discussed now and I'd like to hear which method do you prefer. Best Regard, Yu Meng Sebastian Kiesel <[email protected]> 2009-09-29 21:19 收件人 [email protected] 抄送 [email protected] 主题 Re: [alto] New draft on relay usage for ALTO Hi Yu Meng, On Tue, Aug 25, 2009 at 10:24:08AM +0800, [email protected] wrote: > Hi, > We have submitted a draft on relay usage for ALTO. This document would > describe the background of Qos relay and design the mechanism of combining > ALTO service with relay. > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-meng-alto-relay-00.txt. Comments > welcome. Your draft mentions two use cases: the first is the "Connectivity relay" to connect users with limited Internet access (NAT). I fully agree with that use case and I think that ALTO should be able to assist in selecting an "optimal" (in the sense of ALTO) connectivity relay. However, I am very concerned about the second use case, on which your document focuses: the "QoS relay". With the goal of lower latencies you are proposing an Application Layer-routing/forwarding mechanism that diverts traffic from the path along which normal IP routing would send the packets: | Under the following two conditions, overlay | routing paths can be faster than the direct IP routing paths | (1) An AS in a direct routing path is congested or failed. Can you please explain which timescales we are talking about? Do you want an ALTO-based solution to reroute around suddenly appearing failures/congestion faster than the IP routing protocols can do? Or is it all about routing around chronically congested links, which are known to the operators to be congested but which they do not want to upgrade for some reason? | (2) Multi-homed customer ASes can further improve overlay routing. If we look at Figure 1 of your draft, can you please explain how the owner of the AS B can publish what kind of transit traffic he is willing to relay through a "QoS relay" in his multi-homed stub AS (if he wanted to relay all kinds of IP traffic, AS B could just become a transit AS on BGP level)? Should this policy-aware detection of candidate relays be part of ALTO? Thanks, Sebastian -- Sebastian Kiesel mailto:[email protected] 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
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
