Re: [alto] 答复: Re: New draft on relay usage for ALTO

[Tao Ma <abcdmatao at gmail.com>]

Hi, 
   Some comments inline.
Tao Ma
Beijing University of Posts and Telecommunications,Mobile lIfe and New mEdia(MINE) Lab

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?

RE: I think relay is a method of overlay routing which has the function of bypassing some congested IP path. IP routing can recover from failure too. But overlay routing cares more about the application metric. Their understanding of failure or congestion might be different. For example, for VOIP application which has stringent delay requirements, IP rerouting mechanism can’t detect some paths that are actually congested in the view of the application requirements. In ALTO-based solution, overlay rerouting might be complementary for IP rerouting especially for some QoS requirements. 

| (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?

RE: In ALTO-based solution, relay is application relay. As long as there are “QoS relay” in AS B, an overlay path which traverses AS B can be established, which needs no modification on BGP level. In other words, this solution can be seen as policy unaware, for it doesn’t care about IP routing policy.  

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