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 <sebastian.kiesel at nw.neclab.eu>
2009-09-29 21:19
收件人
meng.yu at zte.com.cn
抄送
alto at ietf.org
主题
Re: [alto] New draft on relay usage
for ALTO
Hi Yu Meng,
On Tue, Aug 25, 2009 at 10:24:08AM +0800, meng.yu at zte.com.cn 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:sebastian.kiesel at nw.neclab.eu
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