Re: [alto] ALTO pipeline discussions

Qiao Xiang <xiangq27@gmail.com> Wed, 27 June 2018 06:21 UTC

Return-Path: <xiangq27@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F93130E80 for <alto@ietfa.amsl.com>; Tue, 26 Jun 2018 23:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level:
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2VYMPL2HAoI for <alto@ietfa.amsl.com>; Tue, 26 Jun 2018 23:21:11 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96DC130F36 for <alto@ietf.org>; Tue, 26 Jun 2018 23:21:09 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id t3-v6so2369456eds.3 for <alto@ietf.org>; Tue, 26 Jun 2018 23:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lKbhZLYt7n3zho/KzsXd64c8p/YMTj6yNocnvQMaABU=; b=UCIOObb0p/QDd4aLWwpOW+5zWIBoyg/0AeEVFU92s8TqYVpQ7Bxjgz/2RQVKvbRPiY qIL0aIO/ELV9lbkwwW7xquSzuILhIMwbcRT5Pa89rp4hs7SHbZ0kaSvOOqLSvORiOb62 8M+9O/MA3x4I/z5RJ1ZH0wIBO5tA4Lu9SDqgxQm9+fLjbLjdC1mHl2rMRVRPc5lso57H kszLdXwvFS/Dhp4tbs1JPB+0YCmaMMTUnfm4qE6VL+y+3dJ8v1XWxE492oc2qqi0yeb6 raZdF3BATKXSSUlGyhrNmlQFPyynBOCe3+EqBw2oTEsR5jVEcHbfuH+sVtUtJe7xGpEc dweg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lKbhZLYt7n3zho/KzsXd64c8p/YMTj6yNocnvQMaABU=; b=A6MLgywdKTpNo/5QckBnU+/pzA0LoAUTxODfpcqCzigkqeef1oHg508qYRn3mCtfQd ssd0e9uvfgsjn2f4bZw9YU5edUWtpRidEc0qjMSffS5R1m9/k4mK2xOXB7uB3PKvQADr 2Kf/7Dmsqs9GwjCmUCV/Kl0y1UpCymrgPwxceUIOJ5MgSbmueeUXQF7q1CjTl6zhxEf3 4gkPHsr5D6Nv56g1iNmakmbOZac3WqjhjRW9gz6rAniPD9m3F0vzQG8d+FFGS43w3Hb5 0FsStQ77yGGzGU0XT7x1bW06gR2iPiFZxACXmeQaDULJEcnlk1uf/AfmrBcoDR/c9OM5 b+AA==
X-Gm-Message-State: APt69E2OF+qAz7DWd+IRoj3GohgS6E4GlUX/yhnj3UtOX59V5Ian+Gf8 PIstxHZQlOIcJ5jW1R4Obd3ruCiVwJW3D2Yd2kcr+Hgw
X-Google-Smtp-Source: AAOMgpcznSQf1sij/Ye0BDApFo6xEYuvpzEOU11tXQmwMghR+WPclzQRNDvJ8RAkO+3GLauE+GwWfSGDhjnPGuk8inc=
X-Received: by 2002:a50:88c2:: with SMTP id d60-v6mr4233968edd.281.1530080468005; Tue, 26 Jun 2018 23:21:08 -0700 (PDT)
MIME-Version: 1.0
References: <805b9de78af146979f4036948c0859f8@DM5PR08MB2377.namprd08.prod.outlook.com>
In-Reply-To: <805b9de78af146979f4036948c0859f8@DM5PR08MB2377.namprd08.prod.outlook.com>
From: Qiao Xiang <xiangq27@gmail.com>
Date: Tue, 26 Jun 2018 23:20:55 -0700
Message-ID: <CAOB1xS8zN=iaQXBB4zwW3ZZiSz+FkMvyQTQ=2QjA3s5WzHXx=Q@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Cc: "Randriamasy, Sabine (Nokia - FR/Nozay)" <sabine.randriamasy@nokia-bell-labs.com>, Lyle.T.Bertz@sprint.com, Danny Alex Lachos Perez <dlachosper@gmail.com>, Chan Dawn <dawn_chen_f@hotmail.com>, Jensen Zhang <jensen@jensen-zhang.site>, Xiao Lin <x.shawn.lin@gmail.com>, Christian Esteve Rothenberg <chesteve@dca.fee.unicamp.br>, "Y. Richard Yang" <yry@cs.yale.edu>
Content-Type: multipart/mixed; boundary="000000000000c6416e056f999eb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/CSnAEuJN3-NcLV2sbhI2daE_9zw>
Subject: Re: [alto] ALTO pipeline discussions
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2018 06:21:17 -0000

