Re: [alto] Design issue on path vector

Dawn Chan <dawn_chen_f@hotmail.com> Fri, 24 March 2017 17:51 UTC

Return-Path: <dawn_chen_f@hotmail.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 AC81A12984A; Fri, 24 Mar 2017 10:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.126
X-Spam-Level:
X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 t6kf9YJlARlU; Fri, 24 Mar 2017 10:51:30 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253063.outbound.protection.outlook.com [40.92.253.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF0312956A; Fri, 24 Mar 2017 10:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DdZcPqTheDvoWrWF+J97+eYvjuE39APRcjz5gfruqr0=; b=VitQXOK5DdumPCgbOVcQAnLzwgI9oK3QAIAEC9oYqkIPVP0b0cgHpzdM3X876HcxL1Y8Lrg+0xN/2UwDuHESKPk1QRHhemcBtIjOVM43uy78PtQZ71ib/w8e7DJPxuwKCe5EJHM6hkzD1Q2QcSkZI49BkHxkODSNhj2u7WOVYjzWD1w/06tsPICIfF4S9/LX0i4qv2IsNbfMAt3qGcR0kn+Qa5G3f1lJjHFeGc6qODhJt1fzIRouKn1VJM2XSYIXc7fgCB7OtDgDItSw9BYiLBp7C8U8Ibrnsctn/i+/BNwXdmV1l1oNRXrhhR1fHvR0UBZU3Yp+tO3Wlg6VNHGo6g==
Received: from HK2APC01FT031.eop-APC01.prod.protection.outlook.com (10.152.248.58) by HK2APC01HT028.eop-APC01.prod.protection.outlook.com (10.152.249.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7; Fri, 24 Mar 2017 17:51:26 +0000
Received: from TY1PR04MB0656.apcprd04.prod.outlook.com (10.152.248.55) by HK2APC01FT031.mail.protection.outlook.com (10.152.248.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7 via Frontend Transport; Fri, 24 Mar 2017 17:51:25 +0000
Received: from TY1PR04MB0656.apcprd04.prod.outlook.com ([10.163.246.157]) by TY1PR04MB0656.apcprd04.prod.outlook.com ([10.163.246.157]) with mapi id 15.01.0977.021; Fri, 24 Mar 2017 17:51:25 +0000
From: Dawn Chan <dawn_chen_f@hotmail.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>, "jingxuan.n.zhang@gmail.com" <jingxuan.n.zhang@gmail.com>
CC: "alto@ietf.org" <alto@ietf.org>, "draft-yang-alto-path-vector@ietf.org" <draft-yang-alto-path-vector@ietf.org>, "sabine.randriamasy@nokia-bell-labs.com" <sabine.randriamasy@nokia-bell-labs.com>, "wendy@wdroome.com" <wendy@wdroome.com>
Thread-Topic: Design issue on path vector
Thread-Index: AQHSomRF1IdmzCY0/0OSyGBvWoXSaqGhQtmAgADESYCAASEjgIAAv7oAgADj5QD//33DgA==
Date: Fri, 24 Mar 2017 17:51:25 +0000
Message-ID: <TY1PR04MB0656505E4B662342BBA38474B53E0@TY1PR04MB0656.apcprd04.prod.outlook.com>
References: <TY1PR04MB065600AD703BAEC14FC7D27DB53D0@TY1PR04MB0656.apcprd04.prod.outlook.com> <CANUuoLoQa-HhQcdKma5+6iUwY7-oXBoqt02OntU6ym-mM+LFcQ@mail.gmail.com> <CAAbpuyo7x2q=B3FU6kdm8mckg744n=dLYmgJaeUfnaHLCnLzzA@mail.gmail.com> <CANUuoLqXUkxjoKr-8Cqw+67vGn4KvLiMMKYQ7OvUsm0BcF3QMw@mail.gmail.com> <TY1PR04MB06567D69F38FAE63B6B35160B53E0@TY1PR04MB0656.apcprd04.prod.outlook.com> <DC8A0ADC-EB21-4BC1-A690-1405333E6DF8@hotmail.com>
In-Reply-To: <DC8A0ADC-EB21-4BC1-A690-1405333E6DF8@hotmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:65E5270D8098C2D5620AB150C7D0BC2A2746C664E1D3C9AC3A4B79296F504CFC; UpperCasedChecksum:6F71E40DCF8A34CEB0E207AE1B43627D7E89C896D13810EB55B17069C3466E5A; SizeAsReceived:8599; Count:40
x-ms-exchange-messagesentrepresentingtype: 1
x-microsoft-exchange-diagnostics: 1; HK2APC01HT028; 5:4wm11yTzWZHcOlD2TRxCy89uIA62uNoQFTLSFM/SCMlZzH5YLSX8ByyaYFNotkRsm2aKtrK9sAxHMX6hCWvDS2ZBoi8x8MSCe0F68FWXOiKNUVDuoQu2/acSY05n9VoG1SqG+M+y4q6IY1YL0wFt/A==; 24:MsY0zYYP9PGedoEZk7W5jN+VaUbJFVpC1aH3qKCdsenHe+K8f8glL+f9BCuRZYV3fsOeA6Zvp/FopQRWNrtgLtL7ciI4y1zgMzA2bBO8Vak=; 7:pVzsYqur/XoHcu7p4OABppwxubyFnqxI0jMN49UaexK8S4Eojqv44uUQe3jqVvkc7afjgCRi++s7U7DGNKM3vdlsR24+Xfp2I/ZO2W+pGrQpnIM5JyMyphs9QUtYpGdlgnfEyow5S9bjwnoLxyleR72RQzCTGrbkpcQb3yLQQPQfiijwrm2MhLbYbK0UPJ7VluKec9eWPwspulNUDxJZJ8yqnUoYeWRC5FDdlPdfSSy+zfyf9CsJCq2D9HVbV2fLj/5aEqA4pZR1E3LfcdcbvTQIiSmB178t+SqxgMoHWZry3feK0PhNHC45do/lf7b1
x-incomingheadercount: 40
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98900017); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT028; H:TY1PR04MB0656.apcprd04.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: a67ea8b8-344d-4656-1a89-08d472de624d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1603101448)(1601125374)(1701031045); SRVR:HK2APC01HT028;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HK2APC01HT028; BCL:0; PCL:0; RULEID:; SRVR:HK2APC01HT028;
x-forefront-prvs: 0256C18696
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_TY1PR04MB0656505E4B662342BBA38474B53E0TY1PR04MB0656apcp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 17:51:25.3856 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT028
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/riBW9WAMltc0akEVCMHb7MpGvQE>
Subject: Re: [alto] Design issue on path vector
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 24 Mar 2017 17:51:33 -0000

Hi Richard, Jensen and all,

Thanks for your discussion. I think I have a simple enough design now. Please see below.

The major argument seems to be how to provide the network element properties.

We have discussed both inline and separate (reference) design since IETF 96. I will recommend to use separate design. Let me explain the reason.

Although the inline design seems to be simpler, yet it cannot solve the following problem: How to inform the client which property types will be provided? The cost map resource has to provide such information in its IRD entry. Because of the semantics of cost-mode and cost-metric, it is nonsense to provide such information in the cost-type. So IRD has to provide a “cost-type-specific” attribute to provide such information. It is not a good idea.

How about the separate design? If we separate the graph information into pv-cost-map and ane-prop-map, the property types can be declared by the IRD entry of ane-prop-map. But we have to introduce some extra complexities:

Requirement 1: The dependent relationship has to be indicated explicitly.
Requirement 2: The response of ane-prop-map has to be query specific.

For requirement 1, I propose to declare the pv-cost-map as the dependent resource of the ane-prop-map. It is reasonable. Because the network elements are computed when the client queries the pv-cost-map. In other words, the generation of the ane-prop-map is caused by the query of the pv-cost-map. Another potential benefit is that the server can provide pv and other cost-types in the same cost-map.

For requirement 2, I think it can be proposed as a generic requirement: The responses of several resources can be associated with the same query.

Let’s see the general scheme of the ALTO service response:

object {
  [ResponseMeta meta;]
  ResponseData   network-map | cost-map | endpoint-cost-map | property-map;
} Response;

In our case, we can think pv-cost-map. ResponseData and ane-prop-map. ResponseData are generated at the same time when the server receives a request of pv-cost-map. So both ResponseDatas should be associated with the same query. Let’s specify the query as a “query-id” information. A reasonable workflow should be the following:

1. The client sends a request to the pv-cost-map.
2. The pv-cost-map returns the response with a “query-id” information.
3. The client sends a request with this “query-id” information to the ane-prop-map.
4. The ane-prop-map returns the response with the dependency of the pv-cost-map response with the same “query-id” information.

The following is an example of the IRD:

“pv-cost-map": {
      "uri": "http://alto.example.com/costmap/multi/filtered",
      "media-type": "application/alto-costmap+json",
      "accepts": "application/alto-costmapfilter+json",
      "uses": ["default-network-map"],
      "capabilities": {
        "cost-type-names": ["pv-ane", "num-routingcost", "num-hopcount"],
        "cost-constraints": true
      }
},
"default-nep-map": {
    "uri": "http://alto.example.com/propmap/nepmap/default",
    "media-type": "application/alto-propmap+json",
    "accepts": "application/alto-propmapfilter+json",
    "uses ": ["filtered-multi-cost-map”],
    "capabilities": {
        "domain-types": ["ane"],
        "prop-types": ["availbw"],
        "query-specific": true
    }
}

Below is an example of pv-cost-map request and response.

pv-cost-map request:
{
    "cost-type": {
        "cost-mode": "path-vector",
        "cost-metric": "ane",
    },
    "pids": {
      "srcs": ["PID1", "PID3"],
      "dsts": ["PID2", "PID4"]
    }
}

pv-cost-map response:
{
    "meta": {
        "vtag": [{"resource-id":"filtered-multi-cost-map",
                      "tag": "<sha256>",
                      "query-id": “query_0”}], // Means this response is associated with query_0.
      "dependent-vtags": [
        {"resource-id": "default-network-map",
         "tag": "<sha256>"},
      ],
      "cost-type": {
        "cost-mode": "path-vector",
        "cost-metric": "ane",
      },
    },
    "cost-map": {
      "PID1": {"PID2": ["ane:L01", "ane:L02"],
               "PID4": ["ane:L01", "ane:L03"]},
      "PID3": {"PID2": ["ane:L04", "ane:L02"],
               "PID4": ["ane:L05", "ane:L03"]}
    }
}

In the pv-cost-map response, “vtag” is extended. A new attribute “query-id” is added into VersionTag.

Next is an example of ane-prop-map request and response.

ane-prop-map Request:

{
    "query-id": “query_0”,
    "entities":["ane:L01","ane:L02","ane:L03","ane:L04","ane:L05"],
    "properties":["availbw”]
}

The query format of property map is extended, a new field “query-id” is to uniquely identify different network elements in different queries. Since one FCM or ECS query will update the ane-prop-map, so, the “query-id” in the request body of a ane-prop-map is the same as “query-id” in the response body of the corresponding FCM or ECS.

ane-prop-map Response:

{
    "meta": {
      "dependent-vtags": [
        {"resource-id": "default-nep-map",
         "tag":"<sha256>”,
         “query-id”:”query_0”
        },
      ],
    },
    "property-map": {
      "ane:L01": {"availbw": "30"},
      "ane:L02": {"availbw": "40"},
      "ane:L03": {"availbw": "50"},
      "ane:L04": {"availbw": "40"},
      "ane:L05": {"availbw": "70"}
    }
}

The “query-id” here is the same as the “query-id” in FCM response and nep-map resource mentioned above. And their value must be the same.

Any comments on this design?

Best Regards,
Dawn