Re: [altoext] i2aex BOF - Large Bandwidth Use Case

Young Lee <younglee.tx@gmail.com> Sun, 25 March 2012 04:53 UTC

Return-Path: <younglee.tx@gmail.com>
X-Original-To: altoext@ietfa.amsl.com
Delivered-To: altoext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70CE21F8503; Sat, 24 Mar 2012 21:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.315
X-Spam-Level:
X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vN7N-t4UPEO; Sat, 24 Mar 2012 21:53:22 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFFFA21F8501; Sat, 24 Mar 2012 21:53:21 -0700 (PDT)
Received: by lagj5 with SMTP id j5so3604164lag.31 for <multiple recipients>; Sat, 24 Mar 2012 21:53:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9cp2QFUPLF0vUKsXuAq7n9leAPGDFU6kEZ2Wv1n02Dw=; b=JTvFjYnzNQTYBXSvHK/T/fWQcEn4Py4R3TeiYphdXAlb1a5jT6Eex4kTbjWW2hmh18 5LkjACQX+VUoJocAsV8dNLoZ3gN8UjwlDuDHPZfIUT50jtzLzutenE3LMR/xfnKZJMgn +i9pjNrG5ASHeSWplZ1jKZTKZrligy1Ura5zCvwgEpMqvlbucW4O7LqzhmkCGVii93Bu j6PL+c88WUdBYdr/5Sj9t8Fxt1sEurcI6pFTKfMPdJqtVUFBn7Mu9r13Hb7ZOfgRil+E kOUzLaWISpbQNj42L2PVwvqfRJuEfzOfaWIbu3iIqMymK1tDQXoqb5aWha1j+2PexqHu Uznw==
MIME-Version: 1.0
Received: by 10.112.42.7 with SMTP id j7mr6207000lbl.75.1332651200513; Sat, 24 Mar 2012 21:53:20 -0700 (PDT)
Received: by 10.112.24.1 with HTTP; Sat, 24 Mar 2012 21:53:20 -0700 (PDT)
Received: by 10.112.24.1 with HTTP; Sat, 24 Mar 2012 21:53:20 -0700 (PDT)
In-Reply-To: <2C0E90B7-4B30-45F4-A7B0-1887E8654A66@cs.yale.edu>
References: <7AEB3D6833318045B4AE71C2C87E8E1720C8E5DC@dfweml511-mbx.china.huawei.com> <2C0E90B7-4B30-45F4-A7B0-1887E8654A66@cs.yale.edu>
Date: Sat, 24 Mar 2012 23:53:20 -0500
Message-ID: <CAGHSPWN1HkXTHD0zqryoOuKxM8j+6vctDhL1ceBzQdKmavsmqg@mail.gmail.com>
From: Young Lee <younglee.tx@gmail.com>
To: "Y. R. Yang" <yry@cs.yale.edu>
Content-Type: multipart/alternative; boundary="e0cb4efa6e366a898504bc0a09d2"
Cc: "altoext@ietf.org" <altoext@ietf.org>, Enrico Marocco <enrico.marocco@telecomitalia.it>, Greg Bernstein <gregb@grotto-networking.com>, Spencer Dawkins <spencer@wonderhamster.org>, "alto@ietf.org" <alto@ietf.org>, Leeyoung <leeyoung@huawei.com>, DIEGO LOPEZ GARCIA <diego@tid.es>, "Vijay K. Gurbani" <vkg@bell-labs.com>
Subject: Re: [altoext] i2aex BOF - Large Bandwidth Use Case
X-BeenThere: altoext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Non-WG list for discussions related to ALTO Protocol Extensions <altoext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/altoext>, <mailto:altoext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/altoext>
List-Post: <mailto:altoext@ietf.org>
List-Help: <mailto:altoext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/altoext>, <mailto:altoext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Mar 2012 04:53:23 -0000

Hi Richard

Thanks for your great comment. I think you hit the right issue. I agree
with you. The ppt slides did not make it clear but our intention was to
suggest a graph representation to "complement" the bgp fashioned cost map.
As you indicated, neither the bgp fashioned cost map alone nor graph
representation alone will satisfy the requirements necessary for the
applications with assured service quality.

We can discuss this issue on Monday. Thanks.

Young
On Mar 24, 2012 6:22 PM, "Y. R. Yang" <yry@cs.yale.edu> wrote:

> Hi Young,
>
> Very nice deck of slides with some very interesting use cases!
>
> A quick comment/question on using approximate graphs to address the
> interesting issues of shared bottlenecks that may not be exposed by e2e
> links. In a dynamic, interactive constraint solving/joint optimization
> setting, such internal coupling will show up as "cost" increase on one
> source-dest pair, when using another independent pair.
>
> But your use case does show another way to expose infrastructure info. We
> consider the use case that the path for a source, destination pair is
> computed by the infrastructure, not by the app (otherwise, it is a
> different story). Then one issue of exposing only a graph is ambiguity for
> an app to determine the path for a source, destination pair, unless the
> underlying graph has no loop, since then the computed path then will depend
> on the policy of the infrastructure. For example, consider a graph, where
> each s1, s2, rs, r1, r2, rd, d1, d2 is a pid, si is source ER, and di is
> destination ER in your example:
>
> s1 -> rs
> s2 -> rs
> rs -> r1
> rs -> r2
> r1 -> rd
> r2 -> rd
> rd -> d1
> rd -> d2
>
> Then the app may not be able to figure out the path for s1 to d1, or s2 to
> d2.
>
> One possibility is to expose the node path in a "cost" map, where the
> value of each entry is a (bgp style) path vector, in addition to a graph
> topology map. I get a feeling that others may have better, more compact
> representation, but the preceding seems simple.  What do you think?
>
> Thanks!
>
> Richard
>
> On Mar 23, 2012, at 1:40 PM, Leeyoung <leeyoung@huawei.com> wrote:
>
> > WARNING: contains banned part
> > This message cannot be displayed because of the way it is formatted. Ask
> the sender to send it again using a different format or email program.
> multipart/mixed
> > _______________________________________________
> > altoext mailing list
> > altoext@ietf.org
> > https://www.ietf.org/mailman/listinfo/altoext
> _______________________________________________
> altoext mailing list
> altoext@ietf.org
> https://www.ietf.org/mailman/listinfo/altoext
>