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

From: [email-masked]
Date: Sat, 10 Oct 2009 15:56:22 +0900

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-masked]> 
2009-09-29 21:19

收件人
[email-masked]
抄送
[email-masked]
主题
Re: [alto] New draft on relay usage for ALTO

Hi Yu Meng,

On Tue, Aug 25, 2009 at 10:24:08AM +0800, [email-masked] 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-masked]
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

---

From: Tao Ma <[email-masked]>
Date: Sun, 11 Oct 2009 14:09:19 +0800

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

> 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.

> BGP level)?  Should this policy-aware detection of candidate relays be
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.

> NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 Heidelberg, Germany
> --

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 12 Oct 2009 12:17:30 +0200

Hi,

On Sun, Oct 11, 2009 at 05:10:13PM +0800, miao xiong wrote:
> >> mechanism can't detect some paths that are actually congested in the view of
> > To be added, there actually exists interaction between overlay routing and
> > IP routing. In my opinion, the interaction of them, especially for the
> > rerouting of failure recovery, needs further research and discussion.

Exactly this is my concern.

ALTO for initially selecting one of several equivalent resource
providers (i.e., application protocol endpoints that can do stuff far
beyond the functions of an IP router) complements IP routing (obviously
with dependencies).

In contrast, using relays (which do basically packet forwarding on
another layer in the protocol stack) to divert packets from the "normal"
path really duplicates functions of IP routing. I fear that in the
latter case there is much more danger of undesired layer interaction
than in the first one.

> Numerous studies have reported the existence of triangle inequality
> violations (TIV) in the Internet delay space??for about10%-30%??. It has
> been proved to be a stable phenomenon in the Internet, and it is due
> to the flaw of IP routing protocol. Since it is impossible to modify
> the existing IP protocol, using QoS relay will be a complement to IP
> routing.

Do you have more information (e.g., references to papers/studies) about 
the true reasons for TIV? Are they due to

1) Non-technical, deliberate decisions of the network operators (e.g.,
   no business case for upgrading a line)?

2) Technical limitations of the IP routing protocols (BGP, OSPF, etc.)?

3) Technical limitations of the IP protocol itself (IPv4)?

or ...

Maybe also some people working for an operator can comment on this?

Thanks,

   Sebastian

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 12 Oct 2009 14:38:43 +0200

> Maybe also some people working for an operator can comment on this?

As far as I can tell, TIVs are intrinsically related to the very nature
of the Internet -- path asymmetry, route load balancing and so on -- and
at the end of they could be hardly considered a problem. However,
problem or non-problem, they entirely belong to the routing layer and
addressing them at the application level makes to me for a perfect
example of layer violation.

-- 
Ciao,
Enrico

---

From: Tao Ma <[email-masked]>
Date: Wed, 14 Oct 2009 11:29:24 +0800

Hi,
   For your first concern, using ALTO to guide the path selection really has
the danger of interaction with IP layer routing. This question is a key
issue of this solution. Till now, in my opinion, the difference of time
scale(faster than IP like RON) or concern(application Qos vs. connectivity)
between overlay and IP layer might be the possible motivation of this
solution.
   For the second concern, about Triangle Inequality Violation(TIV), I have
two papers,http://www.cl.cam.ac.uk/~ekl25/p53CameraReady.pdf and
http://www.imconf.net/imc-2007/papers/imc145.pdf which focuses on the reason
caused by policy. Hope it might be helpful. Can any other add some other
references or knowledge about this. Thanks:)
Tao Ma
Beijing University of Posts and Telecommunication, Mobile lIfe and New
mEdia(MINE) Lab

2009/10/12 Sebastian Kiesel <[email-masked]>

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 27 Oct 2009 12:23:27 +0100

lichun li wrote:
> Indeed, TIVs should be addressed in routing layer. However, solving
> the problem in routing layer may involve things like changing routing
> protocol and replacing routers, which will pay some time and high
> price. In contrary, relay is an easier solution for applications
> sensitive to delay, and is already used somewhere.

I'm sorry you lost me here. TIVs are the result of routing policies, I
don't think there's anything wrong with current routing protocols, at
least not in a way that significantly influences TIVs.

> Relay can cause layer violation. Operators may not like it. But
> operator's participating in relay selection may reduce the harm of
> layer violation.

If a routing policy makes traffic flow from AS A to AS B on a slow yet
capable direct link instead of rerouting it through a fast connected AS
C, well, I'm pretty sure that policy entirely reflects the operator's
will. If they were actually interested in making traffic follow
different paths, they'd just need to reconfigure the routers without
recurring to application level relay (that, BTW, basically doubles
bandwidth costs) and relay selection.

-- 
Ciao,
Enrico

---

From: lichun li <[email-masked]>
Date: Tue, 27 Oct 2009 18:41:26 +0800

[Sorry to resend this mail. Something was wrong. Former mail is not
listed in alto Archives, and some people can't get the former mail.]

Just my two cents.

On Mon, Oct 12, 2009 at 8:38 PM, Enrico Marocco
<[email-masked]> wrote:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>

-- 
Sincerely yours,

Lichun Li
ZTE Corporation

---

From: lichun li <[email-masked]>
Date: Tue, 27 Oct 2009 21:59:30 +0800

I understand. Routing policy can result in TIVs, if the policy
considers factors other than latency.
I think the technical limitation could be the reason of TIVs too.
Resolving TIVs caused by technical reasons in IP layer may be hard,
but resolving with relay is easier.

Take AS routing as an example. Suppose both AS B and AS C can route
traffic from AS A to AS D. AS B charges a higher price for routing
traffic, but routing through AS B is fast. Suppose AS A's operator's
will is: a flow to AS D should route through AS C (slow but cheap) if
QOS meets the application's requirement, otherwise route through AS B
(fast but expensive). If using routing policy only, out-bound router
must sense the exact QOS requirement of every traffic flow and the
latency of AS path. So only configuring routing policy at IP layer may
not fulfill the will of operator entirely. Both routing policy and
relay should be used to fulfill operator's will.

-- 
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 27 Oct 2009 17:43:36 +0100

> but resolving with relay is easier.

Could you provide examples of such routing layer limitations that would
be best addressed at the application layer?

> relay should be used to fulfill operator's will.

I would say that's what RSVP was invented for. In which way do you think
a solution based on application-level relays would work better?

-- 
Ciao,
Enrico

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 27 Oct 2009 20:11:24 +0100

> a solution based on application-level relays would work better?

Woops, of course I meant DiffServ, sorry. It may have been a Freudian
slip though ;)

-- 
Ciao,
Enrico

---

From: [email-masked]
Date: Wed, 28 Oct 2009 09:18:13 +0800

Maybe this is not a good example.
In my opinion, there are two possible reasons to use QoS relay.
1 Due to the technical limitation of IP layer QoS, P2P users have to use 
relay.
2 Due to non-technical reasons like the cost of implementing IP layer QoS 
solution, IP layer QoS can not meet the requirement of P2P users. So P2P 
users have to use relay wether the operator likes it or not.

I am not very familar with the IP layer QoS. I not sure about reason 1.

Anyway, no matter what reason, QoS relay exists.

-- 
Kind regards

Lichun Li
ZTE Corporation

Enrico Marocco <[email-masked]> 
发件人:  [email-masked]
2009-10-28 00:43

收件人
lichun li <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [alto] ????: Re: New draft on relay usage for ALTO

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 28 Oct 2009 09:20:50 +0100

> Anyway, no matter what reason, QoS relay exists.

Can you please give a specific example where this exists?

Thanks,
Sebastian