[alto] Review of cost-calendar-11

[Vijay Gurbani <[e-mail]>]

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.

 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).

 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.

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.

- 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.

- S3.2, para 1: "w.r.t." ==> Too colloquial to be in a standard document.
  Please take out or reword the sentence.

- 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.

- 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