Dear WG members,

As posted in Richard's earlier email, we want to discuss items that are not
working group documents but are of interests to the WG. This email is to
share my preliminary thoughts on two items: (1) How should ALTO information
be integrated/utilize in orchestration; and (2) Use mathematical
programming representation abstraction as unified resource representation.

The motivation for me to look into these items are (1) How to represent
resource sharing of flows with on-demand routing? and (2) How to represent
shared risk link group (SRLG) information of flows? Both these motivating
questions are raised during our earlier discussion with people from LNBL
and ESNet, one of the major use cases of ALTO. They are highly interested
in the linear inequality abstraction introduced in the ALTO path vector
draft.

My first design proposal is to use "generalized disjunctive programming"
(GDP) as the abstraction. GDP is an optimization modeling technique that
can encode not only linear/integer constraints, but logical propositions. I
believe it is a good candidate for unified resource representation in ALTO
because it is highly expressive and easy to interpret. I prepare a few
simple slides to illustrate the basic idea of my design, and will write
down the specs in a draft before the cut-off date. Meanwhile, it will be
greatly appreciated if you could share your comments or thoughts on this
design,

Thank you very much.


Best
Qiao

On Thu, Jun 21, 2018 at 9:58 PM Y. Richard Yang <yry@cs.yale.edu> wrote:

> Dear all,
>
> It is 24 days to the scheduled ALTO session, on July 16. After this
> weekend, it will be only 3 weeks. During the last couple of months, to
> better prepare for the coming IETF, some of us (Danny, Dawn, Lyle, Jensen,
> Sabine, Shawn, Qiao, Christian) looked at both the current state and the
> pipeline of ALTO.
>
> For the current-state part, Dawn/Danny/Shawn are doing a wonderful review
> of ALTO, on ALTO implementations, ALTO in related work. They will continue
> to lead the efforts.
>
> The objective of this email is to start a thread to discuss the pipeline
> aspect. We want to discuss items that are not working group documents but
> have interests. We may or may not have a chance to work on these items, but
> will definitely help to get the discussion started.
>
> At a high, rough level, we can classify ALTO pipeline into three
> categories, and in each category, we can identify several potential working
> items. At the end of this email is a list. We are hoping that we can have a
> good discussion on this before and during the coming IETF.
>
> Cheers,
> Richard, on behalf of Danny, Dawn, Lyle, Jensen, Sabine, Shawn, Qiao,
> Christian
>
>
>
>
>
>
>
>
>
>
>
> * - App use cases/requirements/architecture 1. A systematic study of how
> ALTO info be integrated/utilize in orchestration 1. One aspect ALTO + PCE,
> ABNO, Path-based, 2. Extension to new architectures (e.g., cellular, 5G)
> endpoint types 3. Extension to new settings such as multi-domain (ALTO is
> traditional design for App-Net, i.e., north-south interface, interdomain is
> more EW interface), SFC, NFV,  edge clouds - API/base protocol 1. A general
> multipart service, SSE -> HTTP/2 2. Flow cost service, extensible query
> schema for a set of flows, may including unicast and multicast, multipath,
> ... 3. Calendar for endpoint entity properties [Sabine] 4. Unified resource
> representation (e.g., mathematical programming representation abstraction,
> linear inq) - Backend/infrastructure 1. Smart/on-demand measurements (query
> miss trigger, start and collect measurements, formalize the protocol,
> connect to IPPM, accuracy/freshness, what kind of info to be provided) 2.
> Proxy architecture, for scale, interdomain, for fault tolerance, for
> security/privacy -- Qiao Xiang Postdoctoral Fellow, Department of Computer
> Science,Yale University*
>