Re: [alto] Review of cost-calendar-11
"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com> Tue, 14 May 2019 14:52 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 A6AFF12010E; Tue, 14 May 2019 07:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 ONAKKaQj8JEr; Tue, 14 May 2019 07:51:58 -0700 (PDT)
Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120111.outbound.protection.outlook.com [40.107.12.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7821200B3; Tue, 14 May 2019 07:51:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SwAJvNzI6+UwLoDVXJlgYwlOZvUC1rsU85x6phA5wJI=; b=lKmrFeCAVvRfViAmhY/iDCGxcW5c2mDoYxXcrobGxhz950/+tzpZEWoxJCvZoSN1qfjnJI9ak78L+by7BoPWSe9tBZJ0nmc2L/ANxi61wdflo6hK+oct+fs8fA0VE5QuK1rq95eF1iGof0VjL5BT8TOC0Jxz0sNXh0qvPN9eQP8=
Received: from PR1PR07MB5100.eurprd07.prod.outlook.com (20.177.209.144) by PR1PR07MB5739.eurprd07.prod.outlook.com (20.177.210.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.13; Tue, 14 May 2019 14:51:51 +0000
Received: from PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::b472:6872:a200:cf76]) by PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::b472:6872:a200:cf76%5]) with mapi id 15.20.1900.010; Tue, 14 May 2019 14:51:51 +0000
From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>
To: Vijay Gurbani <vijay.gurbani@gmail.com>, IETF ALTO <alto@ietf.org>, "draft-ietf-alto-cost-calendar@ietf.org" <draft-ietf-alto-cost-calendar@ietf.org>
Thread-Topic: Review of cost-calendar-11
Thread-Index: AQHU40L+TciQuwTN90Ck2JILIXGZbqZeWiIw
Date: Tue, 14 May 2019 14:51:50 +0000
Message-ID: <PR1PR07MB5100E59B6BAF5E5D4E151C7495080@PR1PR07MB5100.eurprd07.prod.outlook.com>
References: <CAMMTW_KZwvRyhhQV+9yv+805M6DoYdFMFPOOVKm8q+azMGU7ZA@mail.gmail.com>
In-Reply-To: <CAMMTW_KZwvRyhhQV+9yv+805M6DoYdFMFPOOVKm8q+azMGU7ZA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sabine.randriamasy@nokia-bell-labs.com;
x-originating-ip: [2a01:cb00:a00:b000:c964:95b2:47bc:dae1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3d70cca0-0f13-4d4d-e4b1-08d6d87bb2bb
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:PR1PR07MB5739;
x-ms-traffictypediagnostic: PR1PR07MB5739:
x-microsoft-antispam-prvs: <PR1PR07MB57397955363006CE0D42B6FC95080@PR1PR07MB5739.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-forefront-prvs: 0037FD6480
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(136003)(396003)(346002)(366004)(199004)(189003)(236005)(8676002)(81166006)(81156014)(86362001)(9686003)(256004)(25786009)(64756008)(66446008)(14444005)(7736002)(54896002)(66476007)(66556008)(76116006)(6306002)(5660300002)(790700001)(6116002)(2501003)(74316002)(6246003)(53936002)(52536014)(316002)(2906002)(68736007)(229853002)(71190400001)(71200400001)(7696005)(11346002)(76176011)(99286004)(446003)(6436002)(66946007)(73956011)(478600001)(55016002)(8936002)(186003)(14454004)(33656002)(486006)(6506007)(46003)(53546011)(476003)(102836004)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB5739; H:PR1PR07MB5100.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: /a8cUU2eoaT+aDZ27SoOk+XZEP3iaxPtTr3rizad4ClFn5z5HDkdXAGkR4XNfbQfOKO3g+sJBRqIdGftCSvnOLsAjblCGTLXDH0dkRkJhDAxWexLLQuKUuk7cZMFsQXP5Xfsc3aV5IKWbrB+hn2JNTtRLV3cdvc3MYLpL2UfgzU7IlKAAjZCmRjYvBDOfaAHJqr6txaIANxV8i4KO/nsIL5nLapGEbNqx4C+RPYS78Cq1lBjmrWu+aLDIOPA4v7QSxOcKnm15alxJ+uPucmn//ST8NP41dPMHF66VhDG7maiFSNU/hntR4pL8UuTngg19yP08YnuxIO+Nd8pV69/1xLCUMfVYs63dm1JueSxlcPw79AgFjBhgZegmPhnHT6hfEdd/fPzQ05xDpPFV+kGYucUccy47k0PhxTEzCeN8s8=
Content-Type: multipart/alternative; boundary="_000_PR1PR07MB5100E59B6BAF5E5D4E151C7495080PR1PR07MB5100eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d70cca0-0f13-4d4d-e4b1-08d6d87bb2bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2019 14:51:50.9789 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5739
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/7yEvh3MRx0LaXwfZDBGvE_wWMnU>
Subject: Re: [alto] Review of cost-calendar-11
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 14 May 2019 14:52:02 -0000
Hi Vijay, Many thanks for your wise guidance. I have attended to your comments and feedback and hope they meet your expectations. Please find my answers inline. All document-order specific comments have been attended. An inline answer is provided for some of them. draft-ietf-alto-cost-calendar-12.txt has just been posted. Thanks, Sabine From: Vijay Gurbani <vijay.gurbani@gmail.com<mailto:vijay.gurbani@gmail.com>> Sent: Monday, March 25, 2019 8:44 PM To: IETF ALTO <alto@ietf.org<mailto:alto@ietf.org>>; draft-ietf-alto-cost-calendar@ietf.org<mailto:draft-ietf-alto-cost-calendar@ietf.org> Subject: Review of cost-calendar-11 The cost-calendar draft is ready. It is an excellent piece of work by the authors who are long standing ALTO contributors; the draft is is applicable and of interest to many ALTO deployments (and this should be highlighted; I provide the Unicorn link to highlight this in my feedback below, but please provide more). The one feedback I have about the draft is the need for a thorough edit session to ensure grammar and consistency in the document as well as to ensure that implementations deal with as less ambiguity as possible when following the protocol extension. I provide some examples of where the text can be improved below. - General: a) Is it Cost Calendars (plural) or Cost Calendar (singular)? You use both in the text; best to ensure that only one representation is being used. [[SR]] It is Cost Calendars with an “s” when used in plural mode. I put “CalendarS” in section There is now a section 2.1 “Terminology”, that among others defines terms Calendar and Cost Calendars. In Section “2.4.1. ALTO Cost Calendar for all cost modes”, Calendar is now in “singular” mode, to harmonize with the rest of section 2.4. b) There are a number of run-on sentences (see first, second and third paragraphs in S3.1; such run-on sentences make it very hard to understand what is being asked of the implementors, and as a result will lead to an implementation that is ambiguous at best and full of bugs in the worst case. Such sentences must be scrubbed appropriately before publishing as these outline normative behaviour). [[SR]] some updates were made to clarify and shorten sentences, e.g. in sections 4.3 and 5.4. Getting the right text to describe the processing of cost-calendar is not easy, I will be the first to admit. Perhaps an editor can improve the text to eliminate such run-on sentences. c) In many HTTP requests and responses (see for example the ALTO POST request on page 19), a content length is specified. In the example on page 19, the C-L is 815. However, how was this sum arrived at? The body of the response contains a lot of elucidations ("v1, v2, ..., v12"), for example. Does the 815 bytes include these elucidations ("...")? My advice would be to be as realistic as possible and remove these elucidations, put sample values in the response and calculate the C-L. Yes, more work, but better product. [[SR]] Yes, the value of content length includes these elucidations. To clarify this, section 4.1.3., that brings the first occurrence of such an elucidation, now ends with the following sentence: The value of field "Content-Length" in the responses is computed as if "throughputrating" values were encoded in 2 digits. The same type of symbolization is used in the other example Server responses in Section 4.2.3 and Section 4.2.4 of this document. Similar text was also added in sections 4.2.3 and 4.2.4 . Indeed, one of the IESG reviews did ask that the draft clearly explains that these values ("v1, v2, ..., v12") are symbols, and then agreed on the proposed sentence, just before the above mentioned one: “the arrays in the provided example are symbolized by expression "[v1,v2, ... v12]", that is otherwise not valid in JSON.”. Document-order specific comments follow. - Abstract: a) s/service such that/service so that/ b) s/ALTO Cost Calendars/ALTO Cost Calendar/ - S1, para 1: s/needing to/that need to/ - S1, para 2: The larger point you are making in the second half of the paragraph is that due to the fact that ALTO does not provide real time network metrics, the applications essentially have to figure out what the cost of doing business will be at some later time, a proposition that is sub-optimal since the application has no idea of network usage at some future time. This salient point is not quite captured. Perhaps the text below may help? (Please feel free to edit as needed.) Also, you have the wrong reference to ALTO requirements document in your current text; that is fixed below as well. OLD: ALTO intentionally avoids provisioning real-time information as explained in the ALTO Problem Statement [RFC5693] and ALTO Requirements [RFC5693]. Thus the current Cost Map and Endpoint Cost Service are providing, for a given Cost Type, exactly one path cost value. Applications have to query one of these two services to retrieve the currently valid cost values. They, therefore, need to plan their ALTO information requests according to their own estimation of the frequency of cost value change. With [RFC7285], an ALTO client should interpret the returned costs as those at the query moment. However, Network costs can fluctuate, e.g., due to diurnal patterns of traffic demand or planned events such as network maintenance, holidays or highly publicized events. Providing network costs for only the current time thus may not be sufficient, in particular for applications that can schedule their traffic in a span of time, for example by deferring backups or other background traffic to off-peak hours. NEW: For the reasons outlined in the ALTO problem statement [RFC5693] and requirement AR-14 [RFC6708], ALTO does not disseminate network metrics that change frequently. In a network, the costs can fluctuate for many reasons having to do with instantaneous traffic load or due to diurnal patterns of traffic demand or planned events such as network maintenance, holidays or highly publicized events. Thus, an ALTO application wishing to use the Cost Map and Endpoint Cost Service at some future time will have to estimate the state of the network at that time, a process that is, at best, fragile and brittle since the application does not have any visibility into the state of the network. The need of such future scheduling of large scale traffic that can be addressed by the ALTO protocol is motivated by Unicorn, a unified resource orchestration framework for multi-domain, geo-distributed data analytics [draft-xiang-alto-multidomain-analytics]. - S2, para 2: s/crowded events/expected spike in traffic due to crowd gathering (concerts, sports, etc.)/ - S2.1, para 1: a) s/with dateless/without date/ b) s/the "meta" of/the "meta" section of/ c) s/avoiding to process useless requests./reducing processing of similar requests./ - S2.2, para 2: s/also says/states/ - S2.2, a) s/and ensure/and to ensure/ b) para 4: "As recommended, it relies ..." ==> Recommended by who? Please specify. [[SR]] “Recommended” has been removed as the cited section 8.3.7 of RFC 7285 expresses a MUST rule. - S2.2.2: OLD: As a consequence, when a metric is available as a Calendar array, it MUST be as well available as a single value, as provided by [RFC7285]. NEW: As a consequence, when a metric is available as a Calendar array, it also MUST be available as a single value as required by [RFC7285]. (This ensures backwards compatibility.) - S3.1, para 1, 2, and 3: I would re-write these paragraphs completely, probably put them in one pragraph. In its current form, it is hard to parse and understand these paragraphs. My suggested edit is below, but please feel free to modify as needed. A Cost Calendar for a given Cost Type MUST be indicated in the IRD by an object of type CalendarAttributes. A CalendarAttribute object is represented by "calendar-attributes" member of a resource entry. Each CalendarAttributes object applies to a set of one or more cost types. A Cost Type name MUST appear no more than once in the "calendar-attributes" member of a resource entry; multiple appearances of a Cost Type name in CalendarAttributes object of the "calendar-attributes" member causes the ALTO client to ignore any occurrences of this name beyond the first encountered occurrence. [[SR]] a MUST (NOW “MUST cause the ALTO client to ignore”) has been added - S3.2, para 1: "w.r.t." ==> Too colloquial to be in a standard document. Please take out or reword the sentence. [[SR]] the paragraph has been re-phrased as follows: <t>It may be useful to distinguish IRD resources supported by the base ALTO protocol from resources supported by its extensions. To achieve this, one option, is that a "root" ALTO Server implementing base protocol resources delegates "specialized" information resources such as the ones providing Cost Calendars, to another ALTO Server running in a subdomain that is specified with its URI in the "root" ALTO Server. This option is described in Section 9.2.4 "Delegation using IRDs" of <xref target="RFC7285"/>.</t> - S3.3: a) first bullet: s/at the IANA./with IANA. b) in the remaining bullets, s/some fictitious/a fictitious/ - S3.3, after the GET request, what is the horizontal line doing? It appears to be separating the request and the response, if so, please use the "S -> C" and "C -> S" nomenclature used in other IETF documents to denote request going from Client to Server and response from Server to Client. - S4, para 2 does not make sense grammatically. Please reword. [[SR]] para 2 has been re-phrased as follows: <t>The reference time zone for the provided time values is UTC. The option chosen to express the time format is the HTTP header fields format specified in <xref target="RFC7231"/> where, however, timestamps are still displayed with the acronym "GMT" rather than "UTC":</t> - S4.1.3, para 1: s/periods for example to/periods to/ - S4.1.3, para 3: s/To lighten the text/For representation brevity/ Thanks. - vijay
- [alto] Review of cost-calendar-11 Vijay Gurbani
- Re: [alto] Review of cost-calendar-11 Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
- Re: [alto] Review of cost-calendar-11 Randriamasy, Sabine (Nokia - FR/Paris-Saclay)