Re: [alto] Review of draft-ietf-alto-cost-calendar-02

"Randriamasy, Sabine (Nokia - FR/Nozay)" <sabine.randriamasy@nokia-bell-labs.com> Thu, 20 July 2017 09:41 UTC

Return-Path: <sabine.randriamasy@nokia-bell-labs.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 1AB21131BFF; Thu, 20 Jul 2017 02:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 PLtCN0AccC3X; Thu, 20 Jul 2017 02:41:42 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0139.outbound.protection.outlook.com [104.47.0.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307CC131A5F; Thu, 20 Jul 2017 02:41:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XI6epop8kGGF4r7URGGqn/HLuRWZGSFaDIZx5oBNwj4=; b=Cc1BjAumfD+i3fj98VeXE46DbqbxvltQLhD1RzIkvNPpCTdlBmjTveE1/98InqyNhfDVvrz8AJk1tAKuLS46LGsZkIRp/fYApkhwlz7PeFhJfS3I4+WGWJ6GJhi0G+mb01U/frj7aLNo+7ULC39baTEtbVVe0CItVmcNsqIGtiE=
Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com (10.168.75.147) by DB6PR0701MB2216.eurprd07.prod.outlook.com (10.168.58.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 09:41:24 +0000
Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com ([fe80::79f9:96c:a3c5:3ecc]) by DB6PR0701MB2454.eurprd07.prod.outlook.com ([fe80::79f9:96c:a3c5:3ecc%17]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 09:41:24 +0000
From: "Randriamasy, Sabine (Nokia - FR/Nozay)" <sabine.randriamasy@nokia-bell-labs.com>
To: Dawn Chan <dawn_chen_f@hotmail.com>, "draft-ietf-alto-cost-calendar@ietf.org" <draft-ietf-alto-cost-calendar@ietf.org>
CC: "alto@ietf.org" <alto@ietf.org>
Thread-Topic: Review of draft-ietf-alto-cost-calendar-02
Thread-Index: AQHS+uoC6HcZZaTHrEWxQs4PEvw97aJcf9Rw
Date: Thu, 20 Jul 2017 09:41:23 +0000
Message-ID: <DB6PR0701MB2454E1A5CBC41AE58ABFD48495A70@DB6PR0701MB2454.eurprd07.prod.outlook.com>
References: <HK2PR0401MB1588529A627653EF6F4A15EFB5AF0@HK2PR0401MB1588.apcprd04.prod.outlook.com>
In-Reply-To: <HK2PR0401MB1588529A627653EF6F4A15EFB5AF0@HK2PR0401MB1588.apcprd04.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: hotmail.com; dkim=none (message not signed) header.d=none;hotmail.com; dmarc=none action=none header.from=nokia-bell-labs.com;
x-originating-ip: [31.133.143.87]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2216; 7:6P6Qdn7XgvDLf6ndWiH0DxmiwDiFl/uRZXElLFvqxQ4gNwv4UuKuMSPlUI8k1evjxnFpP5+U2+ySPMq02b/Ger/L9b4BUfjdIjlBUfr+V5Ra9Q3UFsalYDHk1MsoI0OLmjIsiAyE6uyFMDL5h9MUQQ8CemBd/m9thPLv6aJziNjPwxZTVc67YKwmLySeha+XydGw4yjucCxEGU1muEiz1CDZS03cb1hKfHQjvkwTWUMWIq1qhP9TTmHBbTqcuXKesrtW7hsQipuY5ctpvwH7k19O0SsiAzPXeX2x4hfAUNaZHYYRdltuu16JZtApXa2bqsZ9uKL+YjF9s2d9u8ThbUXF5hK1ZCtsA6fh0n7/EPXfde4Dx6UX9zq8ooqo2B6/5/R2zSoUJBdXt+0DKuK+E/Jp3zlijn713PZueRj6jcAsRJaGe8WY0q5jypPp8gbjaWNN64LS7c+nSZyz5p7Qahb34EOJ1FmQqvsokXago54CRGcJO3dqzACKrWymve+zqsln8Hbxu5Z5gEIn+v/frTdT1xAcLzHoL2DOjg0aFcPi86kiCszLlodNrbUj/DmBUkPclyV5uJmzVlkmNW0BqiPBkh2INkt5jon9G/uM2Qpa54kMFojjrv+I1gKESQrUqrXCwUpcIUHWfxP6jSZpnFeAfCzg4ZVifTDNz1jXHq/vogt5pImisVlCA1UVzawCf+JGM78lXNW+vStc6eDN+B4bhQxZ1O4LVKCZRccCnvuVKH2T/WE+ZAUVmJkCmTm5ySp3JBImnv4cD/b5Y1uUnv3gMWZFQTIMmXftUaFDBcQ=
x-ms-office365-filtering-correlation-id: d4d831d1-2868-447d-2edf-08d4cf537c5f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB2216;
x-ms-traffictypediagnostic: DB6PR0701MB2216:
x-exchange-antispam-report-test: UriScan:(151999592597050)(158342451672863)(26388249023172)(236129657087228)(48057245064654)(148574349560750)(194151415913766)(21748063052155)(247924648384137);
x-microsoft-antispam-prvs: <DB6PR0701MB22162760C876BB66EBE3510195A70@DB6PR0701MB2216.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201703031522075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2216; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2216;
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39860400002)(39450400003)(39850400002)(39840400002)(39400400002)(377454003)(54896002)(236005)(53546010)(9686003)(33656002)(229853002)(55016002)(99286003)(2906002)(39060400002)(6246003)(66066001)(38730400002)(86362001)(606006)(14454004)(2950100002)(3660700001)(8936002)(3280700002)(6436002)(7696004)(478600001)(25786009)(5250100002)(2501003)(6306002)(5660300001)(4326008)(76176999)(50986999)(54356999)(2900100001)(81166006)(230783001)(8676002)(74316002)(6506006)(53936002)(189998001)(45080400002)(7736002)(790700001)(102836003)(3846002)(6116002)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2216; H:DB6PR0701MB2454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR0701MB2454E1A5CBC41AE58ABFD48495A70DB6PR0701MB2454_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 09:41:24.0211 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2216
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/oEfx_0Eg2kIG3eR-V8dRn-kL8pc>
Subject: Re: [alto] Review of draft-ietf-alto-cost-calendar-02
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: Thu, 20 Jul 2017 09:41:45 -0000

Hi Dawn,

Thanks so much for your additional review. For short, there are indeed a number of typos and inconsistencies to be solved.

As for your point 2: the sentence means “However, Calendars can also represent any metric ++ with values ++ considered as time-varying by an ALTO Server”. The sentence is really about metrics here.

For point 6, indeed, the Server may omit member “cost-type-names” if only one metric is requested. And a “legacy” ALTO client by the way will not request a calendar.

I will respond inline in detail after the WG session.

Cheers,
Sabine


From: Dawn Chan [mailto:dawn_chen_f@hotmail.com]
Sent: Wednesday, July 12, 2017 10:37 AM
To: draft-ietf-alto-cost-calendar@ietf.org
Cc: alto@ietf.org
Subject: Review of draft-ietf-alto-cost-calendar-02

Hi authors of cost calendar and all,
I’ve just reviewed the new version of cost calendar and here are some feedbacks.

1. In Section 1 Introduction, “In case the ALTO Cost value changes are predicable over a certain period of time and …”, here the “predicable” should be “predictable”.
2. In Section 2.2.1 ALTO Cost Calendar for all cost modes, “However,Calendars can also represent any metric considered as time-varying by an ALTO Server”. I think this paragraph is discussing about cost mode rather than cost metric, so it might be better is we change the “metric” into “mode”.
3. In Section 3.1 Calendar attributes in the IRD resources capabilities, when explaining “cost-type-name”, I think it should be “cost-type-names”, it might be a typo.
4. In Section 3.3 Example IRD with ALTO Cost Calendars,
"http://custom.alto.example.com/calendar/endpointcost/lookup": an endpoint cost map in which in which calendar capabilities are indicated for cost type names: "num-routingcost", "num-latency","num-pathbandwidth", "string-service-status”.
Here one of the “in which” is a typo and should be deleted.

5. In Section 3.3 Example IRD with ALTO Cost Calendars, in the example of IRD, when specifying capabilities of resource "filtered-cost-map-calendar”, the “calendar-attributes” is the following:

"calendar-attributes" : [

              {"cost-type-names" : [ "num-routingcost", "num-pathbandwidth" ],

               "time-interval-size" : "1 hour”,

               "number-of-intervals" : 24

              },

              {"cost-type-names" : "string-service-status”,

               "time-interval-size" : "30 minute”,

               "number-of-intervals" : 48

        }

] // end calendar-attributes



Here the “cost-type-names”: “string-service-status” should be “cost-type-names”: [“string-service-status”] because “cost-type-names” is a JSONArray object. The same to the “cost-type-names” specified in resource “endpoint-cost-calendar-map” in this example.

Another problem for resource “endpoint-cost-calendar-map” is that

"endpoint-cost-calendar-map" : {

              "uri" : "http://custom.alto.example.com/calendar/endpointcost/lookup”,

              "media-types" : [ "application/alto-endpointcost+json" ],

              "accepts" : [ "application/alto-endpointcostparams+json" ],

              …

              “uses” : [“my-default-network-map"]

}



Here, the “media-types” and “accepts” are not JSONArray objects, so it should be



"endpoint-cost-calendar-map" : {

              "uri" : "http://custom.alto.example.com/calendar/endpointcost/lookup”,

              "media-types" : "application/alto-endpointcost+json",

              "accepts" : "application/alto-endpointcostparams+json",

              …

}



And an endpoint cost map do not need the dependent network map.



6. Here are some inconsistency between the definition and example displayed.



 In Section 4.1.2 Calendar extension in Filtered Cost map responses, it extends the response format with an field

 CalendarResponseAttributes calendar-response-attributes <1..*>;



The definition of CalendarResponseAttributes is:

object{

  JSONString    cost-type-names;

  JSONString    calendar-start-time;

  JSONString    time-interval-size;

  JSONNumber    number-of-intervals;

  [JSONNumber   repeated;]      [OPTIONAL]

} CalendarResponseAttributes;

But in the example in Section 4.1.3 “num-intervals” is used instead of “number-of-intervals”. The same typos happened in Section 4.2.3 and Section 4.2.4 (the examples of endpoint cost maps).

Another point is that, the "cost-type-names” is NOT optional, but the examples in Section 4.1.3 and 4.2.3 doesn’t provide this information. My suggestion is that “cost-type-names” is an OPTIONAL field, for legacy ALTO requests (request which contains only one cost type), the “cost-type-names” is  not necessary. But for multi-cost ALTO request, the “cost-type-names” MUST be provided. And since “cost-type-names” only contains a single value, maybe the name can be changed to “cost-type-name”.

Above are some of my ideas, if there is some misunderstanding, please correct.

Wish to here your reply.

Best Regards,

Dawn